[U-Boot-Users] intended behavior of bootm

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

Hi Wolfgang,

thanks for your reply. That's the kind of thing I wanted to hear.
Now I will start playing around ;-)

Matthias

On Tuesday 22 April 2008 22:49, Wolfgang Denk wrote:
> In message <200804212302.30762.matthias.fuchs@esd-electronics.com> you wrote:
> > 
> > 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?
> 
> The key question here is your definition of "corrupted".
> 
> If reliability is an issue, you want to implement (1) support  for  a
> hardware  watchdog combined with (2) support for a boot counter. Then
> you set "bootlimit" to a reasonable value  and  "altbootcmd"  to  the
> command required to load and boot from USB.
> 
> Such a setup will be very robust and handle even situations when  the
> images  look  good  (checksums  are  OK  etc.)  but fail to work (for
> example, because of buggy binaries or libraries were included, config
> files got corrupted, etc.).
> 
> > 1) Make bootm fail when any image has a CRC error?
> 
> This is trivial to do. Remember that you can always use "imi" to check
> images; something like
> 
> => imi $kernel_addr && imi $ramdisk_addr && bootm $kernel_addr $ramdisk_addr
> 
> would do what you want.
> 
> The new image format allows for even fancier methods.
> 
> Or implement a boot counter and let the board reset on corrupt images
> and then use "altbootcmd".
> 
> > 2) Add a new command to check images and decide on the result
> 
> Not needed. "iminfo" already does that.
> 
> > Any idea? I think the idea behind this is clear. When images A are not ok boot
> > images B.
> 
> As mentioned above, the trick question is  how  you  define  when  an
> image is OK.
> 
> 
> 
> Best regards,
> 
> Wolfgang Denk
>