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

Update... still not working. Here's the latest:

 # 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
 # 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]
  
$_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 0xD0001400 0x43000618 ;# Updated DDR SDRAM Configuration Register
 mww 0xD0001404 0x34143000 ;# Updated Dunit Control Low Register
 mww 0xD0001408 0x11012227 ;# Updated DDR SDRAM Timing (Low) Register
 mww 0xD000140C 0x00000819 ;# Updated DDR SDRAM Timing (High) Register
 mww 0xD0001410 0x00000001 ;# Updated DDR SDRAM Address Control Register
 mww 0xD0001414 0x00000000 ;# Updated DDR SDRAM Open Pages Control Register
 mww 0xD0001418 0x00000000 ;# Updated DDR SDRAM Operation Register
 mww 0xD000141C 0x00000632 ;# Updated DDR SDRAM Mode Register
 mww 0xD0001420 0x00000040 ;# Updated DDR SDRAM Extended Mode Register
 mww 0xD0001424 0x0000F07F ;# Updated Dunit Control High Register
 mww 0xD0001428 0x00085520 ;# Updated (DDR2 ODT Read Timing (default values)) Dunit Control High Register
 mww 0xD000147c 0x00008552 ;# Updated (DDR2 ODT Write Timing (default values)) Dunit Control High Register
 mww 0xD0001500 0x00000000 ;# Added (CS[0]n Base address to 0x0)
 mww 0xD0001504 0x07FFFFF1 ;# Updated CS0n Size Register
 mww 0xD0001508 0x10000000 ;# CS1n Base Register
 mww 0xD000150C 0x00000000 ;# Updated CS1n Size Register
 mww 0xD0001514 0x00000000 ;# Updated CS2n Size Register
 mww 0xD000151C 0x00000000 ;# Updated CS3n Size Register
 mww 0xD0001494 0x00030000 ;# Updated DDR2 SDRAM ODT Control (Low) Register
 mww 0xD0001498 0x00000000 ;# Updated DDR2 SDRAM ODT Control (High) REgister
 mww 0xD000149C 0x0000e803 ;# Updated DDR2 Dunit ODT Control Register
 mww 0xD0001480 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
 }

And the output:

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

How about.

Instead of

nand write 0 uboot.kwb 0 oob_softecc_kw

Do

nand write 0 uboot.kwb 0

We don't really care to write oob or ecc. The u-boot image has no oob or ecc info on it. It does not seem relevant to the time out, but try it anyway.

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

Also see davidalfa working thread..

David wrote a really good thread about Dockstar mods and JTAG

https://forum.doozan.com/read.php?2,127079,127629#msg-127629

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

bodhi Wrote:
-------------------------------------------------------
> Do
>

> nand write 0 uboot.kwb 0
>

> We don't really care to write oob or ecc. The
> u-boot image has no oob or ecc info on it. It does
> not seem relevant to the time out, but try it
> anyway.


Unfortunately, no change with the new command. Same initial steps (no errors) and then the write command:

> nand write 0 uboot.kwb 0
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

I'll spend some time reading David's thread.

The most significant takeaway I found from David's Dockstar thread was that I should try OpenOCD 0.10 since he had problems with later versions wiring to NAND. So I downloaded a prebuilt version, but it didn't change anything.

