On Tue, 15 Jul 2014 13:22:04 +0100 Ian Campbell <i...@hellion.org.uk> wrote:
> On Sun, 2014-07-13 at 11:48 +0100, Neil Williams wrote: > > On Sun, 13 Jul 2014 10:32:46 +0100 > > Ian Campbell <i...@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. > > > > > > > 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. > > But how do you boot that initial kernel (the one which does the kexec) > if not via u-boot? Sorry, let me clarify: ... isolates the variability of the u-boot support behind a common layer - i.e. LAVA doing somewhat the job of UEFI of booting the board with all kinds of magic variables and tricks to boot the first kernel to get to a point where the kexec can be done. This can provide a way to boot devices which haven't got (and aren't likely to get) UEFI support. There are lots of devices involved here, some will work one way, some will work others. For some, an ISO on an SD card + custom commands to u-boot & kexec into the kernel on the SD card is the only way to do it. The point is that this allows testing of the ARMMP kernel, whether or not regular users would get to install Debian using DI. However it gets installed - even a long winded and awkward way - it's still worth running tests once the ARMMP kernel is installed. If only to compare the Debian ARMMP kernel with a Linaro kernel or a vendor kernel. I'm looking at solutions to run tests of the ARMMP kernel across as many ARM devices as I can. Where that also allows testing DI in an approximation of how a real user would do it, so much the better. > > 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. > > I'm not sure what you mean here, what needs mangling in the Debian > installer? > > AFAIK the Debian installer should run on all the platforms which it > supports out of the box, that's the goal at least. I agree on the goal, sadly we're not there yet on armhf. I can boot some devices directly into DI via LAVA from the bootloader but that still requires a bootloader to be on the device and DI doesn't include that in the image (because u-boot is too variable for that). Also, when booting such devices, the DI initrd needs a u-boot header added (which LAVA does automatically) - this isn't something u-boot itself can do in tftp. Sidenote:: d-i.debian.org doesn't work as just the IP address, so the locations cannot be given directly to tftp in u-boot as that needs a serverip and a directory. This makes it harder to replicate what LAVA is doing when testing by hand because the files from d-i.debian.org need to be downloaded to a tftp server directory first. > For platforms which are unsupported I'm not sure why booting the > installer via kexec instead of uboot should make a difference to how > well it bodges along. > > If we care about those platforms we should add the necessary support > for them to the installer, since our end users surely aren't going to > be kexecing from LAVA. True but LAVA can test whether the kernel boots on that device which helps users know that it's worth investing the time in adding any necessary support. Plus it allows comparisons with other kernel builds available for that device. > > 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 > > I don't believe that the netboot installer images hosted on debian.org > change any more or less frequently than the ISOs (that goes for > images/ISO which are part of stable). > > Either way if you care about permanence and reproducibility then you > need to copy the thing locally. For a CI loop, it's common to test every build and then move on, so a weblink is fine for that part. For regular users, yes, a download is better. > > the Debian ISO has never been tested on ARM. > > Is there even any ARM platform out there with a optical drive on it? ISOs are not just about optical drives. (Yes, there are ARMv8 platforms currently available which have DVD rewriters installed). ISOs are also a good way (possibly the most common way) of writing an SD card and the only way to get some devices to boot. > > 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. > > Why does ISO vs. netboot image require more or less infrastructure or > exposure to u-boot commands? I haven't looked at the netboot images yet - just ISO or individual kernel+initrd+dtb downloads using tftp. > > 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.... > > That's the curses installer output. > > I usually use "DEBIAN_FRONTEND=text" if I want to log it rather than > interact with it. Thanks - I also need to work out how to boot the DI kernel & dtb without the DI initrd so that I can login and run tests. The problem there is how to get the modules into the right place. I think LAVA has the support for that, it may need a tweak or two. -- Neil Williams ============= http://www.linux.codehelp.co.uk/
signature.asc
Description: PGP signature
