[U-Boot] freescale imx bootlets vs u-boot for i.MX28

Paul B. Henson henson at acm.org
Thu Mar 21 00:16:57 CET 2013


On 3/20/2013 7:47 AM, Wolfgang Denk wrote:

> again, such an approach may work perfectly fine.  If, on the other
> hand, you have to consider things like support for service and
> maintenance tasks, software updates (especially reliable ones),
> debugging, etc., then you may find bootlets don't offer much support
> for any such things.

One avenue being investigated is to have the basic bootlet load a 
stripped-down minimal linux kernel with an initramfs containing basic 
tools that would then set up the production environment and use kexec to 
bootstrap the production linux kernel, more or less trying to use linux 
itself as the second stage bootloader. There are certainly pros/cons of 
that approach, I'm just trying to make sure I evaluate and review all of 
them I can find.

> I guess you have not studied the iMX28 boot ROM code yet?  If so,
> consider yourself lucky, and try to leave it at that.

No, I must confess I don't have much experience in the embedded realm, 
and I'm finding the wide variety of intricate ways the different 
embedded processors use to IPL, well, interesting :). I briefly reviewed 
the processor specification document and dug through the freescale 
kobs-ng tool and the bundled u-boot mxsboot tool, but definitely don't 
have more than a high level grasp of what's going on.

It looks like two identical copies of the bootstream are burned to NAND, 
but I'm not sure why at this point. My guess is for redundancy, it looks 
like the processor falls back to the second copy if it "fails" to read 
the first, but again I'm not sure why it would fail, whether it would 
actually require a previously good block to fail, or if the IPL is just 
completely incapable of dealing with a bad block even if it is known 
about when the stream is burned.

> What I heard from those who did, makes me believe that running U-Boot
> (or, more precisely, _any_ code you can control yourself) as quickly
> as possible might be a really excellent idea.

Heh :). That is definitely an advantage of u-boot, loading in the 
minimal SPL code with the ROM and then having a more reliable way to 
load the full bootloader image and actual OS.

Thanks much for the feedback, I greatly appreciate it.



More information about the U-Boot mailing list