On Sun, 13 Jul 2014 10:32:46 +0100 Ian Campbell <ijc@hellion.org.uk> wrote: > On Sat, 2014-07-12 at 22:54 +0100, Neil Williams wrote: > > > The big issue with testing installers on ARM is the variability in > > bootloaders and device support. What LAVA can provide is a common > > base. A known working Linaro kernel/bootloader combination could > > get the board to a known state and then use kexec to boot into the > > ARMMP kernel. The first kernel would need to also be using device > > tree and a similar vintage but this could act as an incentive to > > get device support into mainline and hence to be available in ARMMP. > > If I were working on LAVA I'd be rather concerned about relying on > kexec in this way, since IME it's subtle and easy to break (if indeed > it works to start with), but I suppose you deliberately want to catch > that ;-). We have had kexec working in a LAVA context - there are lots of calls and methods used in LAVA which are less reliable... > > What needs to happen in Debian is to make the dtb available to a > > kexec call inside the ISO. > > A kexec call seems to be fairly specific to the lava workflow, I think > we'd want this to be equally usable from u-boot or UEFI, wouldn't we? UEFI yes. u-boot is just too variable. One of the reasons to look at kexec is that it isolates the variability of u-boot support. As a means of testing the installer, u-boot is only usable for one specific type of device at a time and needs to mangle part of the installer or have explicit support already embedded. Not particularly friendly for the ARMMP kernel. However, u-boot support is already in-place for a large number of boards whilst UEFI is not. How many existing boards will add support for UEFI is uncertain. With a kexec, the original u-boot can still be there, so it's potentially less work to get to the point of being able to test. Although LAVA can add this workflow, it isn't specific to LAVA. During testing, LAVA can use a variety of methods to get to the pointed where a suitable kernel has booted and then do the kexec. With that data and the images and calls that produced it, the same method could be scripted (in the same way that my previous company used kexec) to boot the installer on other systems of the same type. Once installed, it's down to u-boot to use the installed files. > Why ISOs BTW? They don't seem all that typical on ARM systems, As a route to the default packaged ARMMP kernel. ISOs are more permanent than a weblink and easier to reproduce over a number of deployments and the Debian ISO has never been tested on ARM. It's also, arguably, the easiest deployment for random developers to set up at home without needing a extra infrastructure or having to get involved in actual uboot commands. > wouldn't netboot be more normal? We already publish the DTBs for > those e.g. > http://d-i.debian.org/daily-images/armhf/daily/device-tree/ (needs a > new upload of d-i before that layout will hit Jessie) Didn't know about those .... https://staging.validation.linaro.org/scheduler/job/49915/log_file#L_57_136 Not sure how to convert the console output to something recognisable or how to get LAVA to recognise that output, but it looks reasonable to me.... (I had to cancel it or LAVA would have started sending newline characters which then could have started the install process using all the default options ...) /me goes to find a monitor & keyboard which will connect to a BBB .... > [...] > > > Proposal: /boot/dtbs/ ? > > IIRC the isos currently put the kernel in /install.$ARCH (to allow for > hybrid disks, I suppose). > > Whatever path is chosen I reckon it should be consistent with whatever > the outcome of > https://wiki.linaro.org/Platform/DeviceTreeConsolidation is. i.e. the > subpath (bit after /boot or /install.$ARCH) at least should be > consistent. True. -- Neil Williams ============= http://www.linux.codehelp.co.uk/
Attachment:
signature.asc
Description: PGP signature