* booting kernel(s)
@ 2011-02-22 13:15 Vanalme Filip
2011-02-23 9:03 ` Sascha Hauer
0 siblings, 1 reply; 4+ messages in thread
From: Vanalme Filip @ 2011-02-22 13:15 UTC (permalink / raw)
To: barebox
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: booting kernel(s)
2011-02-22 13:15 booting kernel(s) Vanalme Filip
@ 2011-02-23 9:03 ` Sascha Hauer
2011-02-23 9:16 ` Baruch Siach
0 siblings, 1 reply; 4+ messages in thread
From: Sascha Hauer @ 2011-02-23 9:03 UTC (permalink / raw)
To: Vanalme Filip; +Cc: barebox
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: booting kernel(s)
2011-02-23 9:03 ` Sascha Hauer
@ 2011-02-23 9:16 ` Baruch Siach
2011-02-23 9:56 ` Peter Korsgaard
0 siblings, 1 reply; 4+ messages in thread
From: Baruch Siach @ 2011-02-23 9:16 UTC (permalink / raw)
To: Sascha Hauer; +Cc: barebox, Vanalme Filip
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
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: booting kernel(s)
2011-02-23 9:16 ` Baruch Siach
@ 2011-02-23 9:56 ` Peter Korsgaard
0 siblings, 0 replies; 4+ messages in thread
From: Peter Korsgaard @ 2011-02-23 9:56 UTC (permalink / raw)
To: Baruch Siach; +Cc: barebox, Vanalme Filip
>>>>> "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
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2011-02-23 9:56 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-02-22 13:15 booting kernel(s) Vanalme Filip
2011-02-23 9:03 ` Sascha Hauer
2011-02-23 9:16 ` Baruch Siach
2011-02-23 9:56 ` Peter Korsgaard
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox