booting kernel(s)

booting kernel(s)

[Vanalme Filip]

On our i.MX27 based board, we would like to have two Kernels : a default kernel and a "rescue" kernel. The first one is the one that will be started normally. The latter would be used only in (the rare) case the default kernel fails to start. E.g., when we remotely update the kernel, it could be that the uploaded image gets corrupt and cannot be started anymore. In that case, we would like to fall back to a "rescue" kernel, a minimal kernel and a small application with a minimum of capabilities, i.e. with some network capabilities just to be able to upload a new image.
We already have this feature for another device that runs U-boot. I guess this should also be possible in barebox ?
Because it was implemented in U-boot some time ago by another company, I'm not completely sure how it is done. I think it's done with this single line in the board's configuration file :
#define CONFIG_BOOTCOMMAND   "bootm 0x20200000;bootm 0x200A0000"
I guess, when the first bootm command fails (due to corrupt image), it will execute the second one. If the first command is successful, the Linux kernel takes over and the second command gets never executed. Am I right ?
I think I can do the same thing in my Barebox's boot script, can I ? Or are there other/better solutions to handle this ?



Filip


_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: booting kernel(s)

[Sascha Hauer]

On Tue, Feb 22, 2011 at 02:15:46PM +0100, Vanalme Filip wrote:
> On our i.MX27 based board, we would like to have two Kernels : a
> default kernel and a "rescue" kernel. The first one is the one that
> will be started normally. The latter would be used only in (the rare)
> case the default kernel fails to start. E.g., when we remotely update
> the kernel, it could be that the uploaded image gets corrupt and
> cannot be started anymore. In that case, we would like to fall back to
> a "rescue" kernel, a minimal kernel and a small application with a
> minimum of capabilities, i.e. with some network capabilities just to
> be able to upload a new image.  We already have this feature for
> another device that runs U-boot. I guess this should also be possible
> in barebox ?

Sure. You have to adjust your partitioning to store a second kernel
and maybe a second rootfs.

> Because it was implemented in U-boot some time ago by
> another company, I'm not completely sure how it is done. I think it's
> done with this single line in the board's configuration file : #define
> CONFIG_BOOTCOMMAND   "bootm 0x20200000;bootm 0x200A0000"

This works for the case the checksum in the first kernel image is wrong.
Then the second bootm command will be executed.

In barebox this would look like this:

nand_parts=256k(barebox),256k(barebox_env),2M(kernel1),2M(kernel2),-(root)

...

bootm /dev/nand0.kernel1.bb; bootm /dev/nand0.kernel2.bb

> I guess, when
> the first bootm command fails (due to corrupt image), it will execute
> the second one. If the first command is successful, the Linux kernel
> takes over and the second command gets never executed. Am I right ?  I
> think I can do the same thing in my Barebox's boot script, can I ? Or
> are there other/better solutions to handle this ?

This fails when the first kernel has a valid checksum but fails to start
maybe because of a corrupt rootfs. But there are currently no general
solutions for this.

Sascha


-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: booting kernel(s)

[Baruch Siach]

Hi Sascha, Vanalme,

On Wed, Feb 23, 2011 at 10:03:10AM +0100, Sascha Hauer wrote:
> On Tue, Feb 22, 2011 at 02:15:46PM +0100, Vanalme Filip wrote:
> > I guess, when
> > the first bootm command fails (due to corrupt image), it will execute
> > the second one. If the first command is successful, the Linux kernel
> > takes over and the second command gets never executed. Am I right ?  I
> > think I can do the same thing in my Barebox's boot script, can I ? Or
> > are there other/better solutions to handle this ?
> 
> This fails when the first kernel has a valid checksum but fails to start
> maybe because of a corrupt rootfs. But there are currently no general
> solutions for this.

A partial solution is to use initramfs (see the kernel 
Documentation/filesystems/ramfs-rootfs-initramfs.txt). You can mount your 
rootfs from the /init script of the initramfs. Then, if mount fails because of 
a corrupt rootfs, you can mount your rescue rootfs instead, or just run 
whatever rescue application you want directly from initramfs.

Another partial solution is a to use a hardware watchdog, and a userspace 
watchdog ping process. Then, upon boot you may check whether this is a normal 
power-on reset or a watchdog reset, and load the appropriate kernel.

baruch

-- 
                                                     ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: booting kernel(s)

[Peter Korsgaard]

>>>>> "Baruch" == Baruch Siach <baruch@tkos.co.il> writes:

 Baruch> A partial solution is to use initramfs (see the kernel
 Baruch> Documentation/filesystems/ramfs-rootfs-initramfs.txt). You can
 Baruch> mount your rootfs from the /init script of the initramfs. Then,
 Baruch> if mount fails because of a corrupt rootfs, you can mount your
 Baruch> rescue rootfs instead, or just run whatever rescue application
 Baruch> you want directly from initramfs.

This only works if mount does a complete rootfs check, which isn't the
case. In the typical situation of a power loss in the middle of an
update, the superblock will normally be valid and you will only discover
the corruption when you start accessing files.

 Baruch> Another partial solution is a to use a hardware watchdog, and a
 Baruch> userspace watchdog ping process. Then, upon boot you may check
 Baruch> whether this is a normal power-on reset or a watchdog reset,
 Baruch> and load the appropriate kernel.

That's imho a better solution, and pretty simply to implement without
any adverse affects on the startup time, whereas the CRC checks do add
to the startup time.

-- 
Bye, Peter Korsgaard

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox