On Mon, 2020-12-14 at 05:13 +0900, Ryutaroh Matsumoto wrote: > > The rpi flavour doesn't have those constraints, though. What would be > > the benefit of booting it in UEFI mode? > > Thank you for paying your attention! > I considered extending autopkgtest-virt-qemu to armel (and other archs) testbeds at > https://salsa.debian.org/ci-team/autopkgtest/-/merge_requests/100#note_205984 > > To boot a qemu disk image by qemu-system-*, a booting firmware seems > indispensable, as the autopkgtest maintainer does not like giving -kernel=something > qemu option as > https://salsa.debian.org/ci-team/autopkgtest/-/merge_requests/97#note_205357 OK, this seems like a good reason. We used to provide a 'versatile' flavour on armel, for the ARM Versatile boards that QEMU has supported for a long time. I removed this flavour back in 2016 after finding that it had been broken for a while and no-one had reported it. Adding that back might be an option, if the Raspberry Pi device emulation in QEMU is slow. What do you think? > A booting firmware for an armel Debian disk image seems only > the qemu-efi-arm Debian package (is there anything else??). The usual practice is to use u-boot or some other board-specific boot loader, which can be configured by the flash-kernel package. I don't think that works in QEMU. Ben. > So I resorted to the UEFI booting. > Currently I proposes to use linux-image-armmp-lpae for armel testbed. -- Ben Hutchings The two most common things in the universe are hydrogen and stupidity.
Attachment:
signature.asc
Description: This is a digitally signed message part