From: Eric A. <eri...@ya...> - 2004-08-11 11:03:57
|
Hi All, I heard of a trick once that may save a lot of grief when developing/swapping out kernels. It's called "The Two Kernel Monte" and was initiated by none other than Donald Becker (original author of most of the Linux ethernet drivers.) http://sourceforge.net/projects/monte/ The idea is that you load a standard kernel into flash that is capable of minimally starting your hardware and mounting your storage device, then you load the "real" kernel you want to run from storage. This would allow you to change the kernel configuration on your mmc card w/o risking damage to the flash image, which seems to be extremely painful to reconstruct. It would be slower to boot than starting up directly from flash, but at this point in gumstix development, I wonder if the simplicity of updating kernel drivers wouldn't be a big win. Regards, -Eric. ===== Eric Z. Ayers eri...@ya... http://www.ayershome.org/~eric/ |
From: Kim H. <ki...@ki...> - 2004-08-11 11:15:15
|
> Hi All, > > I heard of a trick once that may save a lot of grief when > developing/swapping out kernels. It's called "The Two Kernel Monte" > and was initiated by none other than Donald Becker (original author of > most of the Linux ethernet drivers.) > > http://sourceforge.net/projects/monte/ > > The idea is that you load a standard kernel into flash that is capable > of minimally starting your hardware and mounting your storage device, > then you load the "real" kernel you want to run from storage. This > would allow you to change the kernel configuration on your mmc card w/o > risking damage to the flash image, which seems to be extremely painful > to reconstruct. > > It would be slower to boot than starting up directly from flash, but at > this point in gumstix development, I wonder if the simplicity of > updating kernel drivers wouldn't be a big win. That sounds much like the initial ram disks used to load a kernel capable of driving scsi disk so that the scsi disk driving modules can be loaded from the scsi disk :) (Hence the chicken egg problem). Indeed, this sort of approach would pay off. I think the last suggestion amounts to much the same thing though, except that instead of loading the kernel from flash that loads the kernel from MMC you are loading straight from MMC. However, I think it could be quite a desireable thing to have the flash-based loading process to do a quick check on the MMC "for something" that indicates whether or not a kernel should load from MCC or from the standard kernel. However, having said that. Changing environment variables can be considered analogous to changing the boot device in a standard pc. But, it could have the advantage that new gumsticks could be shipped in a state where kernel development can proceed without "ever" having to take the risk of changing flash even once. Allowing new developments to more safely proceed without hickups and delays. Thanks for the link! - Kim |
From: Craig H. <cr...@hu...> - 2004-08-15 12:02:33
|
The approach that I've taken on this is to put the kernel in the jffs2 filesystem. If you trash your kernel somehow, you don't need to rebuild the rootfs, but merely to use u-boot to loadb or fatload a different kernel either over serial or from an MMC card, then boot that. It'll use the jffs2 image as rootfs, and you can then copy the new kernel image to /boot/uImage. Pretty simple recovery process. Really the only tricky part is when you're upgrading u-boot, and *that* fails. Currently, JTAG is the only solution. Might be worth investigating/thinking about a two-uboot-monte solution though... C On Aug 11, 2004, at 12:15 PM, Kim Hendrikse wrote: >> Hi All, >> >> I heard of a trick once that may save a lot of grief when >> developing/swapping out kernels. It's called "The Two Kernel Monte" >> and was initiated by none other than Donald Becker (original author of >> most of the Linux ethernet drivers.) >> >> http://sourceforge.net/projects/monte/ >> >> The idea is that you load a standard kernel into flash that is capable >> of minimally starting your hardware and mounting your storage device, >> then you load the "real" kernel you want to run from storage. This >> would allow you to change the kernel configuration on your mmc card >> w/o >> risking damage to the flash image, which seems to be extremely painful >> to reconstruct. >> >> It would be slower to boot than starting up directly from flash, but >> at >> this point in gumstix development, I wonder if the simplicity of >> updating kernel drivers wouldn't be a big win. > > That sounds much like the initial ram disks used to load a kernel > capable of > driving scsi disk so that the scsi disk driving modules can be loaded > from the > scsi disk :) (Hence the chicken egg problem). Indeed, this sort of > approach > would pay off. I think the last suggestion amounts to much the same > thing > though, except that instead of loading the kernel from flash that > loads the > kernel from MMC you are loading straight from MMC. However, I think it > could be > quite a desireable thing to have the flash-based loading process to do > a quick > check on the MMC "for something" that indicates whether or not a > kernel should > load from MCC or from the standard kernel. However, having said that. > Changing > environment variables can be considered analogous to changing the boot > device in > a standard pc. But, it could have the advantage that new gumsticks > could be > shipped in a state where kernel development can proceed without "ever" > having > to take the risk of changing flash even once. Allowing new > developments to more > safely proceed without hickups and delays. > > Thanks for the link! > > - Kim > > > ------------------------------------------------------- > SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media > 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 > Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. > http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 > _______________________________________________ > gumstix-users mailing list > gum...@li... |