[U-Boot-Users] u-boot and Linux kernel forward compatibility is unsure?
Hello all,
triggered by the e-mail below (which solved my issue, thanks Kim) I have the following question:
For how long can I expect current u-boot (say 1.3.4) to be forward compatible with newer Linux kernels?
It seems the u-boot from only half a year old cannot boot a current Linux kernel (!).
I typically work on products where the initial boot loader is adapted to provide fail-safe upgrades and itself is never upgraded to prevent the chance of non-flashable (bricked) products in the very small chance something goes wrong during the boot loader update.
How do people deal with using u-boot in a fail-safe environment where the chance of brickage must be zero and the (initial) bootloader itself cannot be updated? Should I plan for a second stage loader?
Also, is there any plan to add fail-safe features to u-boot?
Regards,
Leon.
On Wed, May 28, 2008 at 9:38 PM, Kim Phillips kim.phillips@freescale.com wrote:
On Wed, 28 May 2008 21:33:33 +0200 "Leon Woestenberg" leon.woestenberg@gmail.com wrote:
I have tried to run the vanilla upstream 2.6.25.4 kernel on my U-Boot 1.3.0-rc2 (Nov 19 2007 - 16:37:36) MPC83XX
Is this u-boot too old, i.e. might there be a compatibility issue
yes start by updating u-boot
Regards,
Dear Leon,
in message c384c5ea0805281514r1740072fw7c49101a4535f818@mail.gmail.com you wrote:
triggered by the e-mail below (which solved my issue, thanks Kim) I have the following question:
For how long can I expect current u-boot (say 1.3.4) to be forward compatible with newer Linux kernels?
I think chances are pretty good. Please keep in mind that we're right in the middle of a really big change - the merging of the arch/ppc and arch/ppc64 code into a common arch/powerpc tree is something that hits many areas pretty heavily, and the device tree support which many things depend upon is still a (fast) moving target.
But even today you can build a current Linux kernel using the cuImage wrapper and boot it on an old (say, version 1.2.0) U-Boot.
Please do not confuse compatibility with "having all the latest and greatest new interfaces as well".
I think you have to get used to the thought that the Linux kernel is undergoing serious changes right now (which means you cannot consider it stable enough to use the latest version in a project where long- term compatibility is an issue).
It seems the u-boot from only half a year old cannot boot a current Linux kernel (!).
Only if you try to use the latest features. Use a cuImage, and it should just work fine.
I typically work on products where the initial boot loader is adapted to provide fail-safe upgrades and itself is never upgraded to prevent the chance of non-flashable (bricked) products in the very small chance something goes wrong during the boot loader update.
Been there, too.
How do people deal with using u-boot in a fail-safe environment where the chance of brickage must be zero and the (initial) bootloader itself cannot be updated?
You will probably have to accept that software updates are restricted to certain versions. If you started with a root file system build around a 2.4 Linux kernel, you will probably have problems when trying to use a current 2.6 kernel with this file system image as well. There may (or may not) be compatibility layers (like the cuImage wrapper) that extend that period, but there is no guarantee.
Should I plan for a second stage loader?
You already have one - Linux. Use kexec if you really think you must.
Also, is there any plan to add fail-safe features to u-boot?
What are you thinking of?
Best regards,
Wolfgang Denk
Hello Wolfgang,
On Thu, May 29, 2008 at 12:41 AM, Wolfgang Denk wd@denx.de wrote:
in message c384c5ea0805281514r1740072fw7c49101a4535f818@mail.gmail.com you wrote:
For how long can I expect current u-boot (say 1.3.4) to be forward compatible with newer Linux kernels?
I think chances are pretty good. Please keep in mind that we're right
But even today you can build a current Linux kernel using the cuImage wrapper and boot it on an old (say, version 1.2.0) U-Boot.
Thanks for your clear answer, takes away my cloud of doubt.
Also, is there any plan to add fail-safe features to u-boot?
What are you thinking of?
My main requirement is to have the bootloader make a decision to boot a fall back image in case the normal image does not boot (for whatever reason). The fall back image is a user friendly way to unbrick the device. It itself is never overwritten. (In my case a web server with firmware upgrade Java applet, for example).
Currently, my flow is as follows (with implementation in redboot)
boot loader: enable hardware watchdog if flag A is set clear flag A load normal image, boot else if the normal image was not loaded, boot fallback. else boot fallback
the normal image sets flag A when it wants to reboot, then stops servicing the watchdog and resets
if normal image either did not set flag A (it crashes) or it did not service the watchdog, the watchdog will reset the board.
I wonder if this is a common use and if it makes sense to implement this for mainstream u-boot, or is this very specific?
Regards,
In message c384c5ea0805291600v28d281d2o2b65068a0cb88651@mail.gmail.com you wrote:
I wonder if this is a common use and if it makes sense to implement this for mainstream u-boot, or is this very specific?
This is common use, and U-Boot already support it. See the bootcount feature (http://www.denx.de/wiki/view/DULG/UBootBootCountLimit), and read about alternative images in the new image format (doc/uImage.FIT/*).
Best regards,
Wolfgang Denk
participants (2)
-
Leon Woestenberg -
Wolfgang Denk