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 <[EMAIL PROTECTED]> 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: > > 3) 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 -- ------------------------------------------------------------------------- Dipl.-Ing. Matthias Fuchs Head of System Design esd electronic system design gmbh Vahrenwalder Str. 207 - 30165 Hannover - GERMANY Phone: +49-511-37298-0 - Fax: +49-511-37298-68 Please visit our homepage http://www.esd.eu Quality Products - Made in Germany ------------------------------------------------------------------------- Geschäftsführer: Klaus Detering, Dr. Werner Schulze Amtsgericht Hannover HRB 51373 - VAT-ID DE 115672832 ------------------------------------------------------------------------- ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
