HOW2: Repair Pogo E02 with Raspberry PI (1,2 or 3) JTAG and OpenOCD

Ok. so I have this stock mtd partitions
from stock u-boot

console=console=ttyS0,115200 mtdparts=nand_mtd:0xc0000@0(uboot)ro,0x7f00000@0x100000(root)

Creating 4 MTD partitions on "nand_mtd":
0x00000000-0x00100000 : "u-boot"
0x00100000-0x00400000 : "uImage"
0x00400000-0x00800000 : "uInitrd_m"
0x00800000-0x08000000 : "root"

I opened openocd and I gave the commands to flash the saved stock images for u-boot , uImage and uinitrd_m

heevaplug_init
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0x000000d3 pc: 0xffff0000
MMU: disabled, D-Cache: disabled, I-Cache: disabled
> nand probe 0   
NAND flash device 'NAND 128MiB 3.3V 8-bit (Samsung)' found
> nand info 0 
#0: NAND 128MiB 3.3V 8-bit (Samsung) pagesize: 2048, buswidth: 8, erasesize: 131072
....... a lot of blocks
> nand list 
#0: NAND 128MiB 3.3V 8-bit (Samsung) pagesize: 2048, buswidth: 8,
	blocksize: 131072, blocks: 1024
> nand erase 0 0 0x800000
erased blocks 0 to 63 on NAND flash device #0 'NAND 128MiB 3.3V 8-bit'
> nand write 0 u-boot-mtd.bin 0 oob_softecc_kw
wrote file u-boot-mtd.bin to NAND flash 0 up to offset 0x00100000 in 40.270664s (25.428 KiB/s)
> nand write 0 uImage-mtd.bin 0x100000 oob_softecc_kw
wrote file uImage-mtd.bin to NAND flash 0 up to offset 0x00400000 in 120.705383s (25.450 KiB/s)
> nand write 0 uinitrd_m-mtd.bin 0x400000 oob_softecc_kw
wrote file uinitrd_m-mtd.bin to NAND flash 0 up to offset 0x00800000 in 160.762421s (25.479 KiB/s)

After that I restart with sheevaplug_init and I have the stock u-boot output:

           _           ____ _ 
          | |    __ _ / ___(_) ___
          | |   / _` | |   | |/ _ \
          | |___ (_| | |___| |  __/
          |_____\__,_|\____|_|\___|
 _   _     ____              _
| | | |   | __ )  ___   ___ | |_ 
| | | |___|  _ \ / _ \ / _ \| __| 
| |_| |___| |_) | (_) | (_) | |_ 
 \___/    |____/ \___/ \___/ \__| 
 ** MARVELL BOARD: ASTON_WS_GN3 REV: 2 LE
Hold rear button - long :  FAIL


U-Boot 1.1.4 (Jul 27 2011 - 17:43:51) Marvell version: 3.4.16  LaCie 1.5.22 256MB

U-Boot code: 06000000 -> 0607FFF0  BSS: -> 060CE600

Soc: MV88F6281 Rev 3 (DDR2)
CPU running @ 800Mhz L2 running @ 400Mhz
SysClock = 200Mhz , TClock = 166Mhz 

DRAM CAS Latency = 3 tRP = 3 tRAS = 9 tRCD=3
DRAM CS[0] base 0x00000000   size 256MB 
DRAM Total size 256MB  16bit width
Flash:  0 kB
Addresses 98M - 0M are saved for the U-Boot usage.
Mem malloc Initialization (98M - 97M): Done
NAND:128 MB
*** Warning - bad CRC or NAND, using default environment


CPU : Marvell Feroceon (Rev 1)

Streaming disabled 
Write allocate disabled

Module 0 is MII

USB 0: host mode
PCI 0: PCI Express Root Complex Interface
PEX interface detected Link X1
Net:   egiga0 [PRIME], egiga1
Waiting for LUMP (3)
no lump receive; continuing
Hit any key to stop autoboot:  0 

Reset IDE: 
Marvell Serial ATA Adapter
Integrated Sata device found

** Bad partition 1 **

## Checking Image at 00800000 ...
   Bad Magic Number

NAND read: device 0 offset 0x100000, size 0x300000

reading NAND page at offset 0x100000 failed
 3145728 bytes read: ERROR
** Bad partition 1 **

## Checking Image at 01200000 ...
   Bad Magic Number

NAND read: device 0 offset 0x400000, size 0x400000

reading NAND page at offset 0x400000 failed
 4194304 bytes read: ERROR
## Booting image at 00800000 ...
Bad Magic Number
Waiting for LUMP (0)

Abort
no lump receive; continuing
Marvell>>

then I give saveenv

Marvell>> saveenv
Saving Environment to NAND...
Erasing Nand...Writing to Nand... done
Marvell>>

And after restart

           _           ____ _ 
          | |    __ _ / ___(_) ___
          | |   / _` | |   | |/ _ \
          | |___ (_| | |___| |  __/
          |_____\__,_|\____|_|\___|
 _   _     ____              _
| | | |   | __ )  ___   ___ | |_ 
| | | |___|  _ \ / _ \ / _ \| __| 
| |_| |___| |_) | (_) | (_) | |_ 
 \___/    |____/ \___/ \___/ \__| 
 ** MARVELL BOARD: ASTON_WS_GN3 REV: 2 LE
Hold rear button - long :  FAIL


U-Boot 1.1.4 (Jul 27 2011 - 17:43:51) Marvell version: 3.4.16  LaCie 1.5.22 256MB

U-Boot code: 06000000 -> 0607FFF0  BSS: -> 060CE600

Soc: MV88F6281 Rev 3 (DDR2)
CPU running @ 800Mhz L2 running @ 400Mhz
SysClock = 200Mhz , TClock = 166Mhz 

DRAM CAS Latency = 3 tRP = 3 tRAS = 9 tRCD=3
DRAM CS[0] base 0x00000000   size 256MB 
DRAM Total size 256MB  16bit width
Flash:  0 kB
Addresses 98M - 0M are saved for the U-Boot usage.
Mem malloc Initialization (98M - 97M): Done
NAND:128 MB

