Implementing Boot Image Fallback on U-Boot
Boot Image Fallback is a mechanism that enables a system to fallback to a "known good" boot image in the event of catastrophic boot failure (i.e. failure to boot, panic on boot, failure to initialize HW/SW). (CGL Availability Requirements Definition V4.0: AVL.9.0). On system especially used in telecommunication, 99.999% high availability is required. So, this function is highly needed (like my customer requires).
This time, I'm thinking of implementing Boot Image Fallback on U-Boot as follows (like a way GRUB does). So, I would appreciate any comments to this.
It uses new U-Boot command "bootmf" and fw_setenv.
* bootmf
It is a wrapper of "bootm", and it boots kernel with fallback enabled on multiple kernel images.
Also, it uses new U-Boot environment variables as follows.
* imgaddr<N>
It holds physical address of flash partition that kernel image is written. <N> is integer and becomes an entry of corresponding kernel image.
(ex.) imgaddr0=0xf8000000, imgaddr1=0xf8200000
* bootargs<N>
It holds kernel parameter of entry <N>.
(ex.) bootargs0=root=/dev/mtdblock1 , bootargs1=root=/dev/mtdblock3
* default
It holds default entry that "bootmf" tries to boot on default.
(ex.) default=1
* fallback
It holds list of fallback entry that "bootmf" tries to boot on next if it fails to boot default entry.
(ex.) fallback=1 2
Now, I assume that circumstances are as follows. (In my case, Linux on Freescale MPC8540.)
* There are three flash partitions "kernel-0", "kernel-1", "kernel-2" that kernel images are written.
* Environment variables are set as follows.
bootcmd=bootmf
imgaddr0=0xf8000000 (physical address of "kernel-0") imgaddr1=0xf8200000 (physical address of "kernel-1") imgaddr2=0xf8400000 (physical address of "kernel-2") bootargs0=root=/dev/mtdblock1 (rootfs of "kernel-0") bootargs1=root=/dev/mtdblock3 (rootfs of "kernel-1") bootargs2=root=/dev/mtdblock5 (rootfs of "kernel-2") default=0
fallback=1 2
* "fw_setenv default 0" is written to /etc/rc.local.
Then it behaves as follows.
1. When U-Boot boots up, "bootmf" is executed and tries to boot default entry in "default". Before booting kernel, "bootmf" sets corresponding fallback entry in "fallback" to "default". ((ex.) When booting entry "0", "1" is set and when booting entry "1", "2" is set.)
2. If kernel succeeds to boot, "default" is set to "0" by fw_setenv. So, next time U-Boot boots up and "bootmf" is executed, entry "0" will be booted again.
3. If kernel fails to boot, "default" stays to fallback entry "1" because fw_setenv won't be executed. So, next time U-Boot boots and "bootmf" is executed, fallback entry "1" will be booted.
By this way, Boot Image Fallback on U-Boot can be realized. I recognize that this needs to rewrite flash each time booting a kernel, but I think there won't be so many reboots once stable system operation have started.
I'll write and send a prototype of "bootmf" if it is needed.
Best regards,
Signature · 2 lines
MIRACLE LINUX CORPORATION Makito SHIOKAWA
Hi,
take a look at Wolfgang's last posting from Tuesday on the 'intended behavior of bootm'. The bootlimit/altbootcmd function (in your case probably together with a hardware watchdog) could be the stuff you are (and I was) looking for.
Matthias
Quoted 94 lines · On Thursday 24 April 2008 04:53:48 Makito SHIOKAWA wrote:
Boot Image Fallback is a mechanism that enables a system to fallback to a "known good" boot image in the event of catastrophic boot failure (i.e. failure to boot, panic on boot, failure to initialize HW/SW). (CGL Availability Requirements Definition V4.0: AVL.9.0). On system especially used in telecommunication, 99.999% high availability is required. So, this function is highly needed (like my customer requires).
This time, I'm thinking of implementing Boot Image Fallback on U-Boot as follows (like a way GRUB does). So, I would appreciate any comments to this.
It uses new U-Boot command "bootmf" and
fw_setenv.* bootmf
It is a wrapper of "bootm", and it boots kernel with fallback enabled on multiple kernel images.
Also, it uses new U-Boot environment variables as follows.
* imgaddr<N>
It holds physical address of flash partition that kernel image is written. <N> is integer and becomes an entry of corresponding kernel image.
(ex.) imgaddr0=0xf8000000, imgaddr1=0xf8200000
* bootargs<N>
It holds kernel parameter of entry <N>.
(ex.) bootargs0=root=/dev/mtdblock1 , bootargs1=root=/dev/mtdblock3
* default
It holds default entry that "bootmf" tries to boot on default.
(ex.) default=1
* fallback
It holds list of fallback entry that "bootmf" tries to boot on next if it fails to boot default entry.
(ex.) fallback=1 2
Now, I assume that circumstances are as follows. (In my case, Linux on Freescale MPC8540.)
* There are three flash partitions "kernel-0", "kernel-1", "kernel-2" that kernel images are written.
* Environment variables are set as follows.
bootcmd=bootmf
imgaddr0=0xf8000000 (physical address of "kernel-0") imgaddr1=0xf8200000 (physical address of "kernel-1") imgaddr2=0xf8400000 (physical address of "kernel-2") bootargs0=root=/dev/mtdblock1 (rootfs of "kernel-0") bootargs1=root=/dev/mtdblock3 (rootfs of "kernel-1") bootargs2=root=/dev/mtdblock5 (rootfs of "kernel-2") default=0
fallback=1 2* "
fw_setenvdefault 0" is written to/etc/rc.local.Then it behaves as follows.
1. When U-Boot boots up, "bootmf" is executed and tries to boot default entry in "default". Before booting kernel, "bootmf" sets corresponding fallback entry in "fallback" to "default". ((ex.) When booting entry "0", "1" is set and when booting entry "1", "2" is set.)
2. If kernel succeeds to boot, "default" is set to "0" by
fw_setenv. So, next time U-Boot boots up and "bootmf" is executed, entry "0" will be booted again.3. If kernel fails to boot, "default" stays to fallback entry "1" because
fw_setenvwon't be executed. So, next time U-Boot boots and "bootmf" is executed, fallback entry "1" will be booted.By this way, Boot Image Fallback on U-Boot can be realized. I recognize that this needs to rewrite flash each time booting a kernel, but I think there won't be so many reboots once stable system operation have started.
I'll write and send a prototype of "bootmf" if it is needed.
Best regards,
Signature · 13 lines
------------------------------------------------------------------------- Dipl.-Ing. Matthias Fuchs Head of System Design esd electronic system design gmbh Vahrenwalder Str. 207 - 30165 Hannover - GERMANY Phone: +49-511-37298-0 - Fax: +49-511-37298-68 Please visit our homepage http://www.esd.eu Quality Products - Made in Germany ------------------------------------------------------------------------- Gesch?ftsf?hrer: Klaus Detering, Dr. Werner Schulze Amtsgericht Hannover HRB 51373 - VAT-ID DE 115672832 -------------------------------------------------------------------------
Hi,
Thank you for your reply.
Quoted 3 lines
take a look at Wolfgang's last posting from Tuesday on the 'intended behavior of bootm'. The bootlimit/altbootcmd function (in your case probably together with a hardware watchdog) could be the stuff you are (and I was) looking for.
This corresponds to CGL Availability Requirements Definition V4.0: AVL.9.1, whereas Boot Image Fallback is AVL.9.0.
(http://developer.osdl.org/dev/cgl/cgl40/cgl40-availability.pdf)
Boot Image Fallback must handle not only image CRC error before kernel boot, but a boot failure like kernel panic during kernel boot process (after image has successfully loaded). Also, it must fallback after power-on reset.
Signature · 2 lines
MIRACLE LINUX CORPORATION Makito SHIOKAWA
Quoted 10 lines · In message <[email protected]> you wrote:
Quoted 3 lines
of bootm'. The bootlimit/altbootcmd function (in your case probably together with a hardware watchdog) could be the stuff you are (and I was) looking for.
This corresponds to CGL Availability Requirements Definition V4.0: AVL.9.1, whereas Boot Image Fallback is AVL.9.0.
(http://developer.osdl.org/dev/cgl/cgl40/cgl40-availability.pdf)
Boot Image Fallback must handle not only image CRC error before kernel boot, but a boot failure like kernel panic during kernel boot process (after image has successfully loaded). Also, it must fallback after power-on reset.
Actually it implements the features needed to handle all of this.
Best regards,
Wolfgang Denk
Signature · 8 lines
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 Every revolutionary idea - in science, politics, art, or whatever - evokes three stages of reaction in a hearer: 1. It is completely impossible - don't waste my time. 2. It is possible, but it is not worth doing. 3. I said it was a good idea all along.
Quoted 11 lines · Makito SHIOKAWA
Boot Image Fallback is a mechanism that enables a system to fallback to a "known good" boot image in the event of catastrophic boot failure (i.e. failure to boot, panic on boot, failure to initialize HW/SW). (CGL Availability Requirements Definition V4.0: AVL.9.0). On system especially used in telecommunication, 99.999% high availability is required. So, this function is highly needed (like my customer requires).
This time, I'm thinking of implementing Boot Image Fallback on U-Boot as follows (like a way GRUB does). So, I would appreciate any comments to this.
Quoted 6 lines
It uses new U-Boot command "bootmf" and
fw_setenv.* bootmf
It is a wrapper of "bootm", and it boots kernel with fallback enabled on multiple kernel images.
Hello,
You might want to have a look an the new image format introduced recently. It allows you to have multiple kernels (and ramdisks, and other types of images) in one image file, and access these components in elegant way. Have a look in doc/uImage.FIT/. In particular, doc/uImage.FIT/command_syntax_extensions.txt describes new syntax that you might find useful.
Quoted 10 lines
Also, it uses new U-Boot environment variables as follows.
* imgaddr<N>
It holds physical address of flash partition that kernel image is written. <N> is integer and becomes an entry of corresponding kernel image.
(ex.) imgaddr0=0xf8000000, imgaddr1=0xf8200000
This is where you may want to consider the new syntax mentioned above.
Quoted 4 lines
* bootargs<N>
It holds kernel parameter of entry <N>.
And here too.
Quoted 6 lines
(ex.) bootargs0=root=/dev/mtdblock1 , bootargs1=root=/dev/mtdblock3
* default
It holds default entry that "bootmf" tries to boot on default.
Please check the "default booting configuration" feature of the new image format, seems like it might be what you're looking for.
Regards,
Barlomiej
Hi,
Thank you for your reply.
Quoted 6 lines
You might want to have a look an the new image format introduced recently. It allows you to have multiple kernels (and ramdisks, and other types of images) in one image file, and access these components in elegant way. Have a look in doc/uImage.FIT/. In particular,
doc/uImage.FIT/command_syntax_extensions.txtdescribes new syntax that you might find useful.
I'll check it if this can be a substitution.
Signature · 2 lines
MIRACLE LINUX CORPORATION Makito SHIOKAWA
Quoted 6 lines
You might want to have a look an the new image format introduced recently. It allows you to have multiple kernels (and ramdisks, and other types of images) in one image file, and access these components in elegant way. Have a look in doc/uImage.FIT/. In particular,
doc/uImage.FIT/command_syntax_extensions.txtdescribes new syntax that you might find useful.
I've read it but I'm afraid it's bit different from Boot Image Fallback.
Boot Image Fallback decides image to boot according to a order of images to boot and depending on previous boot has succeeded or not. So, this kind of mechanism is still needed.
Quoted 6 lines
Quoted 3 lines
* default
It holds default entry that "bootmf" tries to boot on default.
Please check the "default booting configuration" feature of the new image format, seems like it might be what you're looking for.
Also, on Boot Image Fallback, "default" changes dynamically but "default booting configuration" is embedded in ".its" and it's static.
Anyway thank you. By the way, is it able to define "bootargs" for each image entry on ".its"?
Regards,
Signature · 5 lines
/******************************** * MIRACLE LINUX CORPORATION * * Makito SHIOKAWA * * <[email protected]> * ********************************/
Quoted 6 lines · In message <[email protected]> you wrote:
I've read it but I'm afraid it's bit different from Boot Image Fallback.
Boot Image Fallback decides image to boot according to a order of images to boot and depending on previous boot has succeeded or not. So, this kind of mechanism is still needed.
Are you aware that U-Boot has scripting capabilities, to the extend of being able to run shell scripts?
What you are asking for can be pretty easily implemented using a few macro definitions utilizing the aforementioned features.
If you think something is missing, please point out which specific feature you think is missing.
Please make sure to read the previous postings and the available documentation on this topic.
Quoted 2 lines
Also, on Boot Image Fallback, "default" changes dynamically but "default booting configuration" is embedded in ".its" and it's static.
You can define boot commands, and change these definitions with each boot you perform.
Don't look for a turn-key solution, instead look for building blocks which you can easily put together.
Quoted 2 lines
Anyway thank you. By the way, is it able to define "bootargs" for each image entry on ".its"?
The "bootargs" variable normally gets built dynamically, and of cource you can change the settings each time you build it.
Best regards,
Wolfgang Denk
Signature · 5 lines
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 "The one charm of marriage is that it makes a life of deception a neccessity." - Oscar Wilde
RFC 1/1 Implementing Boot Image Fallback on U-Boot
Hi,
Thank you for your reply.
Quoted 2 lines
Are you aware that U-Boot has scripting capabilities, to the extend of being able to run shell scripts?
What I was thinking as "boomf" is like a patch bellow (It is for U-Boot 1.1.4 and just a prototype). I knew about scripting, but I thought it was difficult to do this processing by a script (especially error checks). Also, I didn't think it's a good way to set corresponding long script to "bootcmd" (U-Boot environment area is limited).
But, is it better to do this processing by a script? (Or, is there more proper way to do same kind of things?)
Quoted 2 lines
What you are asking for can be pretty easily implemented using a few macro definitions utilizing the aforementioned features.
Is it able to do without using all of the elements (new command, new environment variable, fw_setenv) I wrote in the first mail?
I'll check documents and sources over again, but I would appreciate if you can give me some keywords of those features ...
Best regards,
--- common/Makefile | 2 common/cmd_bootmf.c | 256 +++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 257 insertions(+), 1 deletion(-)
common/Makefile +1 -1
@@ -29,7 +29,7 @@ AOBJS = COBJS = main.o ACEX1K.o altera.o bedbug.o circbuf.o \ cmd_ace.o cmd_autoscript.o \ - cmd_bdinfo.o cmd_bedbug.o cmd_bmp.o cmd_boot.o cmd_bootm.o \ + cmd_bdinfo.o cmd_bedbug.o cmd_bmp.o cmd_boot.o cmd_bootm.o cmd_bootmf.o \ cmd_cache.o cmd_console.o \ cmd_date.o cmd_dcr.o cmd_diag.o cmd_display.o cmd_doc.o cmd_dtt.o \ cmd_eeprom.o cmd_elf.o cmd_ext2.o \
common/cmd_bootmf.c new file +256 -0
256 lines not on this page · raw message
Signature · 2 lines
MIRACLE LINUX CORPORATION Makito SHIOKAWA