[U-Boot] BUG: hang with an empty flash (due to recent bootm changes) bisected
Hello,
I'm working with an MPC8349EMDS board, doing testing. I usually just leave the flash blank, and let the autoboot time out, where it sits with the following message:
Hit any key to stop autoboot: 0 Wrong Image Format for bootm command ERROR: can't get kernel image! =>
Since commit 396f635b8ff3ccbc38d75d5eda98444c6466810a, this is no longer the case. The board hangs up after the autoboot times out, showing the following:
Hit any key to stop autoboot: 0 Wrong Image Format for bootm command ERROR: can't get kernel image! XIP Invalid Image ... OK OK
NOTE: If you press a key before the autoboot times out, the board is fine.
This was done with a completely blank flash (other than U-Boot). I get the "bad CRC, using default environment" message.
Reverting 396f635b8ff3ccbc38d75d5eda98444c6466810a solved the problem for me.
Here is the bisection log, just for kicks:
git-bisect start # good: [cd82919e6c8a73b363a26f34b734923844e52d1c] Coding style cleanup, update CHANGELOG, prepare release git-bisect good cd82919e6c8a73b363a26f34b734923844e52d1c # bad: [b5710d9974f6f0f3ddb4e67d6cccc262ab37049e] FSL DDR: Remove old SPD support from cpu/mpc86xx git-bisect bad b5710d9974f6f0f3ddb4e67d6cccc262ab37049e # good: [4cb4e654cafabaa1ac180d37b00c8f6095dae9c9] ColdFire: Multiple fixes for M5282EVB git-bisect good 4cb4e654cafabaa1ac180d37b00c8f6095dae9c9 # good: [c66830263af19831f2b7db307f79d1943febf7f9] dtc: Enable and fix -Wcast-qual warnings git-bisect good c66830263af19831f2b7db307f79d1943febf7f9 # good: [c5d11e79a260415448c152ed557c9bfb93759067] Merge branch 'master' of git://git.denx.de/u-boot-mpc83xx git-bisect good c5d11e79a260415448c152ed557c9bfb93759067 # bad: [306620b762a4f9fa6678568ad2e8772dec145208] remove MVS1 board git-bisect bad 306620b762a4f9fa6678568ad2e8772dec145208 # good: [e906cfae08e8cc2447f59b1bc4c22ab9c3c286d2] bootm: move lmb into the bootm_headers_t structure git-bisect good e906cfae08e8cc2447f59b1bc4c22ab9c3c286d2 # bad: [2a1a2cb6e2b87ee550e6f27b647d23331dfd5e1b] fdt: refactor initrd related code git-bisect bad 2a1a2cb6e2b87ee550e6f27b647d23331dfd5e1b # bad: [3082d2348c8e13342f5fdd10e9b3f7408062dbf9] fdt: refactor fdt resize code git-bisect bad 3082d2348c8e13342f5fdd10e9b3f7408062dbf9 # bad: [396f635b8ff3ccbc38d75d5eda98444c6466810a] bootm: refactor image detection and os load steps git-bisect bad 396f635b8ff3ccbc38d75d5eda98444c6466810a
Hope it helps, Ira
On Aug 27, 2008, at 4:49 PM, Ira Snyder wrote:
Hello,
I'm working with an MPC8349EMDS board, doing testing. I usually just leave the flash blank, and let the autoboot time out, where it sits with the following message:
Hit any key to stop autoboot: 0 Wrong Image Format for bootm command ERROR: can't get kernel image! =>
Since commit 396f635b8ff3ccbc38d75d5eda98444c6466810a, this is no longer the case. The board hangs up after the autoboot times out, showing the following:
Hit any key to stop autoboot: 0 Wrong Image Format for bootm command ERROR: can't get kernel image! XIP Invalid Image ... OK OK
What does the boot command look like?
If I can reproduce this I can track down what's going on.
- k
On Wed, Aug 27, 2008 at 05:20:17PM -0500, Kumar Gala wrote:
On Aug 27, 2008, at 4:49 PM, Ira Snyder wrote:
Hello,
I'm working with an MPC8349EMDS board, doing testing. I usually just leave the flash blank, and let the autoboot time out, where it sits with the following message:
Hit any key to stop autoboot: 0 Wrong Image Format for bootm command ERROR: can't get kernel image! =>
Since commit 396f635b8ff3ccbc38d75d5eda98444c6466810a, this is no longer the case. The board hangs up after the autoboot times out, showing the following:
Hit any key to stop autoboot: 0 Wrong Image Format for bootm command ERROR: can't get kernel image! XIP Invalid Image ... OK OK
What does the boot command look like?
If I can reproduce this I can track down what's going on.
- k
Here is what appears to be the relevant parts of the env.
=> printenv bootcmd bootcmd=run flash_self => printenv flash_self flash_self=run ramargs addip addtty;bootm ${kernel_addr} ${ramdisk_addr} => printenv ramargs addip addtty kernel_addr ramdisk_addr ramargs=setenv bootargs root=/dev/ram rw addip=setenv bootargs ${bootargs} ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname}:${netdev}:off panic=1 addtty=setenv bootargs ${bootargs} console=ttyS0,${baudrate} ## Error: "kernel_addr" not defined ## Error: "ramdisk_addr" not defined
Is there anything else that would help? Ira
Dear Ira Snyder,
In message 20080827225557.GB10692@ovro.caltech.edu you wrote:
=> printenv bootcmd bootcmd=run flash_self => printenv flash_self flash_self=run ramargs addip addtty;bootm ${kernel_addr} ${ramdisk_addr} => printenv ramargs addip addtty kernel_addr ramdisk_addr ramargs=setenv bootargs root=/dev/ram rw addip=setenv bootargs ${bootargs} ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname}:${netdev}:off panic=1 addtty=setenv bootargs ${bootargs} console=ttyS0,${baudrate} ## Error: "kernel_addr" not defined ## Error: "ramdisk_addr" not defined
Ummm... with both "kernel_addr" and "ramdisk_addr" not defined, your boot command looks like this:
run ramargs addip addtty;bootm
i.e. U-Boot tries to locate an image at the default addreess (in RAM), which probably contains random data. Random input => random behaviour ?
Best regards,
Wolfgang Denk
On Thu, Aug 28, 2008 at 01:04:17AM +0200, Wolfgang Denk wrote:
Dear Ira Snyder,
In message 20080827225557.GB10692@ovro.caltech.edu you wrote:
=> printenv bootcmd bootcmd=run flash_self => printenv flash_self flash_self=run ramargs addip addtty;bootm ${kernel_addr} ${ramdisk_addr} => printenv ramargs addip addtty kernel_addr ramdisk_addr ramargs=setenv bootargs root=/dev/ram rw addip=setenv bootargs ${bootargs} ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname}:${netdev}:off panic=1 addtty=setenv bootargs ${bootargs} console=ttyS0,${baudrate} ## Error: "kernel_addr" not defined ## Error: "ramdisk_addr" not defined
Ummm... with both "kernel_addr" and "ramdisk_addr" not defined, your boot command looks like this:
run ramargs addip addtty;bootm
i.e. U-Boot tries to locate an image at the default addreess (in RAM), which probably contains random data. Random input => random behaviour ?
That makes sense, of course. However, it seems pretty unfriendly that a board with a blank flash (other than the bootloader) will lock up if you don't press a key in time. The old behavior was much nicer, in my opinion. At least I could reset the board and then walk away, rather than run to my desktop and press a key on the serial port.
I'm sure there's plenty of other people who just boot over the network, rather than flashing images all the time.
Maybe the default bootcmd should be something like: echo 'No boot command selected'
Lets see what Kumar has to say. Ira
participants (3)
-
Ira Snyder -
Kumar Gala -
Wolfgang Denk