CPU : Marvell Feroceon (Rev 1)

Streaming disabled 
Write allocate disabled

Module 0 is MII

USB 0: host mode
PCI 0: PCI Express Root Complex Interface
PEX interface detected Link X1
Net:   egiga0 [PRIME], egiga1
Waiting for LUMP (3)
no lump receive; continuing
Hit any key to stop autoboot:  0 

Reset IDE: 
Marvell Serial ATA Adapter
Integrated Sata device found

** Bad partition 1 **

## Checking Image at 00800000 ...
   Bad Magic Number

NAND read: device 0 offset 0x100000, size 0x300000

reading NAND page at offset 0x100000 failed
 3145728 bytes read: ERROR
** Bad partition 1 **

## Checking Image at 01200000 ...
   Bad Magic Number

NAND read: device 0 offset 0x400000, size 0x400000

reading NAND page at offset 0x400000 failed
 4194304 bytes read: ERROR
## Booting image at 00800000 ...
Bad Magic Number
Waiting for LUMP (0)

Abort
no lump receive; continuing
Marvell>>

So indeed, after saveenv there is no more bad CRC. but still what is with those errors:

Marvell>> run load_kernel_mtd=nand read.jffs2 0x800000 0x100000 0x300000

NAND read: device 0 offset 0x100000, size 0x300000

reading NAND page at offset 0x100000 failed
 3145728 bytes read: ERROR
Marvell>> run load_initrd_mtd=nand read.jffs2 0x1200000 0x400000 0x400000

NAND read: device 0 offset 0x400000, size 0x400000

reading NAND page at offset 0x400000 failed
 4194304 bytes read: ERROR
Marvell>>

Edited 1 time(s). Last edit at 04/11/2021 07:16AM by fratzicu.

Reading the first MB dumped into the file, I found that the env variables start from 0xa0000 and stop at BFFFF (c0000).

There is also an interesting part of the stock u-boot image
- it starts from 0x0 and goes to 0x65573 with bytes
- then a lot of FF...
- then from 0x70200 again some information with board names and other things until 0x73FFF(0x74000)
- here I think there are infos about boards: from 0x70ttc to 0x71BEC
- here I think there are the default env vars from 0x72EC8 to 72F41F
- zeros until 0x73FFF
- some isolated non-FF and non 00 bytes are at addresses:
- FF from 0x74000 to ox7BFFF (0x7C000)
- 0x740A8 (FB)
- 0x7607E (FB)
- 0x76466 (DF)
- 0x780A8 (FB)
- 0x7A07E (FB)
- 0x7A466 (DF)
- then we have zeros from 0x7C000 to 0x83FFF (0x84000)
- 0x7E834 (04)
- 0x82834 (04)
- then we have again FF from 0x84000 to 0x8BFFF (0x8C000)
- 0x840A8 (FB)
- 0x8607E (FB)
- 0x86466 (DF)
- 0x880A8 (FB)
- 0x8A07E (FB)
- 0x8A466 (DF)
- then again zeros from 0x8C000 to 0x93FFF (0x94000)
- then again FF from 0x94000 to 0x9BFFF (0x9C000)
- 0x940A8 (FB)
- 0x9607E (FB)
- 0x96466 (DF)
- 0x980A8 (FB)
- 0x9A07E (FB)
- 0x9A466 (DF)
- then again zeros from 0x9C000 to 0x9FFFF (0xA0000)
- env variables start from here (0xA0000) to BFFFF (c0000)
- data from 0xA0000 to A08E0
- zeros from 0xA08E1H to BFFFF
- and from 0xC0000 until the end of one Mb 0xFFFFF (0x100000) only FFs

Do you think the isolated non-00 and non-FF could be error written bytes? could those have been read erroneously from the flash with jtag and other such bytes could be among the uImage and uinitrd_m read data so when flashing back there could be read errors?
Should I re-read flash and compare with the first read data to see they are identical?
kind regards.



Edited 1 time(s). Last edit at 04/11/2021 08:36AM by fratzicu.

So it seems my u-boot layout is

================================================================================
## uboot layout (mtd0) ##
================================================================================
                     offset                   
   Block 0 (128K)    0x0    ------------|            
                                        |
   Block 1 (128K)    0x20000            |
                                        |
   Block 2 (128K)    0x40000    uboot   |            size 0xa0000
                                        |
   Block 3 (128K)    0x60000            |
                                        |                         uboot  5 Blocks with 128K 
   Block 4 (128K)    0x80000            |          
                                        
   Block 5 (128K)    0xa0000 -----------|-->           
                              uboot env |                size 0x20000
   Block 6 (128K)    0xc0000 -----------|-->  uboot env 1 Block with 128K
                              nothing here, only FF
   Block 7 (128K)    0xe0000 -----------|  
                              nothing here, only FF
                                                       128K x 8 = 1024K = 1M
            to      0x100000                             1M = 8 Blocks (0-7)
                                     
================================================================================

Edited 2 time(s). Last edit at 04/13/2021 09:14AM by fratzicu.

fratzicu,


Yes. Kirkwood stock u-boot images are usually 4 blocks. The built image is smaller, but we round it up to 512K to make it easier to flash to NAND.

As I've mentioned above, I think you should move on to work on the kernel DTS. This has to be done so that you understand the box HW and can run the Kirkwood kernel with the DTS. Don't dwell on the NAND stuff, it is not important at the moment.

Boot into Debian using my rootfs Debian-5.2.9-kirkwood-tld-1-rootfs-bodhi.tar.bz2 on USB. Then worry about flashing kernel to NAND. It can be done at Linux shell command line. As always, it is much easier to understand to problem and avoid mistake during flashing while inside Linux. And then when you want to run OpenWrt, the kernel images flashing can be done at u-boot prompt if prefered (but unecessary).

When you're ready to start, create a new thread in Debian sub-forum with Subject:

