Back to the public list... On Sun, 1 Apr 2012 21:28:06 -0500, Paul Larson <[email protected]> wrote: > On Thu, Mar 29, 2012 at 8:55 PM, Zygmunt Krynicki < > [email protected]> wrote: > > > W dniu 30.03.2012 03:40, Le.chi Thu pisze: > > > > > This worry me because the hold ideal with automation is you should > > > able to recycle the device (when it stop responding). > > > > Yes but to do that you need reliable recovery boot method, typically > > that is external to the device. We may be able to do this once PXE > > booting and UEFI are commonplace. > > > Or, a piece of hardware that allows you to write/read directly to the sd > from an external system. :) That's the long-term goal, but not so far off > as you might think. > > Short term, I still think a tiny initramfs is the way to go.
So how would this work? Please excuse the train of consciousness style below... I guess the idea is that you have two uImage & uInitrd files on /boot, and choose between them using uboot commands and so select booting into test mode or master mode? One extreme approach would be to have the master mode just dd an image file completely over the mmc -- if you did this with the output of l-m-c we'd have no way of recovering, but maybe we could run l-m-c on the server, mush the boot partition of the image around a bit so that it used a known good bootloader and booted to the master mode kernel & initrd by default, then blat that over the mmc. We could be more gentle in the master image, but that feels to me like although we'd be able to use the expected partition layout, the dispatcher/master image agent would have to know what it _was_ and that's still pretty tedious -- although I guess you could just clone the layout from the image file produced by l-m-c.... This feels like it would be more reliable (e.g. losing power while the image is being blatted over the mmc would presuambly require manual recovery). I guess we'd have to be careful about resource consumption in our initramfs -- presumably one has to fit rootfs and all RAM usage within the RAM of the boards? I think Beagle xM's are our least capable boards with half a gig of RAM, but all the others have a gig? That's reasonably generous I guess, and we can customize our rootfs pretty significantly, but I don't know if we'd want to write the master agent in Python in this environment... Cheers, mwh _______________________________________________ linaro-validation mailing list [email protected] http://lists.linaro.org/mailman/listinfo/linaro-validation