I am using an Ubuntu build for the Pi. I had gone this route because I couldn't get OpenOCD to compile on Raspberry Pi OS. But, now that I was able to run a pre-built binary, maybe I should try Raspberry Pi OS + prebuilt OpenOCD 0.10. Theoretically all the files I've been working with/on should just transfer over. With that in mind, I just need to locate another microSD card for this purpose (I'd rather not need to wipe this card just in case I need to return back to Ubuntu).

I'll be working on that, but if you have any thoughts in the meantime, please let me know.

Well, no luck. Raspberry Pi OS installed on a card, OpenOCD 0.10 installed, files copied into place....

Same exact error.

At this point, I'm wondering if it's dead hardware -- presumably something actually wrong with the NAND. I found a thread (I'd have to search for it again) where someone else was having the same errors and tried a different physical unit with better results.

I'm honestly not sure what else it could be.

Thoughts??

> At this point, I'm wondering if it's dead hardware
> -- presumably something actually wrong with the
> NAND.

Could be.

You could try to load the u-boot image to memory and execute it (instead of flashing). If it runs, it'll be easier to see if NAND flash is really bad.

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

I had previously tried loading uboot into memory but it didn't seem to work (transferred but didn't execute). I'll try that again, though.

Please correct me if I'm wrong here... I assume that I just need to run

pogo_load_uboot

and then it should start executing and will have activity serial UART/console, right? Keep in mind also that I don't have the uboot environment in NAND anymore as I'm pretty sure I had wiped that at some point (trying to write that to NAND also fails/).

> Please correct me if I'm wrong here... I assume
> that I just need to run
>

> pogo_load_uboot
>

>
> and then it should start executing and will have
> activity serial UART/console, right?

Yes.

> Keep in mind
> also that I don't have the uboot environment in
> NAND anymore as I'm pretty sure I had wiped that
> at some point (trying to write that to NAND also
> fails/).

That's OK. We olnly need to run to the command prompt. And then if that's succesful, it would tell if NAND was initialized and can be flashed. The envs are not necessary at this point.

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

I spent several hours trying to get some signs of life out of the device, but to no avail.

I used the pogo_load_uboot function and it completed without errors, but nothing appears on the UART (I've checked for reversed Tx/Rx, and I did actually find that my Tx was shorted to ground, but fixed that and it didn't spring to life). I've also tried 3 different serial adapters.

Interestingly, when I run a continuity test on the Tx line vs ground, I'm seeing it as open (as it should be) before the board is initialized. But once I run pogo_init, it does register as a short. So the CPU is obviously being configured, but it seems to keep that pin low at all times (I don't have scope at home, though, so I can't be 100% certain).

Could we have an incorrect register setting that is preventing the serial line from operating as expected?

FWIW, I also tried a bunch of other things including uboot directly into memory and I even used different uboot files (such as those from OpenWrt). I also tried to load an intramfs OpenWrt image into RAM, but nothing seemed to work.

The one bit of success I had was using the opencd NAND tools -- I ran a bad block test which returned that it couldn't determine the erase status of the NAND. But after I explicitly erased the NAND, it recognized all of the blocks as erased and didn't report any errors.

But that notwithstanding, unless there are any other clues we can dig up, or other registers to configure/edit, I'm thinking that this may be a bit of a dead end.

Any thoughts?

In running from RAM test, did you run pogo_load_uboot right after pogo_init? do you have a log of this attempt?

> Could we have an incorrect register setting that
> is preventing the serial line from operating as
> expected?

That's not likely. The BootROM configured the serial port when the box is powered up (that's why we don't do anything regarding serial in kwbimage.cfg). And Kirkwood SoCs have the same serial configuration. If the Pogo E02 JTAG cfg has no problem with serial then I can't see why the Pogo V4 would.

> The one bit of success I had was using the opencd
> NAND tools -- I ran a bad block test which
> returned that it couldn't determine the erase
> status of the NAND. But after I explicitly erased
> the NAND, it recognized all of the blocks as
> erased and didn't report any errors.
>
> But that notwithstanding, unless there are any
> other clues we can dig up, or other registers to
> configure/edit, I'm thinking that this may be a
> bit of a dead end.
>
> Any thoughts?

Sorry, I don't have any other idea.

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



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

Here's the log... In this case, I actually manually ran each line of the pogo_load_uboot function that is defined in the pogo.cfg file.

Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Open On-Chip Debugger
> pogo_init         
target halted in Thumb state due to debug-request, current mode: Supervisor
cpsr: 0x400000f3 pc: 0xffff0ba6
MMU: enabled, D-Cache: enabled, I-Cache: enabled
> load_image uboot.kwb
524288 bytes written at address 0x00000000
downloaded 524288 bytes in 56.624947s (9.042 KiB/s)

> verify_image uboot.kwb
verified 524288 bytes in 2.988857s (171.303 KiB/s)

> 
> resume 0x800200

Also worth mentioning...

I have my serial adapter setup for 3.3V and settings 115200 8N1. The adapter itself is plugged into the Pi and enumerates as ttyUSB0. And I'm using minicom as my terminal application.

> load_image uboot.kwb
524288 bytes written at address 0x00000000
downloaded 524288 bytes in 56.624947s (9.042 KiB/s)

> verify_image uboot.kwb
verified 524288 bytes in 2.988857s (171.303 KiB/s)

> 
> resume 0x800200

That's fishy. The load address should be 0x800000. resume 0x800200 meaning jump to 0x800200 and execute (where u-boot image was loaded with offset 0x200 for the image header).

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

The commands were pulled directly from the original post's pogo_load_uboot function, no modifications made.

Based on your comment, though, I'm going to try resume 0x200 since the address offsets are not as expected. (basically, an attempt to nullify the difference between the actual load address 0x000000 and the typically expected load address 0x800000.

to be continued...

No change based on the 0x0 load address. and 0x200 resume address.

 load_image uboot.kwb      
524288 bytes written at address 0x00000000
downloaded 524288 bytes in 56.629524s (9.041 KiB/s)

> resume 0x200

I also tried this:

> load_image uboot.kwb 0x800000
524288 bytes written at address 0x00800000
downloaded 524288 bytes in 56.611168s (9.044 KiB/s)

> resume 0x800200

But the serial console remains quiet.

If it were in u-boot command prompt, we would run go. Not sure what resume does here.

go 0x800200

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



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

The OpenOCD environment doesn't have "go", but resume should be the same thing... it's just resuming from the halted state at the specified address.

> But the serial console remains quiet.

I think the serial port was fried (damaged) and u-boot could not start because of that.

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

I'm inclined to agree... hardware failure at this point seems pretty likely. I wonder if uboot fails or if it's actually running but with no active I/O. ("What good is a phone call if you're unable to speak")

That said, I don't know why I can't write to the NAND... probably doesn't matter much if serial can't come up.

I'm thinking it's probably not worth spending any more time on this device given that I got it for free, it wasn't worth much to begin with, and I've already spent tons of energy on this.

On the plus side, this has been a really good learning experience to get JTAG up and running on the Pi and generally having the ability to use that interface to talk to a device. This may serve me well in the future, and I also can advise users about this forum if they run into similar issues with uboot and the like.

Thanks again for all your help!!!

shermbug,

> On the plus side, this has been a really good
> learning experience to get JTAG up and running on
> the Pi and generally having the ability to use
> that interface to talk to a device. This may serve
> me well in the future, and I also can advise users
> about this forum if they run into similar issues
> with uboot and the like.
>

Indeed.

Next time you have some free time on your hand, you can try this on a working Pogo v4 or Mobile.

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

If/when I come across some additional Pogo v4 / Mobile hardware, I will :-).

