[U-Boot-Users] intended behavior of bootm

[Matthias Fuchs <matthias.fuchs@esd-electronics.com>]

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:
> > 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
-------------------------------------------------------------------------