[U-Boot] freescale imx bootlets vs u-boot for i.MX28
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…
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
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.
participants (2)
-
Paul B. Henson -
Wolfgang Denk