shermbug Wrote:
-------------------------------------------------------
> If/when I come across some additional Pogo v4 /
> Mobile hardware, I will :-).

If you're located in the US I can send you via US Mail a Smartenit Harmony P2 which is essentially a relabeled Pogoplug V4 Mobile where they used the serial port to drive Zigbee card. The serial port can still be used after disconnecting the Zigbee card. I have a box of these devices, so if you are interested just sen me a PM.

Ray

I am in the USA, yes. Thank you for that offer!! I may take you up on it, but I don't actually need the device for more than just experimentation (I had been attempting to install OpenWrt on it when I killed uboot). So, if the device needs a home, sure, I'll take it. But if you have any use for it, there is no need.

Meanwhile, are you also a member of the OpenWrt forum (with a similar, but not identical username)?

rayknight Wrote:
-------------------------------------------------------
> shermbug Wrote:
> -------------------------------------------------------
> > If/when I come across some additional Pogo v4 /
> > Mobile hardware, I will :-).
>
> If you're located in the US I can send you via US
> Mail a
> Smartenit
> Harmony P2 which is essentially a relabeled
> Pogoplug V4 Mobile where they used the serial port
> to drive Zigbee card. The serial port can still
> be used after disconnecting the Zigbee card. I
> have a box of these devices, so if you are
> interested just sen me a PM.
>
> Ray

Thumbs up!

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



Edited 1 time(s). Last edit at 06/15/2025 08:55PM by bodhi.

so.... I'm now beginning to question the serial adapters that I have. They were working when I started this whole thing, but I'm beginning to wonder if something is wrong with them.

So... when I get some time, I'll crack open a router with its UART pins exposed (I've got an ER-X handy that should be perfect) and see there is appropriate I/O in my serial console.

It would be both annoying and embarrassing if my serial adapters were to blame some of this. But... the NAND write failures are still likely real. TBD.

Ok.... feeling like a real idiot now. The serial adapter plugged into the Pi wasn't doing anything in Minicom, but it was when I plugged it into my Mac with the SerialTools app.

A bunch of troubleshooting later and it appears you need to run sudo minicom on the pi, else there will be no output. My other adapters don't appear to be working, though.... but I know I have one good one.

I'll try loading uboot again onto the pogo as soon as I get a chance (I need to fix a JTAG bodge wire that broke off today). I'll keep you posted.

You should look into using tio instead of minicom for serial access to devices. Just the first part of the Readme had me hooked after someone on an embedded board mentioned it as an alternative to screen:

Quote

Easily connect to serial TTY devices
Sensible defaults (115200 8n1)
Automatic connection management

Automatic detection of serial ports
Automatic reconnect
Automatically connect to first new appearing serial device
Automatically connect to latest registered serial device

rayvt Wrote:
-------------------------------------------------------
> 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.

@rayvt thanks for the tip on the HP T620. After putting one in my ebay cart for a few days but not pulling the trigger, the seller offered a price of just under $20 and free shipping for one, so I pulled the trigger. My Pogo's are sadly getting long in the tooth, especially the older models. Compiling has become more difficult. I look forward to playing around with the T620.



Edited 1 time(s). Last edit at 06/18/2025 08:24AM by bluzfanmr1.