Thanks for Jerry's and your reply. I see that my expectation was incorrect and I didn't take the words 'point of no return' that serious.
Now I have to find a (simple) solution to solve my problem:
Typically the 405 board boots from onboard flash. Because of historic reason there is a kernel and a ramdisk image (not a multi image and nothing that is aware of any new image format). These images cannot be changed. When one of these images either one of them or both is corrupted, U-Boot should try to load both of them from a usb mass storage. So what's the best way to do so?
1) Make bootm fail when any image has a CRC error? 2) Add a new command to check images and decide on the result 3) ???
Any idea? I think the idea behind this is clear. When images A are not ok boot images B.
good night Matthias
On Monday 21 April 2008 21:19:22 Wolfgang Denk wrote:
Dear Matthias,
in message 200804211509.43558.matthias.fuchs@esd-electronics.com you
wrote:
I am wondering if bootm behaves correctly on CRC errors in kernel and/or ramdisk images. This is what I observed:
Most has already been said in previous replies, so here just a summary
of the situation:
- Same loading as above. But I make the ramdisk CRC check fail (mw
320000 12345678). I get: ## Booting kernel from Legacy Image at 00200000 ... ... ## Loading init Ramdisk from Legacy Image at 00300000 ... ... Verifying Checksum ... Bad Data CRC
<system reset> U-Boot 1.3.2-00450-g77dd47f (Apr 21 2008 - 14:43:23)
Hmm, I expected the same behavior as for a corrupted kernel image.
This expectation is incorrect.
So what should be the correct behavior? I would like to get back to the prompt on any CRC error. So is this a bug?
No, it is not a bug. Kernel image and ramdisk image get processed sequentiually. As soon as you uncompress and copy the kernel image to it's load address (typically 0x0000 for PowerPC), it will overwrite the exception vectors used by U-Boot. The next interrupt (for example timer) would then kill kill you. That's why there is a point of no return just before we start uncompressing / loading the kernel image.
Any errors after this point can only be resolved by a reset.
That's intentional and documented. There are no intentions to change this behaviour.
Best regards,
Wolfgang Denk