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 ;-). > 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? Why ISOs BTW? They don't seem all that typical on ARM systems, 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) [...] > 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. Ian. -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1405243966.11981.67.ca...@dagon.hellion.org.uk
