Bug#977126: linux: No armel kernel can be booted by grub-efi-arm:armel

[Ryutaroh Matsumoto]

Hi Ben,

> But linux-image-rpi does not have the virtio driver, this option cannot
> be used (at least for now).
> 
> Can you try adding it?  You should be able to cross-build the kernel
> package quite easily if you use the profiles "cross,pkg.linux.notools".
> There are generic instructions at
> .

Thanks. I will. But please give me some time as I am in my working hour... 
I didn't have experience with u-boot'ing a Debian kernel, so maybe I need some
time to correctly build a qemu bootable image by u-boot-rpi:armel package...
Ryutaroh

Bug#977126: linux: No armel kernel can be booted by grub-efi-arm:armel

[Ben Hutchings]

On Mon, 2020-12-14 at 10:24 +0900, Ryutaroh Matsumoto wrote:
Hi Ben, thanks again for your response.

> 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?

If nobody uses linux-image-versatile now, I don't want to request the
kernel team to revive it. It may/might increase the maintainance
effort...

It will, though probably not very much.

The minimum requirements by autopkgtest-virt-qemu are
* VM has at least two serial ports,
* the Linux kernel has a driver for them, and
* the Linux kernel has a driver for a storage attached to the VM.

On the other hand, RPi series has only one serial port by PL011.
So we need to attach another serial port to the VM. For armhf, arm64,
and ppc64el, I was advised to use virtconsole by Simon McVittie,
and it has worked fine as far as I see.

But linux-image-rpi does not have the virtio driver, this option cannot
be used (at least for now).

Can you try adding it?  You should be able to cross-build the kernel
package quite easily if you use the profiles "cross,pkg.linux.notools".
There are generic instructions at
.

[...]
> 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.

I have not intensively investigated if we can boot linux-image-marvell
by qemu-system-arm and some u-boot Debian package...
I will see it within several days and report it back here.
First I will see u-boot-qemu Debian package and the qemu "virt" machine
can boot linux-image-marvell as suggested at
https://github.com/ARM-software/u-boot/blob/master/doc/README.qemu-arm

It won't - it has very different hardware.  Even the CPU will be
incompatible (ARMv7 whereas marvell is built for v5).

Ben.

linux-image-marvell seems capable of handling PCI serial ports.
Storage options for QEMU VM seems only "ich9-ahci" and "sdhci-pci"...

Best regards, Ryutaroh

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


signature.asc
Description: This is a digitally signed message part

Bug#977126: linux: No armel kernel can be booted by grub-efi-arm:armel

[Ryutaroh Matsumoto]

Hi Ben, thanks again for your response.

> 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?

If nobody uses linux-image-versatile now, I don't want to request the
kernel team to revive it. It may/might increase the maintainance effort...

The minimum requirements by autopkgtest-virt-qemu are
* VM has at least two serial ports,
* the Linux kernel has a driver for them, and
* the Linux kernel has a driver for a storage attached to the VM.

On the other hand, RPi series has only one serial port by PL011.
So we need to attach another serial port to the VM. For armhf, arm64,
and ppc64el, I was advised to use virtconsole by Simon McVittie,
and it has worked fine as far as I see.

But linux-image-rpi does not have the virtio driver, this option cannot
be used (at least for now). Another option is to attach "pci-serial-2x"
to the qemu VM, but linux-image-rpi does not seem to have a PCI driver...
Yet another option is to attach "qemu-xhci" and "usb-serial" to the VM,
but "usb-serial" behaves much differently from isa/pci-serial and virtconsole
and it cannot be used by the current autopkgtest-virt-qemu as reported at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=973038#40

> 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.

I have not intensively investigated if we can boot linux-image-marvell
by qemu-system-arm and some u-boot Debian package...
I will see it within several days and report it back here.
First I will see u-boot-qemu Debian package and the qemu "virt" machine
can boot linux-image-marvell as suggested at
https://github.com/ARM-software/u-boot/blob/master/doc/README.qemu-arm

linux-image-marvell seems capable of handling PCI serial ports.
Storage options for QEMU VM seems only "ich9-ahci" and "sdhci-pci"...

Best regards, Ryutaroh

Bug#977126: linux: No armel kernel can be booted by grub-efi-arm:armel

[Ben Hutchings]

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.


signature.asc
Description: This is a digitally signed message part

Bug#977126: linux: No armel kernel can be booted by grub-efi-arm:armel

[Ryutaroh Matsumoto]

> 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

A booting firmware for an armel Debian disk image seems only
the qemu-efi-arm Debian package (is there anything else??).
So I resorted to the UEFI booting.
Currently I proposes to use linux-image-armmp-lpae for armel testbed.

Best regards, Ryutaroh

Processed: Re: Bug#977126: linux: No armel kernel can be booted by grub-efi-arm:armel

[Debian Bug Tracking System]

Processing control commands:

> tag -1 moreinfo
Bug #977126 [src:linux] linux: No armel kernel can be booted by 
grub-efi-arm:armel
Added tag(s) moreinfo.

-- 
977126: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977126
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#977126: linux: No armel kernel can be booted by grub-efi-arm:armel

[Ben Hutchings]

Control: tag -1 moreinfo

On Fri, 2020-12-11 at 19:09 +0900, Ryutaroh Matsumoto wrote:
> Source: linux
> Version: 5.9.11-1
> Severity: important
> X-Debbugs-Cc: pkg-grub-de...@alioth-lists.debian.net
> 
> Dear Maintainer,
> 
> grub-efi-arm:armel package remains almost unusable for very long time.
> To boot a kernel in UEFI mode, it must be compiled with CONFIG_EFI.
> But no Debian armel kernel (specifically linux-image-marvell or
> linux-image-rpi) is built with CONFIG_EFI.
> This leaves armel grub-efi-arm package almost useless.

I wasn't aware that this package existed until now...

> For example, trying to boot linux-image-marvell by grub-efi-arm:armel
> shows the following message:
[...]

The marvell flavour is constrained by memory and partition limits on
many of the supported machines, so it is unlikely that we would want to
increase its size further by enabling EFI support.

The rpi flavour doesn't have those constraints, though.  What would be
the benefit of booting it in UEFI mode?

Ben.


-- 
Ben Hutchings
The two most common things in the universe are hydrogen and stupidity.


signature.asc
Description: This is a digitally signed message part

Bug#977126: linux: No armel kernel can be booted by grub-efi-arm:armel

[Ryutaroh Matsumoto]

Source: linux
Version: 5.9.11-1
Severity: important
X-Debbugs-Cc: pkg-grub-de...@alioth-lists.debian.net

Dear Maintainer,

grub-efi-arm:armel package remains almost unusable for very long time.
To boot a kernel in UEFI mode, it must be compiled with CONFIG_EFI.
But no Debian armel kernel (specifically linux-image-marvell or
linux-image-rpi) is built with CONFIG_EFI.
This leaves armel grub-efi-arm package almost useless.

For example, trying to boot linux-image-marvell by grub-efi-arm:armel
shows the following message:

Welcome to GRUB!

error: no suitable video mode found.
  Booting `Debian GNU/Linux'

Loading Linux 5.9.0-4-marvell ...
error: plain image kernel not supported - rebuild with CONFIG_(U)EFI_STUB
enabled.
Loading initial ramdisk ...
error: you need to load the kernel first.

On the other hand, grub-efi-arm:armel can boot linux-image-armmp:armhf.

This feature/bug leaves grub-efi-arm:armel almost useless,
so I chose "important" priority.

Best regards, Ryutaroh Matsumoto


-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: arm64 (aarch64)

Kernel: Linux 5.9.0-4-arm64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_CRAP
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)