[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?

[Wolfgang Denk]

Dear "Paul B. Henson",

Post by 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.

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

Post by Paul B. Henson
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.

Post by Paul B. Henson
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?

Post by Paul B. Henson
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

[Paul B. Henson]

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.