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?