HOW2: Repair Pogo E02 with Raspberry PI (1,2 or 3) JTAG and OpenOCD
Posted by joerg_999
|
Re: HOW2: Repair Pogo E02 with Raspberry PI (1,2 or 3) JTAG and OpenOCD December 18, 2019 10:19PM |
Admin Registered: 13 years ago Posts: 18,549 |
Ray,
I think David has a good idea. These units indeed have a not-so-good power supply. If you could, measure the power with multi-meter before spending more time on something else.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
Quote
So anyway, I then switched the JTAG cable back to the bricked Pogoplug. Nada. I think that this unit had a hardware failure. The JTAG on it used to work but now it does not work anymore.
Quote
daviddyer
These machines are pretty solid, but the power supplies are not. Maybe you need to get a good power supply and try again.
I think David has a good idea. These units indeed have a not-so-good power supply. If you could, measure the power with multi-meter before spending more time on something else.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
|
Re: HOW2: Repair Pogo E02 with Raspberry PI (1,2 or 3) JTAG and OpenOCD January 04, 2020 03:04PM |
Registered: 11 years ago Posts: 18 |
The power supply is good, I metered it and also swapped with a good Pogoplug. I think this board just suddenly went bad. Odd coincidence, though. I flashed a new u-boot build that I am working on---and it never came back. Wierd that this board died dead at the exact same time I flashed a new uboot. It's dead, though...even JTAG doesn't work on it, but does work on another Pogoplug...so I know the JTAG cable & setup works.
**shrug** I guess I'll just keep the power supply and discard the rest.
Thanks for the suggestions & help.
In other news: Really odd things happen with trying to load a new uboot into memory vs. flashing it and then running it from the flash. Yeah, the DENX U-Boot people say that's not supported. But you'd really like to do u-boot development that way, to avoid the risk of bricking your device with a bad u-boot.
With the bodhi 2017 uboot in the flash, stop the boot and load the newly-built uboot.bin into ram and then jump to it. About 90% of the time it works with the DENX ftp://ftp.denx.de/pub/u-boot/u-boot-2019.10.tar.bz2 build. But only 1% of the time does this work on a build from bodhi's 2017 uboot. Older versions, like the 2010 & 2012 uboot work sometimes and fail sometimes.
Code:
usb start
load usb 0:1 0x600000 /u-boot.2019.12.30.bin
go 0x600000
I can't believe I spent so much time on a $10 computer! But I was able to do the uboot upgrades that I wanted to do, even though I lost one Pogoplug.
**shrug** I guess I'll just keep the power supply and discard the rest.
Thanks for the suggestions & help.
In other news: Really odd things happen with trying to load a new uboot into memory vs. flashing it and then running it from the flash. Yeah, the DENX U-Boot people say that's not supported. But you'd really like to do u-boot development that way, to avoid the risk of bricking your device with a bad u-boot.
With the bodhi 2017 uboot in the flash, stop the boot and load the newly-built uboot.bin into ram and then jump to it. About 90% of the time it works with the DENX ftp://ftp.denx.de/pub/u-boot/u-boot-2019.10.tar.bz2 build. But only 1% of the time does this work on a build from bodhi's 2017 uboot. Older versions, like the 2010 & 2012 uboot work sometimes and fail sometimes.
Code:
usb start
load usb 0:1 0x600000 /u-boot.2019.12.30.bin
go 0x600000
I can't believe I spent so much time on a $10 computer! But I was able to do the uboot upgrades that I wanted to do, even though I lost one Pogoplug.
|
Re: HOW2: Repair Pogo E02 with Raspberry PI (1,2 or 3) JTAG and OpenOCD January 06, 2020 04:37AM |
Admin Registered: 13 years ago Posts: 18,549 |
> In other news: Really odd things happen with
> trying to load a new uboot into memory vs.
> flashing it and then running it from the flash.
> Yeah, the DENX U-Boot people say that's not
> supported. But you'd really like to do u-boot
> development that way, to avoid the risk of
> bricking your device with a bad u-boot.
>
> With the bodhi 2017 uboot in the flash, stop the
> boot and load the newly-built uboot.bin into ram
> and then jump to it. About 90% of the time it
> works with the DENX
> ftp://ftp.denx.de/pub/u-boot/u-boot-2019.10.tar.bz2
> build. But only 1% of the time does this work on
> a build from bodhi's 2017 uboot. Older versions,
> like the 2010 & 2012 uboot work sometimes and fail
> sometimes.
That's really not odd at all. That more or less how it has been (since 2012) regarding chainloading uboot.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
> trying to load a new uboot into memory vs.
> flashing it and then running it from the flash.
> Yeah, the DENX U-Boot people say that's not
> supported. But you'd really like to do u-boot
> development that way, to avoid the risk of
> bricking your device with a bad u-boot.
>
> With the bodhi 2017 uboot in the flash, stop the
> boot and load the newly-built uboot.bin into ram
> and then jump to it. About 90% of the time it
> works with the DENX
> ftp://ftp.denx.de/pub/u-boot/u-boot-2019.10.tar.bz2
> build. But only 1% of the time does this work on
> a build from bodhi's 2017 uboot. Older versions,
> like the 2010 & 2012 uboot work sometimes and fail
> sometimes.
That's really not odd at all. That more or less how it has been (since 2012) regarding chainloading uboot.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
|
Re: HOW2: Repair Pogo E02 with Raspberry PI (1,2 or 3) JTAG and OpenOCD May 30, 2020 11:14AM |
Registered: 10 years ago Posts: 55 |
|
Re: HOW2: Repair Pogo E02 with Raspberry PI (1,2 or 3) JTAG and OpenOCD May 30, 2020 04:35PM |
Admin Registered: 13 years ago Posts: 18,549 |
enki,
No need for JTAG:
https://forum.doozan.com/read.php?3,51739,51919#msg-51919
And you can use kwboot version that already installed in your serial console Linux host.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
Edited 1 time(s). Last edit at 05/30/2020 04:38PM by bodhi.
No need for JTAG:
https://forum.doozan.com/read.php?3,51739,51919#msg-51919
And you can use kwboot version that already installed in your serial console Linux host.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
Edited 1 time(s). Last edit at 05/30/2020 04:38PM by bodhi.
|
Re: HOW2: Repair Pogo E02 with Raspberry PI (1,2 or 3) JTAG and OpenOCD May 30, 2020 05:27PM |
Admin Registered: 13 years ago Posts: 18,549 |
enki,
I answered your post above.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
Edited 1 time(s). Last edit at 05/30/2020 05:27PM by bodhi.
I answered your post above.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
Edited 1 time(s). Last edit at 05/30/2020 05:27PM by bodhi.
|
Re: HOW2: Repair Pogo E02 with Raspberry PI (1,2 or 3) JTAG and OpenOCD May 30, 2020 05:32PM |
Registered: 10 years ago Posts: 55 |
Hi Bodhi,
First thank you for prompt reply. I have tried the followings:
0. connect usb cable to serial console of the NSA320s; lsusb shows:
Bus 003 Device 010: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
1. turned on NSA320s by pressing button;
2. run 'kwboot -t -B 115200 /dev/ttyUSB0 -b uboot.2017.07-tld-1.nsa310s.mtd0.kwb -p' command from a Linux laptop.
Sending boot message. Please reboot the target...-^C
and wait but nothing happens ... I had to ^C to return to prompt.
Can I do any other checks ?
First thank you for prompt reply. I have tried the followings:
0. connect usb cable to serial console of the NSA320s; lsusb shows:
Bus 003 Device 010: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
1. turned on NSA320s by pressing button;
2. run 'kwboot -t -B 115200 /dev/ttyUSB0 -b uboot.2017.07-tld-1.nsa310s.mtd0.kwb -p' command from a Linux laptop.
Sending boot message. Please reboot the target...-^C
and wait but nothing happens ... I had to ^C to return to prompt.
Can I do any other checks ?
|
Re: HOW2: Repair Pogo E02 with Raspberry PI (1,2 or 3) JTAG and OpenOCD May 30, 2020 05:34PM |
Admin Registered: 13 years ago Posts: 18,549 |
enki,
Let's move the conversation to:
https://forum.doozan.com/read.php?3,51739
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
Quote
First thank you for prompt reply. I have tried the followings:
0. connect usb cable to serial console of the NSA320s; lsusb shows:
Bus 003 Device 010: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
1. turned on NSA320s by pressing button;
2. run 'kwboot -t -B 115200 /dev/ttyUSB0 -b uboot.2017.07-tld-1.nsa310s.mtd0.kwb -p' command from a Linux laptop.
Sending boot message. Please reboot the target...-^C
and wait but nothing happens ... I had to ^C to return to prompt.
Can I do any other checks ?
Let's move the conversation to:
https://forum.doozan.com/read.php?3,51739
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
|
Re: HOW2: Repair Pogo E02 with Raspberry PI (1,2 or 3) JTAG and OpenOCD November 26, 2020 05:30PM |
Registered: 3 years ago Posts: 28 |
hello,
I am tring to recover my pogo plug e02.
i bought it used on ebay, i never had it working. I almost got Dohi's debian rootfs to load, through tftpboot, but was stuck on loadin kernel.
I was impatient and tried frist thing i saw for flashing u-boot from openwrt forum. this made device corrupt nand enven further than it was.
I am left with jtag as my last hope ( Help me Old Ben One, you are our only hope)
I followed the first post and let openocd compile on my pi, but when I did a test run of the binary, without any connections I got some unexpected settings deprication errors. I wanted to ask if these are ok to continue or no.
I am tring to recover my pogo plug e02.
i bought it used on ebay, i never had it working. I almost got Dohi's debian rootfs to load, through tftpboot, but was stuck on loadin kernel.
I was impatient and tried frist thing i saw for flashing u-boot from openwrt forum. this made device corrupt nand enven further than it was.
I am left with jtag as my last hope ( Help me Old Ben One, you are our only hope)
I followed the first post and let openocd compile on my pi, but when I did a test run of the binary, without any connections I got some unexpected settings deprication errors. I wanted to ask if these are ok to continue or no.
pi@raspberrypi:~ $ sudo openocd -f pogo.cfg Open On-Chip Debugger 0.10.0+dev-01514-ga8edbd020-dirty (2020-11-26-10:55) Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html DEPRECATED! use 'adapter driver' not 'interface' DEPRECATED! use 'adapter speed' not 'adapter_khz' 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 Error: JTAG scan chain interrogation failed: all zeroes Error: Check JTAG interface, timings, target power, etc. Error: Trying to use configured scan chain anyway... Error: feroceon.cpu: IR capture error; saw 0x00 not 0x01 Warn : Bypassing JTAG setup events due to errors Info : Embedded ICE version 0 Info : feroceon.cpu: hardware has 1 breakpoint/watchpoint unit Error: unexpected Feroceon EICE version signature Info : starting gdb server for feroceon.cpu on 3333 Info : Listening on port 3333 for gdb connections pogp_init pogo_init soft_reset_halt nand probe 0 ^Cshutdown command invoked pi@raspberrypi:~ $
|
Re: HOW2: Repair Pogo E02 with Raspberry PI (1,2 or 3) JTAG and OpenOCD November 26, 2020 10:59PM |
Registered: 3 years ago Posts: 28 |
|
Re: HOW2: Repair Pogo E02 with Raspberry PI (1,2 or 3) JTAG and OpenOCD November 26, 2020 11:53PM |
Registered: 7 years ago Posts: 366 |
|
Re: HOW2: Repair Pogo E02 with Raspberry PI (1,2 or 3) JTAG and OpenOCD November 27, 2020 06:32AM |
Registered: 3 years ago Posts: 28 |
Maybe I need an older version of raspian OS.
openOCD gives deprication errors. and fails to connect to JTAG.
I changed the pogo.cfg lines
to
Still do not have the halt status, and nand probe fails to get device
Ive noticed from the example output from 'T1' my openOCD is not declaring gpio pins.
I am on rasbian buster. And suspect changes to the core of rasbian gpio may have been changed. I am going to try and start over with Jessie instead of buster, hope it helps
Edited 5 time(s). Last edit at 11/27/2020 06:52PM by mrmazak.
openOCD gives deprication errors. and fails to connect to JTAG.
pi@raspberrypi:~ $ telnet 127.0.0.1 4444 Trying 127.0.0.1... Connected to 127.0.0.1. Escape character is '^]'. Open On-Chip Debugger > pogo_init DEPRECATED! use 'adapter [de]assert' not 'jtag_reset' unexpected Feroceon EICE version signature DEPRECATED! use 'adapter [de]assert' not 'jtag_reset' Halt timed out, wake up GDB. timed out while waiting for target halted > soft_reset_halt requesting target halt and executing a soft reset Failed to halt CPU after 1 sec Halt timed out, wake up GDB. > pogo_init DEPRECATED! use 'adapter [de]assert' not 'jtag_reset' unexpected Feroceon EICE version signature DEPRECATED! use 'adapter [de]assert' not 'jtag_reset' Halt timed out, wake up GDB. timed out while waiting for target halted > soft_reset_halt requesting target halt and executing a soft reset Failed to halt CPU after 1 sec Halt timed out, wake up GDB. > nand probe 0 NAND flash access requires halted target NAND flash access requires halted target NAND flash access requires halted target NAND flash access requires halted target NAND flash access requires halted target NAND flash access requires halted target unknown NAND flash device found, manufacturer id: 0x00 device id: 0x00 > pogo_init DEPRECATED! use 'adapter [de]assert' not 'jtag_reset' unexpected Feroceon EICE version signature DEPRECATED! use 'adapter [de]assert' not 'jtag_reset' Halt timed out, wake up GDB. timed out while waiting for target halted
I changed the pogo.cfg lines
jtag_reset 0 1 feroceon.cpu arp_examine halt 0 jtag_reset 0 0
to
# jtag_reset 0 1 adapter assert srst feroceon.cpu arp_examine halt 0 # jtag_reset 0 0 adapter deassert srst
Still do not have the halt status, and nand probe fails to get device
Ive noticed from the example output from 'T1' my openOCD is not declaring gpio pins.
I am on rasbian buster. And suspect changes to the core of rasbian gpio may have been changed. I am going to try and start over with Jessie instead of buster, hope it helps
Edited 5 time(s). Last edit at 11/27/2020 06:52PM by mrmazak.
|
Re: HOW2: Repair Pogo E02 with Raspberry PI (1,2 or 3) JTAG and OpenOCD November 27, 2020 09:56PM |
Registered: 3 years ago Posts: 28 |
I got the same errors with Jessie. and current build of openOCD.(v10)
I tried to build with the other branch (v6.0.1) on github, that didnt go so well. It gave error that the only interface programed in build was buspirate.
I got little further with the apt-get repository version (v8) but I had to comment out some config lines because errors said unknown command. But it did show connection to the nand , i think.
Now I guess I can try repository build on my original Buster os PI. But It would be great I someone has a verified repo of correct working build repo of openOCD that this guide used.
I did find snapshots packages on sourceforge for openOCD, and built with a bundle from 2018, in did build a version 9.0, but also did not connect.
I did also build from an updated got link, and got v10 again, and was able to (occasionally) get a halt in 'jazzel' mode, which results in a 'jazzel handling broken' message.
Didn't see this mode in my quick search.
This cheap pc board sure is got me spending too much time working on it.
Edited 1 time(s). Last edit at 11/28/2020 02:02PM by mrmazak.
I tried to build with the other branch (v6.0.1) on github, that didnt go so well. It gave error that the only interface programed in build was buspirate.
I got little further with the apt-get repository version (v8) but I had to comment out some config lines because errors said unknown command. But it did show connection to the nand , i think.
Setting up openocd (0.8.0-4+deb7u1) ... pi@raspberrypi:~ $ sudo openocd -f pogo.cfgOpen On-Chip Debugger 0.8.0 (2018-01-22-05:24) Licensed under GNU GPL v2 For bug reports, read http://openocd.sourceforge.net/doc/doxygen/bugs.html Info : only one transport option; autoselect 'jtag' Runtime Error: /usr/share/openocd/scripts/interface/raspberrypi123-native.cfg:18: invalid command name "bcm2835gpio_peripheral_base" in procedure 'script' at file "embedded:startup.tcl", line 58 at file "pogo.cfg", line 10 at file "/usr/share/openocd/scripts/interface/raspberrypi123-native.cfg", line 18 pi@raspberrypi:~ $ sudo nano /usr/share/openocd/scripts/board/pogo.cfgpi@raspberrypi:~ $ sudo nano /usr/share/openocd/scripts/board/pogo.cfg pi@raspberrypi:~ $ sudo nano /usr/share/openocd/scripts/interface/raspberrypi123-native.cfg pi@raspberrypi:~ $ sudo openocd -f pogo.cfgOpen On-Chip Debugger 0.8.0 (2018-01-22-05:24) Licensed under GNU GPL v2 For bug reports, read http://openocd.sourceforge.net/doc/doxygen/bugs.html Info : only one transport option; autoselect 'jtag' BCM2835 GPIO config: tck = 11, tms = 25, tdi = 10, tdi = 9 Runtime Error: /usr/share/openocd/scripts/interface/raspberrypi123-native.cfg:45: invalid command name "bcm2835gpio_swd_nums" in procedure 'script' at file "embedded:startup.tcl", line 58 at file "pogo.cfg", line 10 at file "/usr/share/openocd/scripts/interface/raspberrypi123-native.cfg", line 45 pi@raspberrypi:~ $ sudo nano /usr/share/openocd/scripts/interface/raspberrypi123-native.cfg pi@raspberrypi:~ $ sudo openocd -f pogo.cfgOpen On-Chip Debugger 0.8.0 (2018-01-22-05:24) Licensed under GNU GPL v2 For bug reports, read http://openocd.sourceforge.net/doc/doxygen/bugs.html Info : only one transport option; autoselect 'jtag' BCM2835 GPIO config: tck = 11, tms = 25, tdi = 10, tdi = 9 BCM2835 GPIO config: trst = 7 trst_only separate trst_push_pull adapter speed: 200 kHz trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain connect_deassert_srst adapter_nsrst_delay: 200 jtag_ntrst_delay: 200 Warn : use 'feroceon.cpu' as target identifier, not '0' pogo_load_uboot Info : clock speed 200 kHz Error: JTAG scan chain interrogation failed: all ones Error: Check JTAG interface, timings, target power, etc. Error: Trying to use configured scan chain anyway... Error: feroceon.cpu: IR capture error; saw 0x0f not 0x01 Warn : Bypassing JTAG setup events due to errors Info : Embedded ICE version 15 Info : feroceon.cpu: hardware has 1 breakpoint/watchpoint unit Error: unexpected Feroceon EICE version signature Warn : ThumbEE -- incomplete support Info : accepting 'telnet' connection from 4444 Error: unexpected Feroceon EICE version signature requesting target halt and executing a soft reset Error: Jazelle state handling is BROKEN! target state: halted target halted in Jazelle state due to debug-request, current mode: Supervisor cpsr: 0xffffffd3 pc: 0x00000000 MMU: disabled, D-Cache: disabled, I-Cache: disabled Error: unknown NAND flash device found, manufacturer id: 0xff device id: 0xff in procedure 'nand' Error: unexpected Feroceon EICE version signature Error: unknown NAND flash device found, manufacturer id: 0xff device id: 0xff in procedure 'nand' requesting target halt and executing a soft reset Error: Jazelle state handling is BROKEN! target state: halted target halted in Jazelle state due to debug-request, current mode: Supervisor cpsr: 0xffffffd3 pc: 0x00000000 MMU: disabled, D-Cache: disabled, I-Cache: disabled
Now I guess I can try repository build on my original Buster os PI. But It would be great I someone has a verified repo of correct working build repo of openOCD that this guide used.
I did find snapshots packages on sourceforge for openOCD, and built with a bundle from 2018, in did build a version 9.0, but also did not connect.
I did also build from an updated got link, and got v10 again, and was able to (occasionally) get a halt in 'jazzel' mode, which results in a 'jazzel handling broken' message.
Didn't see this mode in my quick search.
This cheap pc board sure is got me spending too much time working on it.
Edited 1 time(s). Last edit at 11/28/2020 02:02PM by mrmazak.
|
Re: HOW2: Repair Pogo E02 with Raspberry PI (1,2 or 3) JTAG and OpenOCD December 07, 2020 03:43PM |
Registered: 9 years ago Posts: 94 |
Hi mrmazak
i did this repair job in the middle of 2015, but it should work also with new raspbian an aktual openocd. The only thing i didnt try is with newer Pis.
The last one was:(B,B+700Mhz, RPI2 900Mhz and RPI3 1200Mhz) with simply standard clock Speed of the Raspis.
You shouldnt change anything in discription and workflow - folllow simply straight forward the instructions on page 1 (inkluding my GPIOs and the right cabel setting to your Pogo) and you will succeed like all the other people in this thread.
But be warned : jtag should be the last option and cause always some riscs.
Edited 2 time(s). Last edit at 12/07/2020 04:03PM by joerg_999.
i did this repair job in the middle of 2015, but it should work also with new raspbian an aktual openocd. The only thing i didnt try is with newer Pis.
The last one was:(B,B+700Mhz, RPI2 900Mhz and RPI3 1200Mhz) with simply standard clock Speed of the Raspis.
You shouldnt change anything in discription and workflow - folllow simply straight forward the instructions on page 1 (inkluding my GPIOs and the right cabel setting to your Pogo) and you will succeed like all the other people in this thread.
But be warned : jtag should be the last option and cause always some riscs.
Edited 2 time(s). Last edit at 12/07/2020 04:03PM by joerg_999.
|
Re: HOW2: Repair Pogo E02 with Raspberry PI (1,2 or 3) JTAG and OpenOCD December 09, 2020 06:14PM |
Registered: 3 years ago Posts: 28 |
joerg_999 Wrote:
-------------------------------------------------------
> Hi mrmazak
> i did this repair job in the middle of 2015, but
> it should work also with new raspbian an aktual
> openocd. The only thing i didnt try is with newer
> Pis.
> The last one was:(B,B+700Mhz, RPI2 900Mhz and RPI3
> 1200Mhz) with simply standard clock Speed of the
> Raspis.
> You shouldnt change anything in discription and
> workflow - folllow simply straight forward the
> instructions on page 1 (inkluding my GPIOs and the
> right cabel setting to your Pogo) and you will
> succeed like all the other people in this thread.
>
> But be warned : jtag should be the last
> option and cause always some riscs.
Thank you sir.
I did not get device to work. One time during experimenting with openOCD config settings. Seemed to show am actual connection to device, but failed to write to mtd#.
I purchased the device used, and it was broken' when received, so no real loss. The seller refunded purchase because they sold it as 'working' bit was not and they admitted it was broke to begin with.
-------------------------------------------------------
> Hi mrmazak
> i did this repair job in the middle of 2015, but
> it should work also with new raspbian an aktual
> openocd. The only thing i didnt try is with newer
> Pis.
> The last one was:(B,B+700Mhz, RPI2 900Mhz and RPI3
> 1200Mhz) with simply standard clock Speed of the
> Raspis.
> You shouldnt change anything in discription and
> workflow - folllow simply straight forward the
> instructions on page 1 (inkluding my GPIOs and the
> right cabel setting to your Pogo) and you will
> succeed like all the other people in this thread.
>
> But be warned : jtag should be the last
> option and cause always some riscs.
Thank you sir.
I did not get device to work. One time during experimenting with openOCD config settings. Seemed to show am actual connection to device, but failed to write to mtd#.
I purchased the device used, and it was broken' when received, so no real loss. The seller refunded purchase because they sold it as 'working' bit was not and they admitted it was broke to begin with.
|
Re: HOW2: Repair Pogo E02 with Raspberry PI (1,2 or 3) JTAG and OpenOCD April 03, 2021 04:02PM |
Registered: 3 years ago Posts: 25 |
Hi,
Today I think I succeeded to connect to lacie wireless space using jtag port with the standard arm pinout (20 pin).
I used the following config files:
board: /usr/share/openocd/scripts/board/sheevaplug.cfg in which I modified interface :tumpa.cfg
interface: /usr/share/openocd/scripts/interface/tumpa.cfg (source [find interface/ftdi/tumpa.cfg]) in /usr/share/openocd/scripts/board/sheevaplug.cfg
target: /usr/share/openocd/scripts/target/feroceon.cfg (source [find target/feroceon.cfg]) in /usr/share/openocd/scripts/board/sheevaplug.cfg
actually, I copied sheevaplug.cfg to wspace.cfg and modified only the line source [find interface/ftdi/tumpa.cfg]
then gave the command
made a little progress...
this is shown in the openocd terminal
and this is shown in the telnet terminal
So i'm feeling like making progress. Now I need some guidance on backing up and flashing.
Kind regards
If I give the command
Edited 1 time(s). Last edit at 04/03/2021 04:05PM by fratzicu.
Today I think I succeeded to connect to lacie wireless space using jtag port with the standard arm pinout (20 pin).
I used the following config files:
board: /usr/share/openocd/scripts/board/sheevaplug.cfg in which I modified interface :tumpa.cfg
interface: /usr/share/openocd/scripts/interface/tumpa.cfg (source [find interface/ftdi/tumpa.cfg]) in /usr/share/openocd/scripts/board/sheevaplug.cfg
target: /usr/share/openocd/scripts/target/feroceon.cfg (source [find target/feroceon.cfg]) in /usr/share/openocd/scripts/board/sheevaplug.cfg
actually, I copied sheevaplug.cfg to wspace.cfg and modified only the line source [find interface/ftdi/tumpa.cfg]
then gave the command
sudo openocd -f /usr/share/openocd/scripts/board/wspace.cfgand got the output
Open On-Chip Debugger 0.10.0
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
none separate
Info : auto-selecting first available session transport "jtag". To override use 'transport select <transport>'.
trst_and_srst separate srst_gates_jtag trst_push_pull srst_push_pull connect_deassert_srst
adapter_nsrst_delay: 200
jtag_ntrst_delay: 200
adapter speed: 2000 kHz
dcc downloads are enabled
Warn : use 'feroceon.cpu' as target identifier, not '0'
sheevaplug_load_uboot
Info : clock speed 2000 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
made a little progress...
telnet 127.0.0.1 4444
this is shown in the openocd terminal
Open On-Chip Debugger 0.10.0
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
none separate
Info : auto-selecting first available session transport "jtag". To override use 'transport select <transport>'.
trst_and_srst separate srst_gates_jtag trst_push_pull srst_push_pull connect_deassert_srst
adapter_nsrst_delay: 200
jtag_ntrst_delay: 200
adapter speed: 2000 kHz
dcc downloads are enabled
Warn : use 'feroceon.cpu' as target identifier, not '0'
sheevaplug_load_uboot
Info : clock speed 2000 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 : accepting 'telnet' connection on tcp/4444
invalid command name "scan_chain\"
TapName Enabled IdCode Expected IrLen IrCap IrMask
-- ------------------- -------- ---------- ---------- ----- ----- ------
0 feroceon.cpu Y 0x20a023d3 0x20a023d3 4 0x01 0x0f
Error: NAND flash access requires halted target
Error: NAND flash access requires halted target
Error: NAND flash access requires halted target
Error: NAND flash access requires halted target
Error: NAND flash access requires halted target
Error: NAND flash access requires halted target
Error: unknown NAND flash device found, manufacturer id: 0x02 device id: 0x02
invalid command name "monitor"
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0x000000d3 pc: 0xffff0000
MMU: disabled, D-Cache: disabled, I-Cache: disabled
TapName Enabled IdCode Expected IrLen IrCap IrMask
-- ------------------- -------- ---------- ---------- ----- ----- ------
0 feroceon.cpu Y 0x20a023d3 0x20a023d3 4 0x01 0x0f
NAND flash device 'NAND 128MiB 3.3V 8-bit (Samsung)' found
#0: NAND 128MiB 3.3V 8-bit (Samsung) pagesize: 2048, buswidth: 8,
blocksize: 131072, blocks: 1024
and this is shown in the telnet terminal
Trying 127.0.0.1... Connected to 127.0.0.1. Escape character is '^]'. Open On-Chip Debugger > scan_chain\ invalid command name "scan_chain\" > scan_chain TapName Enabled IdCode Expected IrLen IrCap IrMask -- ------------------- -------- ---------- ---------- ----- ----- ------ 0 feroceon.cpu Y 0x20a023d3 0x20a023d3 4 0x01 0x0f > nand probe 0 NAND flash access requires halted target NAND flash access requires halted target NAND flash access requires halted target NAND flash access requires halted target NAND flash access requires halted target NAND flash access requires halted target unknown NAND flash device found, manufacturer id: 0x02 device id: 0x02 > monitor flash probe 0 invalid command name "monitor" > sheevaplug_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 > scan_chain TapName Enabled IdCode Expected IrLen IrCap IrMask -- ------------------- -------- ---------- ---------- ----- ----- ------ 0 feroceon.cpu Y 0x20a023d3 0x20a023d3 4 0x01 0x0f > nand probe 0 NAND flash device 'NAND 128MiB 3.3V 8-bit (Samsung)' found > nand list #0: NAND 128MiB 3.3V 8-bit (Samsung) pagesize: 2048, buswidth: 8, blocksize: 131072, blocks: 1024 >
So i'm feeling like making progress. Now I need some guidance on backing up and flashing.
Kind regards
If I give the command
nand dump 0 "first4.bin" 0 65536 dumped 65536 bytes in 32.075588s (1.995 KiB/s)Is this correct... it means I created a copy of the first 64 kbytes of flash? That can be written back to it in case of bricking?
Edited 1 time(s). Last edit at 04/03/2021 04:05PM by fratzicu.
|
Re: HOW2: Repair Pogo E02 with Raspberry PI (1,2 or 3) JTAG and OpenOCD April 03, 2021 04:51PM |
Registered: 11 years ago Posts: 18 |
I have pretty much give up on the Pogo---although I still have one in operation as a media server, and 3 still new in boxes. I was never able to repair my flash with JTAG & openocd, so I discarded that one.
A Raspberry Pi only costs $20 and it has much more capability than the Pogo. Only thing the Pogo is better at is the USB ports.
I did manage to upgrade the U-boot code so it would boot off a drive larger than 2TB. But BFD. Sadly, the Pogoplug E02 is obsolete.
A Raspberry Pi only costs $20 and it has much more capability than the Pogo. Only thing the Pogo is better at is the USB ports.
I did manage to upgrade the U-boot code so it would boot off a drive larger than 2TB. But BFD. Sadly, the Pogoplug E02 is obsolete.
|
Re: HOW2: Repair Pogo E02 with Raspberry PI (1,2 or 3) JTAG and OpenOCD April 05, 2021 01:07AM |
Registered: 9 years ago Posts: 94 |
Hi fratzicu,
i dont know the special conditions of your lacie box but it looks like you suceed installing openocd and put the wright parameters.
i also dont know whats your exact target, but if you want to flash new uboot for kirkwood devices you have to take the matching one. (in my case it was a Pogo E02)
After three times overthinking and checking your plan you should go further....
First you should erase the first 512k (4 blocks) of your nand to prepair installing the new bootloader.
( please take a look at your exact bootloader layout and size), in my case it was like this:
For the next step you should download (for example bodhis, if there is one for your box) latest bootloader, extract it, and take the *.kwb file - put it to a place where you have access.
(I did it with symlinks in my discription).
I erased and flashed my new uboot like this:
Edited 1 time(s). Last edit at 04/06/2021 08:53AM by joerg_999.
i dont know the special conditions of your lacie box but it looks like you suceed installing openocd and put the wright parameters.
i also dont know whats your exact target, but if you want to flash new uboot for kirkwood devices you have to take the matching one. (in my case it was a Pogo E02)
After three times overthinking and checking your plan you should go further....
First you should erase the first 512k (4 blocks) of your nand to prepair installing the new bootloader.
( please take a look at your exact bootloader layout and size), in my case it was like this:
================================================================================
## uboot layout (mtd0) ##
================================================================================
offset
Block 0 (128K) 0x0 ------------|
|
Block 1 (128K) 0x20000 |
|
Block 2 (128K) 0x40000 uboot | size 0x80000
|
Block 3 (128K) 0x60000 |
|
Block 4 (128K) 0x80000 -----------|--> uboot 4 Blocks with 128K
Block 5 (128K) 0xa0000
Block 6 (128K) 0xc0000 -----------| size 0x20000
uboot env |
Block 7 (128K) 0xe0000 -----------|--> uboot env 1 Block with 128K
128K x 8 = 1024K = 1M
to 0x100000 1M = 8 Blocks (0-7)
================================================================================
For the next step you should download (for example bodhis, if there is one for your box) latest bootloader, extract it, and take the *.kwb file - put it to a place where you have access.
(I did it with symlinks in my discription).
I erased and flashed my new uboot like this:
# Terminal2 We clear the first 512kB: > nand erase 0 0x0 0xa0000 # erased blocks 0 to 5 on NAND flash device #0 'NAND 128MiB 3.3V 8-bit' # Terminal2 Then we write the nand file uboot: # be careful and take the matching one !! # Files we use: pogo.cfg, and Symlinks we created before # uboot.2017.07-tld-1.pogo_e02.mtd0.kwb ----> uboot.kwb > nand write 0 uboot.kwb 0 oob_softecc_kw # Finished
Edited 1 time(s). Last edit at 04/06/2021 08:53AM by joerg_999.
|
Re: HOW2: Repair Pogo E02 with Raspberry PI (1,2 or 3) JTAG and OpenOCD April 05, 2021 11:12AM |
Registered: 3 years ago Posts: 25 |
Hi,
So it seems that I mastered the reading / erasing / writing to nand flash of wireless space with openocd.
Some bumps along the way:
> nand write 0 flash.bin 0
DCC write failed, expected end address 0x00100814 got 0x5a
For this to work I needed to change the openocd board script wspace.cfg to -work-area-phys 0x10000000 to 0x10000 (I saw it on a blog, don't know the signifficance but it works)
Examples:
After restart device is dead / bricked.
now again back to life but after decompressing.... booting the kernel it does not boot. So I restore now the whole flash
before that i made a bakup of the whole flash
I tested it by erasing, seeing that it is bricked then erasing/writing and seeing it back to life.. Now it is time to continue my journey to understand the flash device partitioning and porting openwrt to it.
I'll keep you posted
So it seems that I mastered the reading / erasing / writing to nand flash of wireless space with openocd.
Some bumps along the way:
> nand write 0 flash.bin 0
DCC write failed, expected end address 0x00100814 got 0x5a
For this to work I needed to change the openocd board script wspace.cfg to -work-area-phys 0x10000000 to 0x10000 (I saw it on a blog, don't know the signifficance but it works)
Examples:
telnet localhost 4444
>sheevaplug_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 list 0 #0: NAND 128MiB 3.3V 8-bit (Samsung) pagesize: 2048, buswidth: 8, blocksize: 131072, blocks: 1024 >nand dump 0 "u-boot.printenv.bin" 0 786432 dumped 786432 bytes in 386.816040s (1.985 KiB/s) > nand erase 0 0 786432 erased blocks 0 to 5 on NAND flash device #0 'NAND 128MiB 3.3V 8-bit'
After restart device is dead / bricked.
> nand write 0 u-boot.printenv.bin 0 wrote file u-boot.printenv.bin to NAND flash 0 up to offset 0x000c0000 in 23.302645s (32.958 KiB/s)
now again back to life but after decompressing.... booting the kernel it does not boot. So I restore now the whole flash
nand erase 0 erased blocks 0 to 1023 on NAND flash device #0 'NAND 128MiB 3.3V 8-bit' > nand write 0 flash.bin 0
before that i made a bakup of the whole flash
nand dump 0 "flash.bin" 0 134217728 dumped 134217728 bytes in 63788.855469s (2.055 KiB/s)
I tested it by erasing, seeing that it is bricked then erasing/writing and seeing it back to life.. Now it is time to continue my journey to understand the flash device partitioning and porting openwrt to it.
I'll keep you posted
|
Re: HOW2: Repair Pogo E02 with Raspberry PI (1,2 or 3) JTAG and OpenOCD April 06, 2021 02:35AM |
Registered: 3 years ago Posts: 25 |
joerg_999 Wrote:
-------------------------------------------------------
> Hi fratzicu,
> i dont know the special conditions of your lacie
> box but it looks like you suceed installing
> openocd and put the wright parameters.
> i also dont know whats your exact target, but if
> you want to flash bodhis uboot for kirkwood
> devices you have to take the matching one. (in my
> case it was a Pogo E02)
>
> After three times overthinking and checking your
> plan you should go further....
>
> First you should erase the first 512k (4 blocks)
> of your nand to prepair installing the new
> bootloader.
> ( please take a look at your exact bootloader
> layout and size), in my case it was like this:
>
> For the next step you should download bodhis
> latest bootloader, extract it, and take the *.kwb
> file - put it to a place where you have access.
> (I did it with symlinks in my discription).
>
> I erased and flashed my new uboot like this:
Thank you. I will do that. Thing is if I restore the old flash back, the old u-boot seems to work but not reading ptoperly kernel and root.
I'll follow your instructions and update here
-------------------------------------------------------
> Hi fratzicu,
> i dont know the special conditions of your lacie
> box but it looks like you suceed installing
> openocd and put the wright parameters.
> i also dont know whats your exact target, but if
> you want to flash bodhis uboot for kirkwood
> devices you have to take the matching one. (in my
> case it was a Pogo E02)
>
> After three times overthinking and checking your
> plan you should go further....
>
> First you should erase the first 512k (4 blocks)
> of your nand to prepair installing the new
> bootloader.
> ( please take a look at your exact bootloader
> layout and size), in my case it was like this:
>
> ================================================================================ > ## uboot layout (mtd0) ## > ================================================================================ > offset > Block 0 (128K) 0x0 ------------| > > | > Block 1 (128K) 0x20000 | > | > Block 2 (128K) 0x40000 uboot | size > 0x80000 > | > Block 3 (128K) 0x60000 | > | > Block 4 (128K) 0x80000 -----------|--> > uboot 4 Blocks with 128K > > Block 5 (128K) 0xa0000 > > Block 6 (128K) 0xc0000 -----------| size > 0x20000 > uboot env | > Block 7 (128K) 0xe0000 -----------|--> > uboot env 1 Block with 128K > > 128K x 8 = 1024K = 1M > to 0x100000 > 1M = 8 Blocks (0-7) > > ================================================================================ > >>
> For the next step you should download bodhis
> latest bootloader, extract it, and take the *.kwb
> file - put it to a place where you have access.
> (I did it with symlinks in my discription).
>
> I erased and flashed my new uboot like this:
> # Terminal2 We clear the first 512kB: > > nand erase 0 0x0 0xa0000 > # erased blocks 0 to 5 on NAND flash device #0 > 'NAND 128MiB 3.3V 8-bit' > > # Terminal2 Then we write the nand file uboot: > # be careful and take the matching one !! > # Files we use: pogo.cfg, and Symlinks we created > before > # uboot.2017.07-tld-1.pogo_e02.mtd0.kwb ----> > uboot.kwb > > > nand write 0 uboot.kwb 0 oob_softecc_kw > > > # Finished > >
Thank you. I will do that. Thing is if I restore the old flash back, the old u-boot seems to work but not reading ptoperly kernel and root.
I'll follow your instructions and update here
|
Re: HOW2: Repair Pogo E02 with Raspberry PI (1,2 or 3) JTAG and OpenOCD April 06, 2021 04:54AM |
Registered: 9 years ago Posts: 94 |
1.)
2.) you did erase the whole nand, and wrote back only the uboot envs? (no uboot himself??)
Edited 6 time(s). Last edit at 04/06/2021 08:49AM by joerg_999.
This print error is known - you should take this config here:Quote
fratzicu
Some bumps along the way:
> nand write 0 flash.bin 0
DCC write failed, expected end address 0x00100814 got 0x5a
For this to work I needed to change the openocd board script wspace.cfg to -work-area-phys 0x10000000 to 0x10000 (I saw it on a blog, don't know the signifficance but it works)
$_TARGETNAME configure \ -work-area-phys 0x100000 \ -work-area-size 65536 \ -work-area-backup 0see discription on first page.
2.) you did erase the whole nand, and wrote back only the uboot envs? (no uboot himself??)
>nand dump 0 "u-boot.printenv.bin" 0 786432 dumped 786432 bytes in 386.816040s (1.985 KiB/s) > nand erase 0 0 786432 erased blocks 0 to 5 on NAND flash device #0 'NAND 128MiB 3.3V 8-bit' After restart device is dead / bricked. > nand write 0 u-boot.printenv.bin 0 wrote file u-boot.printenv.bin to NAND flash 0 up to offset 0x000c0000 in 23.302645s (32.958 KiB/s) now again back to life but after decompressing.... booting the kernel it does not boot. So I restore now the whole flashBut take care, the uboot envs should always match the options of the uboot and the location where uboot will seek them (especially dtb - configuration, loaded intern or external = new methode). In other words: newer uboots can handle some more options in uboot-envs than older one can do!
Edited 6 time(s). Last edit at 04/06/2021 08:49AM by joerg_999.
|
Re: HOW2: Repair Pogo E02 with Raspberry PI (1,2 or 3) JTAG and OpenOCD April 06, 2021 10:18AM |
Registered: 3 years ago Posts: 25 |
Hi,
I erased the whole flash and then flashed back the entire flash but:
1) at some point there was some mentionof marked bad blocks (I used nand check_bad_blocks 0 and those mentions of bad blocks dissappeared in nand info). But I don't know if I should use nand raw_access 0 enable or not).
2) I wrote the whole flash but didn't use the option oob_softecc_kw (could this be the problem?) If I write the whole flash then env variables should be the same as before.
If you have some mercy and could tell a beginner (me) what should be the correct sequence to erase/flash device?
1) after halt and successfull nand probe 0 (I use sheevaplug_init; should I use another command? like soft_reset_halt?)
2) nand raw_access 0 enable
3) nand check_bad_blocks 0
3.1) should we do something here to update bad block table? I read that openocd writes ignoring bad blocks.
4) nand erase 0
5) nand write 0 "flash.bin" 0 oob_softecc_kw
6) resume (I use sheevaplug_init; should I use another command?)
I wander If the error
Note: the original boot process had a detection of short/long power button pressing which seem not to work after erasing reflashing with the same info the whole flash. Maybe this should wotk after disconnectoing the jtag adapter?
Kind regards.
Edited 3 time(s). Last edit at 04/06/2021 11:30AM by fratzicu.
I erased the whole flash and then flashed back the entire flash but:
1) at some point there was some mentionof marked bad blocks (I used nand check_bad_blocks 0 and those mentions of bad blocks dissappeared in nand info). But I don't know if I should use nand raw_access 0 enable or not).
2) I wrote the whole flash but didn't use the option oob_softecc_kw (could this be the problem?) If I write the whole flash then env variables should be the same as before.
If you have some mercy and could tell a beginner (me) what should be the correct sequence to erase/flash device?
1) after halt and successfull nand probe 0 (I use sheevaplug_init; should I use another command? like soft_reset_halt?)
2) nand raw_access 0 enable
3) nand check_bad_blocks 0
3.1) should we do something here to update bad block table? I read that openocd writes ignoring bad blocks.
4) nand erase 0
5) nand write 0 "flash.bin" 0 oob_softecc_kw
6) resume (I use sheevaplug_init; should I use another command?)
I wander If the error
DCC write failed, expected end address 0x00100814 got 0x5ais caused by some ram conflict. would setting
$_TARGETNAME configure \ -work-area-phys 0x100000 \ -work-area-size 65536 \ -work-area-backup 0be correct for my device? (very similar with sheevaplug, seagate dockstar?) Is there a source for correct finding of those parameters or they are just guessed? I'll read the page on this error (edit: I didn't find the page with this information). I'm a beginner but I really want to understand those things from A to Z.
Note: the original boot process had a detection of short/long power button pressing which seem not to work after erasing reflashing with the same info the whole flash. Maybe this should wotk after disconnectoing the jtag adapter?
Kind regards.
Edited 3 time(s). Last edit at 04/06/2021 11:30AM by fratzicu.
|
Re: HOW2: Repair Pogo E02 with Raspberry PI (1,2 or 3) JTAG and OpenOCD April 07, 2021 03:30AM |
Registered: 9 years ago Posts: 94 |
I checked the net for some informations about your lacie net space and found only this: uboot for lacie.
At this point it seems there is no newer uboot than ~2012 and no support for debian.
i saw that the original uboot support booting only from partition 10 and fallback from partition 6, so be careful.
see here:
So at this point non of the existing uboots from bodhi could help, (the nearest one is for GOFLEX NET - USB, SATA, GigaBit Ethernet-support, but no WIFI) you have to compile at your own to get some benefits from new uboot.
No debian support - ;-( , so my knowledge is out of limit for your device and you are at your own.
Maybe bodhi can give you some general hints for going further.
I am not an expert only hobbyist, he is the man who inspired me and i learned most of the stuff.
At this point it seems there is no newer uboot than ~2012 and no support for debian.
i saw that the original uboot support booting only from partition 10 and fallback from partition 6, so be careful.
see here:
Quote
The LaCie stock U-Boot comes with a huge limitation: at reset, U-Boot reinitialize the boot environment variables (stored in Flash) with some built-in values. This includes the boot commands sequence. As a consequence, the LaCie system layout (or partition map) can't be changed. By default, U-Boot will load the Linux kernel from partition 10 (update) or from partition 6 as a fallback (default).
Save flash size (a LaCie U-Boot image size is ~450KB against ~230KB for a mainline one).
Boot reliably from USB.
Some command line enhancements: history, completion, scripting …
Be able to add a new feature.
So at this point non of the existing uboots from bodhi could help, (the nearest one is for GOFLEX NET - USB, SATA, GigaBit Ethernet-support, but no WIFI) you have to compile at your own to get some benefits from new uboot.
No debian support - ;-( , so my knowledge is out of limit for your device and you are at your own.
Maybe bodhi can give you some general hints for going further.
I am not an expert only hobbyist, he is the man who inspired me and i learned most of the stuff.
|
Re: HOW2: Repair Pogo E02 with Raspberry PI (1,2 or 3) JTAG and OpenOCD April 10, 2021 03:54PM |
Registered: 3 years ago Posts: 25 |
Hi,
1) I tried to flash any u-boot.kwb from bodhi (for example the one for seagate dockstar) but the device doesn not boot. It boots with the compiled u-boot using the lacie-nas wiki (2013 version) designed for wireless space.
U-boot tries to load /boot/uImage from USB. This is the output
If I put there the generated uImage and uInitrd it stops at loading kernel image
2) If I flash the first 1Mb of data previously dumped from the stock firmware with jtag&openocd, and even if i flash the whole unaltered flash image, u-boot complains about a nand read error
What am I doing wrong?
1) I tried to flash any u-boot.kwb from bodhi (for example the one for seagate dockstar) but the device doesn not boot. It boots with the compiled u-boot using the lacie-nas wiki (2013 version) designed for wireless space.
U-boot tries to load /boot/uImage from USB. This is the output
U-Boot 2013.04-00574-gfbf87b182 (Mar 20 2021 - 19:21:55) Wireless Space
SoC: Kirkwood 88F6281_A1
DRAM: 256 MiB
WARNING: Caches not enabled
NAND: 128 MiB
*** Warning - bad CRC, using default environment
In: serial
Out: serial
Err: serial
Net: egiga0
88E6161 Initialized on egiga0
BOOTP broadcast 1
BOOTP broadcast 2
*** Unhandled DHCP Option in OFFER/ACK: 44
*** Unhandled DHCP Option in OFFER/ACK: 44
DHCP client bound to address 192.168.23.64
Hit any key to stop autoboot: 0
(Re)start USB...
USB0: USB EHCI 1.00
scanning bus 0 for devices... 3 USB Device(s) found
scanning usb for storage devices... 1 Storage Device(s) found
reading /boot/uImage
If I put there the generated uImage and uInitrd it stops at loading kernel image
5316528 bytes read in 387 ms (13.1 MiB/s) ## Booting kernel from Legacy Image at 00800000 ... Image Name: Linux-5.10.7-kirkwood-tld-1 Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 5316464 Bytes = 5.1 MiB Load Address: 00008000 Entry Point: 00008000 Verifying Checksum ... OK Loading Kernel Image ...
2) If I flash the first 1Mb of data previously dumped from the stock firmware with jtag&openocd, and even if i flash the whole unaltered flash image, u-boot complains about a nand read error
| | __ _ / ___(_) ___
| | / _` | | | |/ _ \
| |___ (_| | |___| | __/
|_____\__,_|\____|_|\___|
_ _ ____ _
| | | | | __ ) ___ ___ | |_
| | | |___| _ \ / _ \ / _ \| __|
| |_| |___| |_) | (_) | (_) | |_
\___/ |____/ \___/ \___/ \__|
** 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)
What am I doing wrong?
|
Re: HOW2: Repair Pogo E02 with Raspberry PI (1,2 or 3) JTAG and OpenOCD April 10, 2021 05:22PM |
Admin Registered: 13 years ago Posts: 18,549 |
fratzicu,
I'll answer number 1, and let joerg look at number 2.
> *** Warning - bad CRC, using default environment
At this point your u-boot envs are from the internal settings. This u-boot could not find the valid envs where it expected to find.
> If I put there the generated uImage and uInitrd it
> stops at loading kernel image
>
So there are 2 possibilities here. Either,
1. This u-boot has some size limitation for uImage (very common with older u-boot).
So try using older kernel uImage such as 4.16.1-kirkwood-tld-1 to make sure the uImage size will be less than 4MB.
2. This u-boot has some expected location for the uImage to load to (not common for a mainline u-boot circa 2013).
Look for stock load address env for uImage, and adjust the load command to load it there.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
I'll answer number 1, and let joerg look at number 2.
> *** Warning - bad CRC, using default environment
At this point your u-boot envs are from the internal settings. This u-boot could not find the valid envs where it expected to find.
> If I put there the generated uImage and uInitrd it
> stops at loading kernel image
>
> 5316528 bytes read in 387 ms (13.1 MiB/s) > ## Booting kernel from Legacy Image at 00800000 > ... > Image Name: Linux-5.10.7-kirkwood-tld-1 > Image Type: ARM Linux Kernel Image > (uncompressed) > Data Size: 5316464 Bytes = 5.1 MiB > Load Address: 00008000 > Entry Point: 00008000 > Verifying Checksum ... OK > Loading Kernel Image ... >
So there are 2 possibilities here. Either,
1. This u-boot has some size limitation for uImage (very common with older u-boot).
So try using older kernel uImage such as 4.16.1-kirkwood-tld-1 to make sure the uImage size will be less than 4MB.
Quote
Updated 14 Apr 2018:
Kernel linux-4.16.1-kirkwood-tld-1 package has been uploaded. The following features were added/updated:
- Add GENERIC_CPU_VULNERABILITIES config to track mainline future security reports.
Latest Linux kernel 4.x general release information can be found at:
LinuxChanges log
Download at Dropbox:
linux-4.16.1-kirkwood-tld-1-bodhi.tar.bz2
md5:
ac1aff7c9848ff949dfa081cf5ac094c
sha256:
8779493bf8319b712b2f8ed3519305e61abee9e2bcc9630fc28d7c6d1d420bb8
2. This u-boot has some expected location for the uImage to load to (not common for a mainline u-boot circa 2013).
Look for stock load address env for uImage, and adjust the load command to load it there.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
|
Re: HOW2: Repair Pogo E02 with Raspberry PI (1,2 or 3) JTAG and OpenOCD April 10, 2021 06:19PM |
Registered: 3 years ago Posts: 25 |
Hi,
Thank you for answering and helping me.
So I should find the expected location of the env in the source code for u-boot used to compile it, right?
If I give the command saveenv then the env variables should be saved at the expected location and the error should be gone.
It is trie that when I reflash the compiled 2013 u-boot I erase the whole first 1 Mb (from offser 0x0 with size 0x100000) - is the conversion right?. Then I write the u-boot.kwb whoch is about 293 kb. At this point no env varia les are stored in flash. So it seems it is normal complaining of this. But if I give saveenv then it should be fine right?
Then I erase /flash old kernwl from 0x100000 to 0x400000 and then uinitrd from 0x400000 to 0x800000. There is also a root image from 0x800000 to 0x8000000 (128 Mb).
i had a headache with those addresses numbers conversion, I thaught I got them right. Maybe I did something wrong.
Kind regards
Thank you for answering and helping me.
So I should find the expected location of the env in the source code for u-boot used to compile it, right?
If I give the command saveenv then the env variables should be saved at the expected location and the error should be gone.
It is trie that when I reflash the compiled 2013 u-boot I erase the whole first 1 Mb (from offser 0x0 with size 0x100000) - is the conversion right?. Then I write the u-boot.kwb whoch is about 293 kb. At this point no env varia les are stored in flash. So it seems it is normal complaining of this. But if I give saveenv then it should be fine right?
Then I erase /flash old kernwl from 0x100000 to 0x400000 and then uinitrd from 0x400000 to 0x800000. There is also a root image from 0x800000 to 0x8000000 (128 Mb).
i had a headache with those addresses numbers conversion, I thaught I got them right. Maybe I did something wrong.
Kind regards
|
Re: HOW2: Repair Pogo E02 with Raspberry PI (1,2 or 3) JTAG and OpenOCD April 10, 2021 06:52PM |
Admin Registered: 13 years ago Posts: 18,549 |
fratzicu,
> So I should find the expected location of the env
> in the source code for u-boot used to compile it,
> right?
Correct. It should be defined in ./include/configs/*lacie*.h (or some similar name header file).
Usually the envs location is at one or more blocks after u-boot in the 1st MB. For stock Kirkwood it is usually at the 640K location, my u-boot version uses 768K location.
> If I give the command saveenv then the env
> variables should be saved at the expected location
> and the error should be gone.
Yes. The error should be gone (checksum is recreated automatically). However, the internal envs are most likely not the same as stock envs. So it is best that you save stock envs listing in a text file and check that afterward.
> It is trie that when I reflash the compiled 2013
> u-boot I erase the whole first 1 Mb (from offser
> 0x0 with size 0x100000) - is the conversion
> right?
Yes (0x100000 is 1MB)
> Then I erase /flash old kernwl from 0x100000 to
> 0x400000 and then uinitrd from 0x400000 to
> 0x800000. There is also a root image from 0x800000
> to 0x8000000 (128 Mb).
You could use any location after 1MB for these. As long as they fit in their own area.
> i had a headache with those addresses numbers
> conversion,
Let Google to do that math for you :) enter into the search box:
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
Edited 1 time(s). Last edit at 04/10/2021 06:55PM by bodhi.
> So I should find the expected location of the env
> in the source code for u-boot used to compile it,
> right?
Correct. It should be defined in ./include/configs/*lacie*.h (or some similar name header file).
Usually the envs location is at one or more blocks after u-boot in the 1st MB. For stock Kirkwood it is usually at the 640K location, my u-boot version uses 768K location.
> If I give the command saveenv then the env
> variables should be saved at the expected location
> and the error should be gone.
Yes. The error should be gone (checksum is recreated automatically). However, the internal envs are most likely not the same as stock envs. So it is best that you save stock envs listing in a text file and check that afterward.
> It is trie that when I reflash the compiled 2013
> u-boot I erase the whole first 1 Mb (from offser
> 0x0 with size 0x100000) - is the conversion
> right?
Yes (0x100000 is 1MB)
> Then I erase /flash old kernwl from 0x100000 to
> 0x400000 and then uinitrd from 0x400000 to
> 0x800000. There is also a root image from 0x800000
> to 0x8000000 (128 Mb).
You could use any location after 1MB for these. As long as they fit in their own area.
> i had a headache with those addresses numbers
> conversion,
Let Google to do that math for you :) enter into the search box:
0x100000 in decimaland divide by 1024 to get KB.... so on.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
Edited 1 time(s). Last edit at 04/10/2021 06:55PM by bodhi.
|
Re: HOW2: Repair Pogo E02 with Raspberry PI (1,2 or 3) JTAG and OpenOCD April 11, 2021 05:32AM |
Registered: 3 years ago Posts: 25 |
Great,
Thank you. I'll test that and then I will try to test some kernel loading. I still didn't master the u-boot commands and scripts. I saved the stock printenv. It has some chains with ifs and elses. I read that the kernel needs some bootqrgs passed by u-boot for console tonput the output on screen. I'll document myself a little nit and then I'll come back.
My yoal is maybe put my device in your supported list of u-boot and kernel and put openwrt on it.
A little question: why would the boot process not work ifnI write back with jtag the exact image of flash dumped with jtag? It saved also the env variables as they were before. Has it something to do with ECC?
Kind regards.
Thank you. I'll test that and then I will try to test some kernel loading. I still didn't master the u-boot commands and scripts. I saved the stock printenv. It has some chains with ifs and elses. I read that the kernel needs some bootqrgs passed by u-boot for console tonput the output on screen. I'll document myself a little nit and then I'll come back.
My yoal is maybe put my device in your supported list of u-boot and kernel and put openwrt on it.
A little question: why would the boot process not work ifnI write back with jtag the exact image of flash dumped with jtag? It saved also the env variables as they were before. Has it something to do with ECC?
Kind regards.
|
Re: HOW2: Repair Pogo E02 with Raspberry PI (1,2 or 3) JTAG and OpenOCD April 11, 2021 06:19AM |
Admin Registered: 13 years ago Posts: 18,549 |
fratzicu,
> My yoal is maybe put my device in your supported
> list of u-boot and kernel and put openwrt on it.
Stock u-boot should work fine. Since you have JTAG, as long as you can load u-boot image and run it, you have a rescue path.
More important is the new kernel DTS for this Wireless Space version of the Lacie. That would be the same DTS for Debian and OpenWrt. Just getting the Kirkwood kernel to run with the new DTS would be a time consuming task. And I can help with that effort.
> A little question: why would the boot process not
> work ifnI write back with jtag the exact image of
> flash dumped with jtag? It saved also the env
> variables as they were before. Has it something to
> do with ECC?
>
Not likely because of ECC. Old NAS boxes don't use ECC, but you can double check that by reading the stock serial boot log. If there is ECC, then it will show in the log.
I would have to dig into it to see the problem. I was hopping joerg would be able to tell by reading your JTAG session log.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
> My yoal is maybe put my device in your supported
> list of u-boot and kernel and put openwrt on it.
Stock u-boot should work fine. Since you have JTAG, as long as you can load u-boot image and run it, you have a rescue path.
More important is the new kernel DTS for this Wireless Space version of the Lacie. That would be the same DTS for Debian and OpenWrt. Just getting the Kirkwood kernel to run with the new DTS would be a time consuming task. And I can help with that effort.
> A little question: why would the boot process not
> work ifnI write back with jtag the exact image of
> flash dumped with jtag? It saved also the env
> variables as they were before. Has it something to
> do with ECC?
>
Not likely because of ECC. Old NAS boxes don't use ECC, but you can double check that by reading the stock serial boot log. If there is ECC, then it will show in the log.
I would have to dig into it to see the problem. I was hopping joerg would be able to tell by reading your JTAG session log.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
|
Re: HOW2: Repair Pogo E02 with Raspberry PI (1,2 or 3) JTAG and OpenOCD April 11, 2021 06:32AM |
Registered: 3 years ago Posts: 25 |
