--- In "Yan Seiner" <> wrote:
> That's just too slick!
Thanks!
>
> Now you're going to make me build a mini-kernel - a totally stripped
> down kernel to use as a bootloader. :-)
>
> I see a lot of potential in this:
>
> I picture loading up a mini-kernel with just enough smarts to put up a
> grub-like menu, and allow me to select if I want to boot from flash,
> tftp, or whatever.... And/or to load up a framebuffer and then boot
> the real kernel. The possibilities are endless.....
We've done a lot of experimenting with fast Linux kernel booting and
believe me, the kernel is already very minimal. We've already made
most of the optimizations available and I don't think you'll gain much
by attempting to further reduce Linux functionality.
Your project does sound neat. I've always wanted to be able to write
bootloaders in shell script! We're looking for a good
marketing "angle" to describe this new feature, maybe thats it: "Write
your own TS-7400 bootloader in as little as one line of shell
script!" :-)
It is our hope the default kernel is "good enough" for most people. We
do however, have several customers doing kernel modifications and are
concerned about safe field updates and want to have failover kernels
which this functionality should squarely accomodate. Combined with
using the hardware watchdog(s), this should allow for the utmost in
product reliability.
I've updated the prelim documentation for the TS-7400 on our website to
reflect this new functionality at http://www.embeddedarm.com/Manuals/ts-
7400-info.txt
Many bootloader's that advertise failover functionality have a very
narrow definition of what is considered a "failure"-- I believe only
the product designer can properly specify "failure" of the device.
Simply calling failure to boot a kernel or a kernel panic IMHO is
narrow-- what happens if the kernel locks up 10 minutes after bootup?
Or your application attempts to access a /dev device and the driver
gives junk data? This is why you use the watchdog and only feed it
while your _system_, not your _kernel_ is operational. The kernel
rarely represents the weakest link in software reliability (at least I
would hope not).
In case its not obvious on how the "bootload" program accomodates
failover, I'd like to illustrate this with the below potential
configuration.
1) Have two kernels in the YAFFS2 filesystem: /latest.bin
and /knowngood.bin.
2) By default, symlink latest.bin to /vmlinux.bin. Symlinking in
YAFFS2 should be an atomic operation.
3) Before you start feeding the watchdog in application code, your
application re-symlinks /knowngood.bin to /vmlinux.bin. I firmly
believe you should feed the watchdog in your own application code as I
believe letting the kernel do it automatically defeats the point of the
watchdog.
4) If your watchdog expires and the board resets, the system will
boot /knowngood.bin. Your application can do some sort of self-check
and if all seems well, resymlink /latest.bin to /vmlinux.bin and then
bootload the /latest.bin kernel directly. Application code can change
behavior based upon what /vmlinux.bin points to (/knowngood.bin
vs. /latest.bin) which says whether or not the last reset was caused by
the watchdog. If you wanted to be really careful, only
make /latest.bin the default by symlinking it in after 15 minutes of
proper system operation.
5) Before graceful shutdown, your application could reset the symlink
back to /latest.bin to avoid the double-bootload and software self-check
that would be caused otherwise-- or you could just leave it in to
always preceed the invocation of your application with a product
specific self-check.
//Jesse Off
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/ts-7000/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/ts-7000/join
(Yahoo! ID required)
<*> To change settings via email:
<*> To unsubscribe from this group, send an email to:
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
|