Debian on LaCie Wireless Space

And post these info in the first post:

- The specifications of the box. See https://wikidevi.wi-cat.ru/LaCie. The Wireless Space does not have its own entry yet, but the specs is listed.
- Stock serial boot log (prefereably a complete log that shows everything until the login prompt)
- printenv listing for the stock u-boot
- If there is GPL source provided by the manufacterer, post the link to it.

And I will help you modify the existing Lacie DTS for other LaCie boxes to create a Wireless Space DTS. And then modify u-boot envs to boot into the USB rootfs.

===

Thanks for all you are doing during this pandemic.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 1 time(s). Last edit at 04/11/2021 04:34PM by bodhi.

Great! I have all the requested info and I will post the new thread soon.
Kind regards.

I was able to start the process of recovering the E02. However, there were some items that say "depreciated" and to use something else. I was able figure out some of the depreciated items and where to change them. One that i'm not sure about is the adapter [de]assert instead of jtag_reset .

Also while it shows I am in supervisor mode, it shows I-Cache:enabled is this ok enabled or is that something to do with the jtag_reset issue?

ad@raspberrypi:~ $ sudo openocd -f pogo.cfg
Open On-Chip Debugger 0.12.0+dev-00164-g682f927f8 (2023-05-03-18:34)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "jtag". To override use 'transport select <transport>'.
Warn : use 'feroceon.cpu' as target identifier, not '0'
pogo_load_uboot
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : BCM2835 GPIO JTAG/SWD bitbang driver
Info : clock speed 200 kHz
Info : JTAG tap: feroceon.cpu tap/device found: 0x20a023d3 (mfg: 0x1e9 (Marvell Semiconductors), part: 0x0a02, ver: 0x2)
Info : Embedded ICE version 0
Info : feroceon.cpu: hardware has 1 breakpoint/watchpoint unit
Info : starting gdb server for feroceon.cpu on 3333
Info : Listening on port 3333 for gdb connections
Info : accepting 'telnet' connection on tcp/4444
DEPRECATED! use 'adapter [de]assert' not 'jtag_reset'
DEPRECATED! use 'adapter [de]assert' not 'jtag_reset'
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0x600000d3 pc: 0x0ff5a3b8
MMU: disabled, D-Cache: disabled, I-Cache: enabled
invalid command name "soft"

I've found some info loooking at this page. jtag reset but i am not 100% clear on it.

It looks like I need to change the both instances of jtag_reset in the pogo.cfg file (snipit below) but I'm not sure what to change them to.
adapter deassert or adapter assert

# We need to assert DBGRQ while holding nSRST down.
 # However DBGACK will be set only when nSRST is released.
 # Furthermore, the JTAG interface doesn't respond at all when
 # the CPU is in the WFI (wait for interrupts) state, so it is
 # possible that initial tap examination failed. So let's
 # re-examine the target again here when nSRST is asserted which
 # should then succeed.
 jtag_reset 0 1
 feroceon.cpu arp_examine
 halt 0
 jtag_reset 0 0
 wait_halt

Any thoughts?

@Joerg -

First, thank you so much for this detailed writeup! I'm in the process of trying to recover a PogoPlug Mobile (my fault, nuked uboot), so I'm working to bring up the JTAG via a Pi.

I've run into a few issues along the way (on the software prep), and I was told to post some of that info here. Specifically, I got a handful of deprecated messages with OpenOCD -- not sure if they're fatal or not.

> DEPRECATED! use 'adapter driver' not 'interface'
> DEPRECATED! use 'bcm2835gpio peripheral_base' not
> 'bcm2835gpio_peripheral_base'
> DEPRECATED! use 'bcm2835gpio speed_coeffs' not
> 'bcm2835gpio_speed_coeffs'
> DEPRECATED! use 'adapter gpio tck; adapter gpio
> tms; adapter gpio tdi; adapter gpio tdo' not
> 'bcm2835gpio_jtag_nums'
> DEPRECATED! use 'adapter gpio swclk; adapter gpio
> swdio' not 'bcm2835gpio_swd_nums'
> DEPRECATED! use 'adapter gpio trst' not
> 'bcm2835gpio_trst_num'
> DEPRECATED! use 'adapter speed' not 'adapter_khz'
> Warn : DEPRECATED: auto-selecting transport

There's a lot more context in my other thread, including information about the fact that I was unable to get the setup working with Raspberry Pi OS. Instead, I used Ubuntu for the Pi. It seems that the binary is working) aside from the deprecated messages, but I also haven't yet connected the hardware, so not sure yet if that works as expected on Ubuntu.

https://forum.doozan.com/read.php?3,139761,139770#msg-139770

(please forgive me if I've broken any rules about crossposting)

Any thoughts about the above messages and/or my 'saga' would be greatly appreciated. Thanks in advance for your help!!

Attached here is the kwbimage.cfg for the Pogo V4.

This should be adapted to the Pogo 02 tutorial in the 1st post.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

(per Bodhi's request, moving my conversation to this thread)

Some updates on my efforts to recover my Pogoplug Mobile (v4).... progress, but not fixed yet! I've got the JTAG interface up and running, but I'm unable to write uboot.

Here are the details:

First, it's worth mentioning that I'm using the exact content as described in the first post of the how2 page for /usr/share/openocd/scripts/board/pogo.cfg -- that seems to be a config for the E02, not sure if it is valid for my v4 unit. Since I can't seem to do an anchor-link to directly reference the section of the tutorial, I'll include here the first few lines of that file:

 # Pogoplug E02
 # modification joerg_999 14.03.2016
 # use this pogo.cfg taken from sheevaplug to use with Raspi direct or Buspirate jtag adapter
 # use raspberrypi-native mode 
 # we use the Pins from SPI Interface (violett) 19,21,23,26 and 22, + 20 for GND 
 # see GPIO schematic Raspi Raspi GPIO

 # source [find interface/buspirate.cfg] 
 # source [find interface/sysfsgpio-raspberrypi.cfg] 
 source [find interface/raspberrypi123-native.cfg]
 source [find target/feroceon.cfg]
...

Next, I'm not exactly sure where I am supposed to use the kwbimage.cfg (for the v4) provided by @bodhi. At first, I thought it was a replacement for the above, but that clearly isn't the case because it's a totally different file structure.

---> hints/directions for the above would be much appreciated.


Moving on... I am using the following files:

uboot.2023.04-tld-1.pogo_v4.environment
uboot.2023.04-tld-1.pogo_v4.kwb

They are sym-linked as uboot-env.bin and uboot.kwb respectively.

At this point, I start the openocd process:

peter@pi400:~$ sudo openocd -f pogo_e02.cfg 
Open On-Chip Debugger 0.12.0+dev-00994-g744955e5b (2025-05-13-19:41)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
DEPRECATED! use 'adapter driver' not 'interface'
DEPRECATED! use 'bcm2835gpio peripheral_base' not 'bcm2835gpio_peripheral_base'
DEPRECATED! use 'bcm2835gpio speed_coeffs' not 'bcm2835gpio_speed_coeffs'
DEPRECATED! use 'adapter gpio tck; adapter gpio tms; adapter gpio tdi; adapter gpio tdo' not 'bcm2835gpio_jtag_nums'
DEPRECATED! use 'adapter gpio swclk; adapter gpio swdio' not 'bcm2835gpio_swd_nums'
DEPRECATED! use 'adapter gpio trst' not 'bcm2835gpio_trst_num'
DEPRECATED! use 'adapter speed' not 'adapter_khz'
Warn : DEPRECATED: auto-selecting transport "jtag". Use 'transport select jtag' to suppress this message.
pogo_load_uboot
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : BCM2835 GPIO JTAG/SWD bitbang driver
Info : clock speed 200 kHz
Info : JTAG tap: feroceon.cpu tap/device found: 0x20a023d3 (mfg: 0x1e9 (Marvell Semiconductors), part: 0x0a02, ver: 0x2)
Info : Embedded ICE version 0
Info : feroceon.cpu: hardware has 1 breakpoint/watchpoint unit
Info : [feroceon.cpu] Examination succeed
Info : [feroceon.cpu] starting gdb server on 3333
Info : Listening on port 3333 for gdb connections

and I can get into the telnet session to run the various commands. There are two notable issues here (I'll call them out after this code block):

$ telnet localhost 4444
Trying ::1...
Connection failed: Connection refused
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Open On-Chip Debugger
> pogo_init                              
DEPRECATED! use 'adapter [de]assert' not 'jtag_reset'
DEPRECATED! use 'adapter [de]assert' not 'jtag_reset'
target halted in Thumb state due to debug-request, current mode: Supervisor
cpsr: 0x400000f3 pc: 0xffff0ba6
MMU: enabled, D-Cache: enabled, I-Cache: enabled
> soft_reset_halt                        
[feroceon.cpu] requesting target halt and executing a soft reset
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0x400000d3 pc: 0x00000000
MMU: disabled, D-Cache: disabled, I-Cache: disabled
> nand probe 0                           
NAND flash device 'NAND 128MiB 3.3V 8-bit (Hynix)' found
> nand erase 0 0x0 0xa0000               
erased blocks 0 to 4 on NAND flash device #0 'NAND 128MiB 3.3V 8-bit'
> nand write 0 uboot.kwb 0 oob_softecc_kw
timed out while waiting for target halted
error executing hosted NAND write
Unable to write data to NAND device
failed writing file uboot.kwb to NAND flash 0 at offset 0x00000000

First, in the example output, it shows " # erased blocks 0 to 5 on NAND flash device #0 'NAND 128MiB 3.3V 8-bit'", but my output shows just blocks 0 to 4.

Then, obviously if fails to write the uboot.kwb file to the nand.

Thoughts/ideas? am I missing a step or doing something wrong?


Thanks!!

Still no luck, but I did make a minor change to the raspberypi123-natifve.cfg:

# Raspi4 BCM2837 (1800Mhz):
bcm2835gpio_speed_coeffs 292407 72

These new coefficients were calculated based on the output of lscpu which showed a max CPU speed of 1800MHz on my Pi400.

That did not solve the problem, though. I'm still getting a timeout (same error as shown in my previous post).

@bodhi and @joerg_999 -- any ideas?

Thanks.

@shermbug,

Not sure why. I've PMed joerg.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Thanks Bodhi! Much appreciated.

Hi joerg (and bodhi) -- Sorry to bump this, but just in case it fell off your radar, I'm still hoping to recover my bricked Pogoplug Mobile. It's been 2 weeks since the last post, but I haven't been able to make any progress because it simply fails to write to the nand. I've done some searching on the web and nothing has really turned up that would explain this situation. I'm hoping that you might have some ideas or things for me to try.

Thanks!

Hi shermbug,

I do rely on joerg to provide helps on this subject.

I'm very rusty about JTAG. I played with it at my job more than 10 years ago, and probably need to relearn it like you are doing!

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Yeah, the last time I worked with JTAG was actually a bit over 2 decades ago as a young engineer programming FPGAs (my JTAG adapter used a parallel port and consisted of literally just a 74-series buffer chip). That really makes me feel old...lol.

But those FPGAs never refused to write... and obviously the environment I'm attempting here is not even remotely the same. So hopefully joerg might have some ideas about what might be causing the nand writes to fail -- be it timing, a minor config issue, or something else. Keeping my fingers crossed for now!

shermbug,

While we are waiting for joerg to chime in about the NAND write error, here is my next recommendations.

1. The example in the 1st post is for the Pogo E02 which uses the 88F6281 SoC. The Pogo V4 uses the 88F6192 SoC. The CPU is running at a different speed, and the TCLK is also different. And I am almost certain the register values are different (I have not looked in the 88F6192 Ref Manual to see how different). Below is just educated guess.

https://forum.doozan.com/read.php?3,21789,139776#msg-139776

Quote

This should be adapted to the Pogo 02 tutorial in the 1st post.

What I meant was, you need to compare the 2 files and retrofit the Pogo E02 cfg to use the Pogo V4 values. For example,

Pogo V4 kwbimage.cfg

#Dram initalization for SINGLE x16 CL=3 @ 200MHz   (need CL=3 @ 200MHz?) 

DATA 0xffd01400 0x43000618      # DDR Configuration register

DATA 0xffd01404 0x34143000      # DDR Controller Control Low

Pogo E02 JTAG cfg

mww 0xD0001400 0x43000C30 ;# DDR SDRAM Configuration Register

mww 0xD0001404 0x39543000 ;# Dunit Control Low Register

And so on for each value you can find matching address.

2. The MPP pins need to be revised.

Pogo E02 JTAG cfg

mww 0xD0010000 0x01111111 ;# MPP 0 to 7
mww 0xD0010004 0x11113322 ;# MPP 8 to 15
mww 0xD0010008 0x00001111 ;# MPP 16 to 23

Here are the correct values for Pogo V4.

01111111
11113311
00551111

I don't think the MPPs have anything to do with that NAND error. But they are relevant for other initialization purposes. For example, Sys Reset (but they are the same, which is MPP 6).

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 1 time(s). Last edit at 06/04/2025 03:00PM by bodhi.

This is suspect, might be wrong.

mww 0xD0010418 0x003E07CF ;# NAND Read Parameters REgister
mww 0xD001041C 0x000F0F0F ;# NAND Write Parameters Register
mww 0xD0010470 0x01C7D943 ;# NAND Flash Control Register

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

bodhi Wrote:
-------------------------------------------------------
> This is suspect, might be wrong.
>
>

> mww 0xD0010418 0x003E07CF ;# NAND Read Parameters
> REgister
> mww 0xD001041C 0x000F0F0F ;# NAND Write Parameters
> Register
> mww 0xD0010470 0x01C7D943 ;# NAND Flash Control
> Register
>

I've verified they are correct.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Awesome! Thank you Bodhi! It may be a day or two before I have time to run through the register maps, but this is extremely helpful and a great pointer. And thank you for verifying the NAND registers.

Sorry for the delay in my response. I now have different errors, but the updated register values didn't fix the problem.

> pogo_init
DEPRECATED! use 'adapter [de]assert' not 'jtag_reset'
DEPRECATED! use 'adapter [de]assert' not 'jtag_reset'
target halted in Thumb state due to debug-request, current mode: Supervisor
cpsr: 0x400000f3 pc: 0xffff0ba6
MMU: enabled, D-Cache: enabled, I-Cache: enabled
> soft_reset_halt                        
[feroceon.cpu] requesting target halt and executing a soft reset
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0x400000d3 pc: 0x00000000
MMU: disabled, D-Cache: disabled, I-Cache: disabled
> nand probe 0                           
NAND flash device 'NAND 128MiB 3.3V 8-bit (Hynix)' found
> nand erase 0 0x0 0xa0000               
erased blocks 0 to 4 on NAND flash device #0 'NAND 128MiB 3.3V 8-bit'
> nand write 0 uboot.kwb 0 oob_softecc_kw
timeout waiting for SYSCOMP & DBGACK, last DBG_STATUS: 0
Unable to write data to NAND device
failed writing file uboot.kwb to NAND flash 0 at offset 0x00000000
>

I'm working on the assumption that the registers in the file that @bodhi provided are really deltas from the e02 device. With that in mind, there were a lot of registers that I didn't update and a few that I commented out because they seemed redundant or inconsistent. I also added a few. All of these should be apparent in the file that resulted (below).

Do I have errors here, or are there other things I need to do/check/edit? Or is this going to boil down to finding complete register map of the 88F6192 and then the corresponding values per register?

# Pogoplug v4 edited from a base of the Pogoplug E02
 # modification shermbug 09.06.2025 based on the below and this file from @bodhi: https://forum.doozan.com/file.php?3,file=7310,filename=kwbimage.cfg,download=1
 # modification joerg_999 14.03.2016
 # use this pogo.cfg taken from sheevaplug to use with Raspi direct or Buspirate jtag adapter
 # use raspberrypi-native mode 
 # we use the Pins from SPI Interface (violett) 19,21,23,26 and 22, + 20 for GND 
 # see GPIO schematic Raspi Raspi GPIO

 # source [find interface/buspirate.cfg] 
 # source [find interface/sysfsgpio-raspberrypi.cfg] 
 source [find interface/raspberrypi123-native.cfg]
 source [find target/feroceon.cfg]
  
$_TARGETNAME configure \
-work-area-phys 0x100000 \
-work-area-size 65536 \
-work-area-backup 0
 #arm7_9 dcc_downloads enable
 # this assumes the hardware default peripherals location before u-Boot moves it
 set _FLASHNAME $_CHIPNAME.flash
 nand device $_FLASHNAME orion 0 0xd8000000
 proc pogo_init { } {
 # We need to assert DBGRQ while holding nSRST down.
 # However DBGACK will be set only when nSRST is released.
 # Furthermore, the JTAG interface doesn't respond at all when
 # the CPU is in the WFI (wait for interrupts) state, so it is
 # possible that initial tap examination failed. So let's
 # re-examine the target again here when nSRST is asserted which
 # should then succeed.
 jtag_reset 0 1
 feroceon.cpu arp_examine
 halt 0
 jtag_reset 0 0
 wait_halt
 arm mcr 15 0 0 1 0 0x00052078
 mww 0xffd01400 0x43000618 ;# Updated DDR SDRAM Configuration Register
 mww 0xffd01404 0x34143000 ;# Updated Dunit Control Low Register
 mww 0xffd01408 0x11012227 ;# Updated DDR SDRAM Timing (Low) Register
 mww 0xffd0140c 0x00000819 ;# Updated DDR SDRAM Timing (High) Register
 mww 0xffd01410 0x00000001 ;# Updated DDR SDRAM Address Control Register
 mww 0xffd01414 0x00000000 ;# Updated DDR SDRAM Open Pages Control Register
 mww 0xffd01418 0x00000000 ;# Updated DDR SDRAM Operation Register
 mww 0xffd0141c 0x00000632 ;# Updated DDR SDRAM Mode Register
 mww 0xffd01420 0x00000040 ;# Updated DDR SDRAM Extended Mode Register
 mww 0xffd01424 0x0000F07F ;# Updated (DDR DDR Controller Control High) Dunit Control High Register
 # mww 0xD0001428 0x00085520 ;# Dunit Control High Register
 # mww 0xD000147c 0x00008552 ;# Dunit Control High Register
 mww 0xffd01428 0x00085520 ;# Added DDR2 ODT Read Timing (default values)
 mww 0xffd0147c 0x00008552 ;# Added DDR2 ODT Write Timing (default values)
 mww 0xFFD01500 0x00000000 ;# Added CS[0]n Base address to 0x0
 mww 0xFFD01504 0x07FFFFF1 ;# Updated CS0n Size Register
 # mww 0xD0001508 0x10000000 ;# CS1n Base Register
 mww 0xFFD0150C 0x00000000 ;# Updated CS1n Size Register
 mww 0xFFD01514 0x00000000 ;# Updated CS2n Size Register
 mww 0xFFD0151C 0x00000000 ;# Updated CS3n Size Register
 mww 0xffd01494 0x00030000 ;# Updated DDR2 SDRAM ODT Control (Low) Register
 mww 0xffd01498 0x00000000 ;# Updated DDR2 SDRAM ODT Control (High) REgister
 mww 0xffd0149c 0x0000e803 ;# Updated (CPU ODT Control) DDR2 Dunit ODT Control Register
 mww 0xffd01480 0x00000001 ;# Updated DDR SDRAM Initialization Control Register
 mww 0xD0020204 0x00000000 ;# Main IRQ Interrupt Mask Register
 mww 0xD0020204 0x00000000 ;# "
 mww 0xD0020204 0x00000000 ;# "
 mww 0xD0020204 0x00000000 ;# "
 mww 0xD0020204 0x00000000 ;# "
 mww 0xD0020204 0x00000000 ;# "
 mww 0xD0020204 0x00000000 ;# "
 mww 0xD0020204 0x00000000 ;# "
 mww 0xD0020204 0x00000000 ;# "
 mww 0xD0020204 0x00000000 ;# "
 mww 0xD0020204 0x00000000 ;# "
 mww 0xD0020204 0x00000000 ;# "
 mww 0xD0020204 0x00000000 ;# "
 mww 0xD0020204 0x00000000 ;# "
 mww 0xD0020204 0x00000000 ;# "
 mww 0xD0020204 0x00000000 ;# "
 mww 0xD0020204 0x00000000 ;# "
 mww 0xD0020204 0x00000000 ;# "
 mww 0xD0020204 0x00000000 ;# "
 mww 0xD0020204 0x00000000 ;# "
 mww 0xD0020204 0x00000000 ;# "
 mww 0xD0020204 0x00000000 ;# "
 mww 0xD0020204 0x00000000 ;# "
 mww 0xD0020204 0x00000000 ;# "
 mww 0xD0020204 0x00000000 ;# "
 mww 0xD0020204 0x00000000 ;# "
 mww 0xD0020204 0x00000000 ;# "
 mww 0xD0020204 0x00000000 ;# "
 mww 0xD0020204 0x00000000 ;# "
 mww 0xD0020204 0x00000000 ;# "
 mww 0xD0020204 0x00000000 ;# "
 mww 0xD0020204 0x00000000 ;# "
 mww 0xD0020204 0x00000000 ;# "
 mww 0xD0020204 0x00000000 ;# "
 mww 0xD0020204 0x00000000 ;# "
 mww 0xD0020204 0x00000000 ;# "
 mww 0xD0020204 0x00000000 ;# "
 mww 0xD0010000 0x01111111 ;# Updated MPP 0 to 7
 mww 0xD0010004 0x11113311 ;# Updated MPP 8 to 15
 mww 0xD0010008 0x00551111 ;# Updated MPP 16 to 23
 mww 0xD0010418 0x003E07CF ;# NAND Read Parameters REgister
 mww 0xD001041C 0x000F0F0F ;# NAND Write Parameters Register
 mww 0xD0010470 0x01C7D943 ;# NAND Flash Control Register
 }
 proc pogo_reflash_uboot { } {
 # reflash the u-Boot binary and reboot into it
 pogo_init
 nand probe 0
 nand erase 0 0x0 0xa0000
 nand write 0 uboot.kwb 0 oob_softecc_kw
 resume
 }
 proc pogo_reflash_uboot_env { } {
 # reflash the u-Boot environment variables area
 pogo_init
 nand probe 0
 nand erase 0 0xc0000 0x20000
 nand write 0 uboot-env.bin 0xc0000 oob_softecc_kw
 resume
 }
 proc pogo_load_uboot { } {
 # load u-Boot into RAM and execute it
 pogo_init
 load_image uboot.kwb
 verify_image uboot.kwb
 resume 0x800200
 }

Hi shermbug,


> I'm working on the assumption that the registers
> in the file that @bodhi provided are really deltas
> from the e02 device. With that in mind, there were
> a lot of registers that I didn't update and a few
> that I commented out because they seemed redundant
> or inconsistent. I also added a few. All of these
> should be apparent in the file that resulted
> (below).
>
> Do I have errors here, or are there other things I
> need to do/check/edit?

Errors. Now that I reread my post, I think I was not thorough enough.

Quote

Pogo V4 kwbimage.cfg
#Dram initalization for SINGLE x16 CL=3 @ 200MHz (need CL=3 @ 200MHz?)

DATA 0xffd01400 0x43000618 # DDR Configuration register

DATA 0xffd01404 0x34143000 # DDR Controller Control Low

Pogo E02 JTAG cfg
mww 0xD0001400 0x43000C30 ;# DDR SDRAM Configuration Register

mww 0xD0001404 0x39543000 ;# Dunit Control Low Register

And so on for each value you can find matching address.

The matching address is 0xD0001400 and 0xffd01400, 0xffd01404 and 0xD0001404. So these values must be

mww 0xD0001400 0x43000618 ;# DDR SDRAM Configuration Register

mww 0xD0001404 0x34143000 ;# Dunit Control Low Register

In kwbimage.cfg, the register address 0xffd01400 is a memory mapped address, corresponds with 0xD0001400 (bare metal address).

In JTAG config, you need to use 0xD0xxxxx. While in u-boot, those addresses are mapped to memory locations.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

It can be quite frustrating. I had a Pogo a few years ago that I tried and ultimately failed to repair. Spent a lot of time & effort on it. Messing with the JTAG & RaspberryPi. Probably 50 hours or more.

It's not really worth it, though, The Pogoplug E02 was a good device in its day, but that day is long past.
I bought several for $10 each, used them as media servers and internet download clients.

I used it for a media server running Debian for a long time, but the small 256MB of RAM was a major limitation. It locked up and had to be rebooted every couple of weeks.
Then I came across an article about a different tiny bookshelf computer, HP T620. Used, 4GB RAM, 16GB SSD price $30. (Just saw an Ebay listing 2 for $40. $20 each) Not much bigger than the Pogoplug.

Much much better than the Pogoplug. Runs standard full-blown Debian, latest release. Several USB ports, both 3.0 and 2.0.
I replaced each of my Pogoplugs with a T620, even though one T620 could have easily done all the work of all the Pogos. Didn't need to parcel out the work to different computers.

My son laughs every time we link the TV to the media server, because the HP still identifies itself as "Pogoplug Server".

I shed a little tear a few months ago when I finally threw my last 3 Pogoplugs in the trash.

bodhi Wrote:
-------------------------------------------------------

> In kwbimage.cfg, the register address 0xffd01400
> is a memory mapped address, corresponds with
> 0xD0001400 (bare metal address).
>
> In JTAG config, you need to use 0xD0xxxxx. While
> in u-boot, those addresses are mapped to memory
> locations.

Ok... thank you. I had assumed (clearly incorrectly) that the actual register map was different. So using the same bare metal addresses as they were makes sense.

That said, there are a few values that don't seem to map easily (or my low level hardware knowledge is rusty):

For the section below, there is only one register in the file that describes the v04 hardware. Do the other two registers (0xD0001428 and 0xD000147c) remain as they were?

 mww 0xffd01424 0x0000F07F ;# Updated (DDR DDR Controller Control High) Dunit Control High Register
 # mww 0xD0001428 0x00085520 ;# Dunit Control High Register
 # mww 0xD000147c 0x00008552 ;# Dunit Control High Register

The next set didn't seem to have a direct match, so I had added lines:

 mww 0xffd01428 0x00085520 ;# Added DDR2 ODT Read Timing (default values)
 mww 0xffd0147c 0x00008552 ;# Added DDR2 ODT Write Timing (default values)
 mww 0xFFD01500 0x00000000 ;# Added CS[0]n Base address to 0x0

Any guidance for these?



Edited 1 time(s). Last edit at 06/09/2025 10:40PM by shermbug.

rayvt Wrote:
-------------------------------------------------------

> It's not really worth it, though, The Pogoplug
> E02 was a good device in its day, but that day is
> long past.

I could not agree more! It is ludicrous that I am spending this much energy on an old and largely obsolete device. Especially because I got the unit for free from someone at work who was decluttering.

After I bricked it, I was willing to spend a very small amount of money (<<$10USD) and some time just for the experience of recovering a borked uboot (this could come in handy in my "other other" life as an OpenWrt expert). That's when I learned about the Pi JTAG method... thus free except for my time and some ancillary things (I needed some thinner bodge wires, but these have been on my "to buy" list for a while).

This totally isn't worth the effort for the device itself, but I'm finding educational value in the de-bricking process. (and I'll also admit to being a stubborn old engineer :-p).

And, it's worth reiterating that I seriously appreciate the efforts of those who have been willing to help me through this process! :-)

shermbug Wrote:
-------------------------------------------------------

> This totally isn't worth the effort for the device
> itself, but I'm finding educational value in the
> de-bricking process. (and I'll also admit to being
> a stubborn old engineer :-p).

Just to put a little more color to this: it fits in with a quote I saw once:

The fastest way to get an engineer to solve a problem is to tell them that it is unsolvable.

shermbug Wrote:

> That said, there are a few values that don't seem
> to map easily (or my low level hardware knowledge
> is rusty):

>
> For the section below, there is only one register
> in the file that describes the v04 hardware. Do
> the other two registers (0xD0001428 and
> 0xD000147c) remain as they were?
>

>  mww 0xffd01424 0x0000F07F ;# Updated (DDR DDR
> Controller Control High) Dunit Control High
> Register
>  # mww 0xD0001428 0x00085520 ;# Dunit Control High
> Register
>  # mww 0xD000147c 0x00008552 ;# Dunit Control High
> Register
>

>

OK. Let me boot up my Pogo V4 and get them.

>
> The next set didn't seem to have a direct match,
> so I had added lines:
>

>  mww 0xffd01428 0x00085520 ;# Added DDR2 ODT Read
> Timing (default values)
>  mww 0xffd0147c 0x00008552 ;# Added DDR2 ODT Write
> Timing (default values)
>  mww 0xFFD01500 0x00000000 ;# Added CS[0]n Base
> address to 0x0
>

>
> Any guidance for these?

If they are in the Pogo V4 kwbimage cfg, but not in the Pogo E02 JTAG cfg, and you should add them using the 0xD000xxxx notation.

So

mww 0xD0001428 0x00085520 ;# Added DDR2 ODT Read
mww 0xD000147c 0x00008552 ;# Added DDR2 ODT Write
mww 0xD0001500 0x00000000 ;# Added CS[0]n Base

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

> I could not agree more! It is ludicrous that I am
> spending this much energy on an old and largely
> obsolete device. Especially because I got the unit
> for free from someone at work who was
> decluttering.

You are the first person who attempt to JTAG the Pogo V4, afaik.

>
> After I bricked it, I was willing to spend a very
> small amount of money (<<$10USD) and some time
> just for the experience of recovering a borked
> uboot (this could come in handy in my "other
> other" life as an OpenWrt expert).

Absolutely. The experience is valuable, regardless of whether you will use it for some real tasks.

BTW, even though this is Debian forum, we love OpenWrt here :)

https://forum.doozan.com/list.php?4
https://forum.doozan.com/read.php?8,139643

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

> For the section below, there is only one register
> in the file that describes the v04 hardware. Do
> the other two registers (0xD0001428 and
> 0xD000147c) remain as they were?
>

>  mww 0xffd01424 0x0000F07F ;# Updated (DDR DDR
> Controller Control High) Dunit Control High
> Register
>  # mww 0xD0001428 0x00085520 ;# Dunit Control High
> Register
>  # mww 0xD000147c 0x00008552 ;# Dunit Control High
> Register
>

Yes, I would use the values in kwbimage. When I dump these while u-boot is running, they are different. So I would stay with values in Pogo V4 kwbimage.cfg, especially if they are the same as Pogo E02 already.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 1 time(s). Last edit at 06/10/2025 12:01AM by bodhi.

bodhi Wrote:
-------------------------------------------------------

> Yes, I would use the values in kwbimage. When I
> dump these while u-boot is running, they are
> different. So I would stay with values in Pogo V4
> kwbimage.cfg, especially if they are the same as
> Pogo E02 already.

Sorry if I confused the issue here.

This is what the E02 file contains (3 lines all labeled as "Dunit Control High Register"):
[code[
mww 0xD0001424 0x0000F17F ;# Dunit Control High Register
mww 0xD0001428 0x00085520 ;# Dunit Control High Register
mww 0xD000147c 0x00008552 ;# Dunit Control High Register
[/code[

And this is from the kwbimage.cfg file you provided:

DATA 0xffd01420 0x00000040	#  DDR Extended Mode
# bit0:    0,  DDR DLL enabled
# bit1:    0,  DDR drive strenght normal
# bit2:    0,  DDR ODT control lsd (disabled)
# bit5-3:  000, required
# bit6:    1,  DDR ODT control msb, (disabled)
# bit9-7:  000, required
# bit10:   0,  differential DQS enabled
# bit11:   0, required
# bit12:   0, DDR output buffer enabled
# bit31-13: 0 required

DATA 0xffd01424 0x0000F07F	#  DDR Controller Control High
# bit2-0:  111, required
# bit3  :  1  , MBUS Burst Chop disabled
# bit6-4:  111, required
# bit7  :  0
# bit8  :  0  , no sample stage
# bit9  :  0  , no half clock cycle addition to dataout
# bit10 :  0  , 1/4 clock cycle skew enabled for addr/ctl signals
# bit11 :  0  , 1/4 clock cycle skew disabled for write mesh
# bit15-12: 1111 required
# bit31-16: 0    required

DATA 0xffd01428 0x00085520	# DDR2 ODT Read Timing (default values)
DATA 0xffd0147c 0x00008552	# DDR2 ODT Write Timing (default values)

So, it looks like the labels for 2 of those registers are either different for the V4 or are incorrect on the E2. /(ODT Read and Write timing for the v4 vs 3 consecutive registers with the same label.... seems suspect). But given the offsets, it looks like these are the values I should use, and it looks like it also answers my question about "adding" additional registers.

With that in mind, I'll hopefully get back to this soon (not happening tonight) with new appreciation for these details :-).

shermbug,

> This is what the E02 file contains (3 lines all
> labeled as "Dunit Control High Register"):
> [code[
> mww 0xD0001424 0x0000F17F ;# Dunit Control High
> Register
> mww 0xD0001428 0x00085520 ;# Dunit Control High
> Register
> mww 0xD000147c 0x00008552 ;# Dunit Control High
> Register
> [/code[

These last 2 comments in Pogo E02 JTAG cfg were wrong.

>
> And this is from the kwbimage.cfg file you
> provided:
>

> DATA 0xffd01420 0x00000040	#  DDR Extended Mode
> # bit0:    0,  DDR DLL enabled
> # bit1:    0,  DDR drive strenght normal
> # bit2:    0,  DDR ODT control lsd (disabled)
> # bit5-3:  000, required
> # bit6:    1,  DDR ODT control msb, (disabled)
> # bit9-7:  000, required
> # bit10:   0,  differential DQS enabled
> # bit11:   0, required
> # bit12:   0, DDR output buffer enabled
> # bit31-13: 0 required
> 
> DATA 0xffd01424 0x0000F07F	#  DDR Controller
> Control High
> # bit2-0:  111, required
> # bit3  :  1  , MBUS Burst Chop disabled
> # bit6-4:  111, required
> # bit7  :  0
> # bit8  :  0  , no sample stage
> # bit9  :  0  , no half clock cycle addition to
> dataout
> # bit10 :  0  , 1/4 clock cycle skew enabled for
> addr/ctl signals
> # bit11 :  0  , 1/4 clock cycle skew disabled for
> write mesh
> # bit15-12: 1111 required
> # bit31-16: 0    required
> 
> DATA 0xffd01428 0x00085520	# DDR2 ODT Read Timing
> (default values)
> DATA 0xffd0147c 0x00008552	# DDR2 ODT Write Timing
> (default values)
>

>
> So, it looks like the labels for 2 of those
> registers are either different for the V4 or are
> incorrect on the E2. /(ODT Read and Write timing
> for the v4 vs 3 consecutive registers with the
> same label.... seems suspect).

I think it was copy/paste error.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)