Back to the public list...
On Sun, 1 Apr 2012 21:28:06 -0500, Paul Larson paul.larson@linaro.org wrote:
On Thu, Mar 29, 2012 at 8:55 PM, Zygmunt Krynicki < zygmunt.krynicki@linaro.org> 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
On Mon, Apr 2, 2012 at 12:41 AM, Michael Hudson-Doyle < michael.hudson@linaro.org> wrote:
Back to the public list...
On Sun, 1 Apr 2012 21:28:06 -0500, Paul Larson paul.larson@linaro.org wrote:
On Thu, Mar 29, 2012 at 8:55 PM, Zygmunt Krynicki < zygmunt.krynicki@linaro.org> 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?
Correct. It's not that different from how we operate now, just that the location would be moved up so that the test partition would be on the first partition with the regular boot. As a side note, this would also eliminate the need for understanding partition offsets, and also make it much easier to re-use the boot.scr from the image itself!
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.
No, I think it's best just to push the bits we need rather than blast the whole thing across and hope that we don't hit an error part-way through.
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).
exactly, and the dispatcher already keeps track of which mode it's in, as it has to force the boot for the test image, and not for the recovery image.
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...
Yes, this is the concern. It should obviously be stripped down as much as possible. Thanks, Paul Larson
On Mon, 2 Apr 2012 09:39:26 -0500, Paul Larson paul.larson@linaro.org wrote:
On Mon, Apr 2, 2012 at 12:41 AM, Michael Hudson-Doyle < michael.hudson@linaro.org> wrote:
Back to the public list...
On Sun, 1 Apr 2012 21:28:06 -0500, Paul Larson paul.larson@linaro.org wrote:
On Thu, Mar 29, 2012 at 8:55 PM, Zygmunt Krynicki < zygmunt.krynicki@linaro.org> 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?
Correct. It's not that different from how we operate now, just that the location would be moved up so that the test partition would be on the first partition with the regular boot. As a side note, this would also eliminate the need for understanding partition offsets, and also make it much easier to re-use the boot.scr from the image itself!
Yeah, that might be nice.
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.
No, I think it's best just to push the bits we need rather than blast the whole thing across and hope that we don't hit an error part-way through.
Right.
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).
exactly, and the dispatcher already keeps track of which mode it's in, as it has to force the boot for the test image, and not for the recovery image.
The part that bothers me about this would be the need to repartition the rest of the image to match the generated image... it wouldn't be hard, but it would be tedious I expect.
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...
Yes, this is the concern. It should obviously be stripped down as much as possible.
Yeah. I wonder if it's worth doing this work or waiting for the sd card muxers...
Cheers, mwh
linaro-validation@lists.linaro.org
-
Michael Hudson-Doyle -
Paul Larson