|
Re: HOW2: Repair Pogo E02 with Raspberry PI (1,2 or 3) JTAG and OpenOCD April 11, 2021 07:15AM |
Registered: 3 years ago Posts: 25 |
Ok. so I have this stock mtd partitions
from stock u-boot
I opened openocd and I gave the commands to flash the saved stock images for u-boot , uImage and uinitrd_m
After that I restart with sheevaplug_init and I have the stock u-boot output:
then I give saveenv
And after restart
So indeed, after saveenv there is no more bad CRC. but still what is with those errors:
Edited 1 time(s). Last edit at 04/11/2021 07:16AM by fratzicu.
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.
|
Re: HOW2: Repair Pogo E02 with Raspberry PI (1,2 or 3) JTAG and OpenOCD April 11, 2021 08:25AM |
Registered: 3 years ago Posts: 25 |
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.
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.
|
Re: HOW2: Repair Pogo E02 with Raspberry PI (1,2 or 3) JTAG and OpenOCD April 11, 2021 08:34AM |
Registered: 3 years ago Posts: 25 |
So it seems my u-boot layout is
Edited 2 time(s). Last edit at 04/13/2021 09:14AM by fratzicu.
================================================================================
## 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.
|
Re: HOW2: Repair Pogo E02 with Raspberry PI (1,2 or 3) JTAG and OpenOCD April 11, 2021 04:32PM |
Admin Registered: 13 years ago Posts: 18,576 |
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.
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.
|
Re: HOW2: Repair Pogo E02 with Raspberry PI (1,2 or 3) JTAG and OpenOCD April 13, 2021 09:08AM |
Registered: 3 years ago Posts: 25 |
|
Re: HOW2: Repair Pogo E02 with Raspberry PI (1,2 or 3) JTAG and OpenOCD May 05, 2023 12:42PM |
Registered: 12 months ago Posts: 1 |
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?
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
Any thoughts?
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?
