[U-Boot] u-boot boot process is broken, how do i recover?
Hi,
I've got a readynas and successfully installed a recent kernel into ROM and Debian onto hard-drive. But when I tried to modify the uboot-env from uboot-console I had trouble with the ; in the vars. And did not know how to escape. So I tried to access uboot-env from linux.
I applied something like this (well, not that straight forward)
/etc/fw_env.config # device offset size Flash sector size Number of sectors /dev/mtd1 0x0 0x20000 0x20000 1
Maybe there is something wrong in my config?
apt-get install uboot-envtools fw_printenv bootcmd fw_setenv bootcmd.bak 'nand read.e 0x1200000 0x200000 0x600000;nand read.e 0x2000000 0x800000 0x1000000;bootm 0x1200000 0x2000000'
fw_setenv bootcmd 'nand read.e 0x1200000 0x200000 0x600000;bootm 0x1200000'
fw_printenv bootcmd.bak bootcmd fw_printenv bootargs fw_setenv bootargs.bak 'console=ttyS0,115200 reason=normal mtdparts=nand_mtd:0x180000@0(u-boot),0x20000@0x180000(u-boot-env),0x600000@0x200000(uImage),0x1000000@0x800000(minirootfs),0x6800000@0x1800000(jffs2)'
fw_setenv bootargs 'console=ttyS0,115200 root=/dev/sda3 mtdparts=nand_mtd:0x180000@0(u-boot),0x20000@0x180000(u-boot-env),0x600000@0x200000(uImage),0x1000000@0x800000(minirootfs),0x6800000@0x1800000(jffs2)'
fw_printenv bootargs.bak bootargs
btw, kernel said: Creating 5 MTD partitions on "nand_mtd": 0x000000000000-0x000000180000 : "u-boot" 0x000000180000-0x0000001a0000 : "u-boot-env" 0x000000200000-0x000000800000 : "uImage" 0x000000800000-0x000001800000 : "minirootfs" 0x000001800000-0x000008000000 : "jffs2"
Now the boot process is broken. I don't understand why. It stops right after the network (see below). Usually the boot countdown should appear afterwards. Is there anything I can do except unsoldering the ROM?
If I have to remove the chip and burn it using an external writer... Is there any way to buy similar chip which can be mounted on a socket?
It's a H27U1G8F2BTR-BC (newer version of HY27UF081G2B-TCB) which is NAND flash, 2,7-3,6V, 1Gbitx8 (128 MiB), SLC Single Die + Large Block, TSOP 48 pin. There is also a FBGA 63 PIN available. are there any sockets for FBGA I can solder to TSOP? Or do other manufacturers offer compatible chips which can be applied to a socket?
thanks for any help!
Jan
__ __ _ _ | / | __ _ _ ____ _____| | | | |/| |/ _` | '__\ \ / / _ \ | | | | | | (_| | | \ V / __/ | | |_| |_|__,_|_| _/ ___|_|_| _ _ ____ _ | | | | | __ ) ___ ___ | |_ | | | |___| _ \ / _ \ / _ | __| | |_| |___| |_) | (_) | (_) | |_ ___/ |____/ ___/ ___/ __| ** MARVELL BOARD: DB-88F6282A-BP LE
U-Boot 1.1.4 (Feb 6 2012 - 14:40:46) Marvell version: 3.4.27 Netgear version: Uboot-1_1_4-NetgearDUOV3-V1008
U-Boot code: 00600000 -> 0067FFF0 BSS: -> 006D0120
Soc: MV88F1155 Rev 1 (DDR3) CPU running @ 1600Mhz L2 running @ 533Mhz SysClock = 533Mhz , TClock = 200Mhz
DRAM unknown CAL tRP = 8 tRAS = 20 tRCD=8 DRAM CS[0] base 0x00000000 size 256MB DRAM Total size 256MB 16bit width Addresses 8M - 0M are saved for the U-Boot usage. Mem malloc Initialization (8M - 7M): Done NAND:128 MB Flash: 0 kB
CPU : Marvell Feroceon (Rev 1)
Streaming disabled Write allocate disabled
USB 0: host mode PEX 0: PCI Express Root Complex Interface PEX interface detected Link X1 Switch On !
Net: egiga0 [PRIME]
Hi JPT,
On Wed, 03 Apr 2013 10:13:02 +0200, JPT j-p-t@gmx.net wrote:
Hi,
I've got a readynas and successfully installed a recent kernel into ROM and Debian onto hard-drive. But when I tried to modify the uboot-env from uboot-console I had trouble with the ; in the vars. And did not know how to escape. So I tried to access uboot-env from linux.
I applied something like this (well, not that straight forward)
/etc/fw_env.config # device offset size Flash sector size Number of sectors /dev/mtd1 0x0 0x20000 0x20000 1
Maybe there is something wrong in my config?
Not in /etc/fw_env.config as far as I can tell, but maybe your Netgear-made u-boot is special.
apt-get install uboot-envtools fw_printenv bootcmd
No result there? There should be.
fw_setenv bootcmd.bak 'nand read.e 0x1200000 0x200000 0x600000;nand read.e 0x2000000 0x800000 0x1000000;bootm 0x1200000 0x2000000'
fw_setenv bootcmd 'nand read.e 0x1200000 0x200000 0x600000;bootm 0x1200000'
fw_printenv bootcmd.bak bootcmd fw_printenv bootargs fw_setenv bootargs.bak 'console=ttyS0,115200 reason=normal mtdparts=nand_mtd:0x180000@0(u-boot),0x20000@0x180000(u-boot-env),0x600000@0x200000(uImage),0x1000000@0x800000(minirootfs),0x6800000@0x1800000(jffs2)'
fw_setenv bootargs 'console=ttyS0,115200 root=/dev/sda3 mtdparts=nand_mtd:0x180000@0(u-boot),0x20000@0x180000(u-boot-env),0x600000@0x200000(uImage),0x1000000@0x800000(minirootfs),0x6800000@0x1800000(jffs2)'
fw_printenv bootargs.bak bootargs
btw, kernel said: Creating 5 MTD partitions on "nand_mtd": 0x000000000000-0x000000180000 : "u-boot" 0x000000180000-0x0000001a0000 : "u-boot-env" 0x000000200000-0x000000800000 : "uImage" 0x000000800000-0x000001800000 : "minirootfs" 0x000001800000-0x000008000000 : "jffs2"
Now the boot process is broken. I don't understand why. It stops right after the network (see below). Usually the boot countdown should appear afterwards. Is there anything I can do except unsoldering the ROM?
Yes: get control through JTAG.
If I have to remove the chip and burn it using an external writer... Is there any way to buy similar chip which can be mounted on a socket?
It's a H27U1G8F2BTR-BC (newer version of HY27UF081G2B-TCB) which is NAND flash, 2,7-3,6V, 1Gbitx8 (128 MiB), SLC Single Die + Large Block, TSOP 48 pin. There is also a FBGA 63 PIN available. are there any sockets for FBGA I can solder to TSOP? Or do other manufacturers offer compatible chips which can be applied to a socket?
Don't consider unsoldering / resoldering, all the more if sockets are involved, as long as you board has JTAG, either as a header or at least as contact points. A dumb JTAG probe and OpenOCD will cost you little and go a long way.
thanks for any help!
Jan
Amicalement,
hi,
Am 03.04.2013 11:00, schrieb Albert ARIBAUD:
apt-get install uboot-envtools fw_printenv bootcmd
No result there? There should be.
sure. it's what I set into bootcmd.bak:
fw_setenv bootcmd.bak 'nand read.e 0x1200000 0x200000 0x600000;nand read.e 0x2000000 0x800000 0x1000000;bootm 0x1200000 0x2000000'
the outputs all looked fine, after I changed the offset in config file to 0x0. Else I wouln't have written anything. But still I am not 100% sure about the sector size of 0x20000 (128KByte)
Yes: get control through JTAG.
Ok. I'll try.
Don't consider unsoldering / resoldering, all the more if sockets are involved, as long as you board has JTAG, either as a header or at least as contact points. A dumb JTAG probe and OpenOCD will cost you little and go a long way.
I've got the following soldering points:
- a 1x3 Pin@2,54mm connector labeld J7 which could be a FAN connector.
- a 2x5=10 PIN@2mm connector J1 near the ROM chip.
both connectors are on this picture: http://natisbad.org/NAS/pics/NETGEAR_ReadyNAS_Duo_v2_RND2000-200EUS_J1_and_J...
- 1x4 PIN @ 2,54mm connector.
So which one? Do I have to guess the pins?
which probe should I chose? Something like these? - Embedded Projects OpenOCD-USB Adapter - Xilinx JTAG Parallel Cable III FPGA CPLD programmer LPT - SainSmart USB Blaster Programmer Cable For FPGA CPLD JTAG Development Board - found a LPT programmer having nothing more than a 74HC244 chip.
Id' prefer the USB adapter...
btw, I found out there is a boot menu. When I hold the reset button during bootup, there is a boot menu offering:
Normal.
Factory default. I believe it loads the initrd to reformat the harddrives.
OS Re-install. Installs the root fs to hard drive from JFFS rom.
Skip volume check.
Memory test. Performs a memory test.
Disk test. Maybe Smart test.
I tried most. They all freeze after printing "net: egiga..." except memory test. Won't help much, I believe, since most rely on the boot process which is broken.
JPT
Hi JPT,
On Wed, 03 Apr 2013 13:30:46 +0200, JPT j-p-t@gmx.net wrote:
hi,
Am 03.04.2013 11:00, schrieb Albert ARIBAUD:
apt-get install uboot-envtools fw_printenv bootcmd
No result there? There should be.
sure. it's what I set into bootcmd.bak:
fw_setenv bootcmd.bak 'nand read.e 0x1200000 0x200000 0x600000;nand read.e 0x2000000 0x800000 0x1000000;bootm 0x1200000 0x2000000'
Ok.
the outputs all looked fine, after I changed the offset in config file to 0x0. Else I wouln't have written anything. But still I am not 100% sure about the sector size of 0x20000 (128KByte)
Well, the exact value can only be known with the source code for the U-Boot your board is running. Speaking of which... Did you look / ask Netgear for the source code? They should provide it to you as per GPL.
Yes: get control through JTAG.
Ok. I'll try.
Don't consider unsoldering / resoldering, all the more if sockets are involved, as long as you board has JTAG, either as a header or at least as contact points. A dumb JTAG probe and OpenOCD will cost you little and go a long way.
I've got the following soldering points:
a 1x3 Pin@2,54mm connector labeld J7 which could be a FAN connector.
a 2x5=10 PIN@2mm connector J1 near the ROM chip.
both connectors are on this picture: http://natisbad.org/NAS/pics/NETGEAR_ReadyNAS_Duo_v2_RND2000-200EUS_J1_and_J...
- 1x4 PIN @ 2,54mm connector.
So which one? Do I have to guess the pins?
Well, without information from Netgear, it's going to be hard to find out which is which. Considering the number of signals in a JTAG I/F, J7 and the 1x4 pin connector can be ruled out. However, it does not mean J1 is JTAG, and anyway, you'll have trouble finding the right pinout.
which probe should I chose? Something like these?
- Embedded Projects OpenOCD-USB Adapter
- Xilinx JTAG Parallel Cable III FPGA CPLD programmer LPT
- SainSmart USB Blaster Programmer Cable For FPGA CPLD JTAG Development
Board
- found a LPT programmer having nothing more than a 74HC244 chip.
Id' prefer the USB adapter...
I cannot advise on the compared merits of those. The ones I know are the BusPirate or BusBlaster (very versatile boards, no casing) and the Olimex ARM-USB-OCD[-H] (less generic than the BusPirate/Blaster but has a casing and comes with a serial port.
In any case, choose a probe for which your JTAG software will work.
btw, I found out there is a boot menu. When I hold the reset button during bootup, there is a boot menu offering: [...] Won't help much, I believe, since most rely on the boot process which is broken.
I think so too. For now, your best chance for recovery will be JTAG.
BTW, this becomes unrelated to U-Boot per se (at most, it's a non-mainline U-Boot, which should not be discussed here). I suggest moving the discussion outside of this list unless you have generic questions left regarding U-boot.
Amicalement,
Dear JPT,
On Wed, 03 Apr 2013 10:13:02 +0200, JPT wrote:
| \/ | __ _ _ ____ _____| | | | |\/| |/ _` | '__\ \ / / _ \ | | | | | | (_| | | \ V / __/ | | |_| |_|\__,_|_| \_/ \___|_|_|
| | | | | __ ) ___ ___ | |_ | | | |___| _ \ / _ \ / _ | __| | |_| |___| |_) | (_) | (_) | |_ ___/ |____/ ___/ ___/ __| ** MARVELL BOARD: DB-88F6282A-BP LE
U-Boot 1.1.4 (Feb 6 2012 - 14:40:46) Marvell version: 3.4.27 Netgear version: Uboot-1_1_4-NetgearDUOV3-V1008
On Marvell hardware, you can send a different U-Boot using the serial port, even if the on-flash U-Boot is broken. Have a look at tools/kwboot.c in the mainline U-Boot sources. It uses the serial port to send using the Xmodem protocol, a new U-Boot payload to the Kirkwood SoC.
Best regards,
Thomas
Hi Thomas,
On Thu, 4 Apr 2013 10:18:15 +0200, Thomas Petazzoni thomas.petazzoni@free-electrons.com wrote:
On Marvell hardware, you can send a different U-Boot using the serial port, even if the on-flash U-Boot is broken. Have a look at tools/kwboot.c in the mainline U-Boot sources. It uses the serial port to send using the Xmodem protocol, a new U-Boot payload to the Kirkwood SoC.
Depends on the SoC. I am the proud owner of a Wireless Space which, due its Kirkwood SoC's revision, cannot recover through UART even though kirkwoods normally can. Not to mention my ED Mini V2, which has orion, with no UART recovery at all.
I did not find if MV88F1155 has UART recovery.
Also, UART recovery requires having a working U-boot image file. JPT, do you have a working (pristine) U-Boot for your ReadyNAS, or can you get one from Netgear?
Best regards,
Thomas
Amicalement,
Am 04.04.2013 11:17, schrieb Albert ARIBAUD:
Hi Thomas,
On Thu, 4 Apr 2013 10:18:15 +0200, Thomas Petazzoni thomas.petazzoni@free-electrons.com wrote:
On Marvell hardware, you can send a different U-Boot using the serial port, even if the on-flash U-Boot is broken. Have a look at tools/kwboot.c in the mainline U-Boot sources. It uses the serial port to send using the Xmodem protocol, a new U-Boot payload to the Kirkwood SoC.
mh, there is no kwb* (or kw?b*) neither in the netgear sources nor in stock uboot-1.14
Depends on the SoC. I am the proud owner of a Wireless Space which, due its Kirkwood SoC's revision, cannot recover through UART even though kirkwoods normally can. Not to mention my ED Mini V2, which has orion, with no UART recovery at all.
Also, UART recovery requires having a working U-boot image file. JPT, do you have a working (pristine) U-Boot for your ReadyNAS, or can you get one from Netgear?
I've got both, source and image. The first thing I did was reading the ROM to disk :) 1,5M 2013-02-10 20:18 mtd0.uboot.img 128K 2013-02-10 20:18 mtd1.uboot-env.img 6,0M 2013-02-10 20:19 mtd2.kernel.img 2,2M 2013-02-10 20:19 mtd3.initrd.img 89M 2013-02-10 20:17 mtd4.jffs2.img
There is a UART_boot_file.zip included in the source: 32000 2008-06-05 19:35 bb11223344556677_boot.bin
There are a lot of changes in the netgear uboot source. I don't know where to start. I cannot find your mail where you wrote about searching for something... o.O
Well, I think easiest would be to try loading the image through serial. Should I start with this? http://forum.doozan.com/read.php?3,4640,4640,quote=1
Thanks,
Jan
Hi JPT,
On Thu, 04 Apr 2013 12:21:43 +0200, JPT j-p-t@gmx.net wrote:
Am 04.04.2013 11:17, schrieb Albert ARIBAUD:
Hi Thomas,
On Thu, 4 Apr 2013 10:18:15 +0200, Thomas Petazzoni thomas.petazzoni@free-electrons.com wrote:
On Marvell hardware, you can send a different U-Boot using the serial port, even if the on-flash U-Boot is broken. Have a look at tools/kwboot.c in the mainline U-Boot sources. It uses the serial port to send using the Xmodem protocol, a new U-Boot payload to the Kirkwood SoC.
mh, there is no kwb* (or kw?b*) neither in the netgear sources nor in stock uboot-1.14
That's because kwb* is an official-U-Boot thing, and u-boot 1.1.4 is way too old, and Netgear sources are based off 1.1.4.
Depends on the SoC. I am the proud owner of a Wireless Space which, due its Kirkwood SoC's revision, cannot recover through UART even though kirkwoods normally can. Not to mention my ED Mini V2, which has orion, with no UART recovery at all.
Also, UART recovery requires having a working U-boot image file. JPT, do you have a working (pristine) U-Boot for your ReadyNAS, or can you get one from Netgear?
I've got both, source and image. The first thing I did was reading the ROM to disk :) 1,5M 2013-02-10 20:18 mtd0.uboot.img 128K 2013-02-10 20:18 mtd1.uboot-env.img 6,0M 2013-02-10 20:19 mtd2.kernel.img 2,2M 2013-02-10 20:19 mtd3.initrd.img 89M 2013-02-10 20:17 mtd4.jffs2.img
Very wise of you.
There is a UART_boot_file.zip included in the source: 32000 2008-06-05 19:35 bb11223344556677_boot.bin
Very convenient of Netgear. :)
There are a lot of changes in the netgear uboot source. I don't know where to start. I cannot find your mail where you wrote about searching for something... o.O
Well, I think easiest would be to try loading the image through serial. Should I start with this? http://forum.doozan.com/read.php?3,4640,4640,quote=1
Since you seem to have a binary meant for UART booting, yes, you might try sending it to the board; with any luck that'll allow you to inspect and possibly revert your U-Boot environment into what it was before the bricking. As to how... any serial app with Xmodem should work, I presume. If the transfer starts, chances are the image will run automatically.
Thanks,
Jan
Amicalement,
Dear Albert ARIBAUD,
On Thu, 4 Apr 2013 14:47:18 +0200, Albert ARIBAUD wrote:
Since you seem to have a binary meant for UART booting, yes, you might try sending it to the board; with any luck that'll allow you to inspect and possibly revert your U-Boot environment into what it was before the bricking. As to how... any serial app with Xmodem should work, I presume. If the transfer starts, chances are the image will run automatically.
No, any app doing Xmodem will not work. In order to turn the Marvell Kirkwood romcode into UART boot mode, you have to send a series of magic bytes to the UART. This is what kwboot does before sending the binary using the Xmodem protocol.
Best regards,
Thomas
Hi Thomas,
On Sun, 7 Apr 2013 10:08:22 +0200, Thomas Petazzoni thomas.petazzoni@free-electrons.com wrote:
Dear Albert ARIBAUD,
On Thu, 4 Apr 2013 14:47:18 +0200, Albert ARIBAUD wrote:
Since you seem to have a binary meant for UART booting, yes, you might try sending it to the board; with any luck that'll allow you to inspect and possibly revert your U-Boot environment into what it was before the bricking. As to how... any serial app with Xmodem should work, I presume. If the transfer starts, chances are the image will run automatically.
No, any app doing Xmodem will not work. In order to turn the Marvell Kirkwood romcode into UART boot mode, you have to send a series of magic bytes to the UART. This is what kwboot does before sending the binary using the Xmodem protocol.
Thanks for the correction -- however, it was done already in a private e-mail exchange with JPT, where indeed the requirement became "any app which can send files in raw as well as xmodem modes".
Best regards,
Thomas
Amicalement,
participants (3)
-
Albert ARIBAUD -
JPT -
Thomas Petazzoni