On 12/07/2012 08:07 AM, Antonio Terceiro wrote:
On Fri, Dec 07, 2012 at 09:24:37AM +0200, Fathi Boudra wrote:
On 5 December 2012 17:33, Andy Doan andy.doan@linaro.org wrote:
On 12/05/2012 07:47 AM, Antonio Terceiro wrote:
When we have SD muxe, then we might use lamc for all devices, but until then the dispatcher would have to be taught what to do with the hwpack file.
Antonio is correct. For our "master devices" which account for probably 90% of our Android jobs, we do our own special stuff with tarballs. So we have options:
- change nothing - assuming the {boot,system,userdata}.tar.bz2 still have
everything. sounds unlikely
change our master device logic to do whatever new process is required
extend our prebuilt image support to android (we currently only do
pre-built images for ubuntu)
Pre-built image support is available on Android as well: http://snapshots.linaro.org/android/~linaro-android/vexpress-jb-gcc47-armlt-...
It's controlled by BUILD_FS_IMAGE in build configuration.
imo, LAVA shouldn't do its own special stuff but use l-a-m-c or the pre-built image.
I guess everyone agrees with you. :-)
+ infinity
The problem is, without an SD mux, there is no way for the host to flash images to the SD card on the target. For this we must have a known-good system running on the target, what we call a master image. The LAVA makes the master image system flash the test image parts to additional SD card partitions (i.e. we must keep the partitions with kernel/rootfs for the master system intact).
That is the case even for pre-built images. LAVA has to extract the contents of its partitions and have the master system flash them to the SD card before rebooting into the test system.
To add to the difficulty, Android's unitird's init.rc (I think that's the file) is set up to mount to specific partition *numbers*. This doesn't work at all for LAVA so we have to use horrible sed/awk style stuff to make sure Android's "system" partition is really partition 5 and not 2 :(