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

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

[Paul B. Henson]

I'm working on a fairly simple project that needs to boot linux from 
NAND on a freescale i.MX28 platform, and there's a lack of consensus on 
how to handle the boot loader.

One option would be to simply use the stock freescale imx bootlets to 
load the linux kernel, the other to leverage u-boot.

Clearly u-boot has a lot more functionality and feature set than the 
basic bootlets, but for this project there's really nothing more needed 
from the bootloader then to load the kernel from nand and pass control 
to it, and one faction thinks it would be more efficient just to use the 
bootlets rather than adding u-boot to the mix.

Assuming a scenario where the boot loader is expected to just load a 
linux kernel and nothing else, what advantages would u-boot provide over 
the basic bootlets? I know that on some platforms the IPL isn't very 
good at handling bad blocks or other issues, and having it load a very 
small u-boot which would then be used to load the larger kernel is 
beneficial, but I'm not sure if that's the case for the bootlets.

I'd appreciate any opinions or reasoning I could take back to the team 
to help make a decision, thanks?

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

[Wolfgang Denk]

Dear "Paul B. Henson",

In message <5147B867.5000704@acm.org> you wrote:
> I'm working on a fairly simple project that needs to boot linux from
> NAND on a freescale i.MX28 platform, and there's a lack of consensus on
> how to handle the boot loader.
>
> One option would be to simply use the stock freescale imx bootlets to
> load the linux kernel, the other to leverage u-boot.

Indeed both are usable approaches that can be taken, and that have
been taken before.

> Clearly u-boot has a lot more functionality and feature set than the
> basic bootlets, but for this project there's really nothing more needed
> from the bootloader then to load the kernel from nand and pass control
> to it, and one faction thinks it would be more efficient just to use the
> bootlets rather than adding u-boot to the mix.

This is true.  But without better knowledge of your project's
requirements it is impossible to us to give any reasonable advice.  If
you will just ship such a system and never really care about it 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.

> Assuming a scenario where the boot loader is expected to just load a
> linux kernel and nothing else, what advantages would u-boot provide over
> the basic bootlets? I know that on some platforms the IPL isn't very

The question is if this scenario (which we often call "production
mode") is really the only possible use you will ever be facing?  Or
will there be other ssituations - say, during development, for
production testing and repair, for maintenance and updates etc., where
you might want to have a more powerful environment?

> good at handling bad blocks or other issues, and having it load a very
> small u-boot which would then be used to load the larger kernel is
> beneficial, but I'm not sure if that's the case for the bootlets.

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

Hope this helps.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Today is the yesterday you worried about tomorrow.

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

[Paul B. Henson]

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.