Debian-Installer support for riscv64
[crossposted to debian-boot and debian-riscv]
Hello everybody,
I'm working on getting d-i support for riscv64 into a useable
state. With the recent upload of elfutils 0.176-1.1 into the
archive it is now possible to complete the "install the base
system" step on riscv64. What is still missing is bootloader
support, for which there are two general options on riscv64:
- plain U-Boot
- EFI GRUB, either
- loaded directly from an EDKII-based EFI firmware or
- chainloaded from U-Boot's EFI emulation layer
In the long run, we will surely see EFI on riscv64, but right now
there is no riscv64 hardware that ships with an EDKII-based EFI
firmware, the kernel still lacks EFI stub support on riscv64 and
AFAIK some riscv64-related bits in the U-Boot EFI emulation layer
and in EFI GRUB are also still missing, so to have something
usable now, we need to target plain U-Boot first. When booting
from plain U-Boot we have two options:
- boot scripts
- extlinux.conf-style boot menus
Boot scripts can be handled with small modifications to the
flash-kernel package that we currently use for arm-based systems;
a proof-of-concept is available at
https://salsa.debian.org/merker/flash-kernel/tree/riscv64-support
but IMHO extlinux-style boot menus are a lot nicer than the
interface provided by flash-kernel. There are good reasons why
flash-kernel uses boot scripts on arm-based systems, but most of
them have their roots in the historic lack of standardized boot
environments on arm-based platforms and Debian's attempts at
providing compatibility with old vendor U-Boot releases, which is
a problem that we thankfully don't have on riscv64 so that I
would clearly prefer using extlinux-style U-Boot menus on riscv64
(Fedora has AFAIK taken the same decision). I have therefore
made an attempt at implementing a u-boot-menu-installer udeb:
https://salsa.debian.org/merker/u-boot-menu-installer
Unfortunately both EFI support as well as the U-Boot
extlinux-style menus require a small change in the configuration
of our riscv64 kernel packages. A corresponding change request
has been sent to the kernel maintainers, but for now testing the
new udeb requires manually installing a modified kernel package.
One problem that I have stumbled about is the combination of
U-Boot's distro_bootcmd environment and GPT-partitioned disks.
Currently d-i autogenerates GPT-style partition tables for
riscv64 and while things work without problems with DOS-style
partition tables, U-Boot doesn't find the partition to boot from
automatically on a GPT-partitioned disk. The logic used by
U-Boot is "if there is a partition marked as bootable, boot from
it, otherwise check the first partition on the disk for a menu
file or a boot script", which works fine for DOS-style partition
tables where d-i marks the partition used for /boot as "bootable"
and /boot is usually on the first partition anyway. With GPT
this fails because there is AFAICS no "bootable" flag for
partitions and the first partition that d-i creates for
GPT-partitioned disks is the "BIOS GRUB" partition and not the
volume containing /boot. If one tells U-Boot the boot partition
number manually with "setenv distro_bootpart 2", everything
works. When performing an EFI boot, the bootloader is always
loaded from the EFI system partition which can be easily
identified by its UUID, so this never poses a problem for
EFI-based systems, and going back to DOS-style partition tables
isn't really an option with today's hard disk sizes and the
2GB-limit inherent in the DOS-style partition table format.
Ideas how to solve this welcome - the only approach I currently
see is to change U-Boot's distro_bootcmd logic to check each and
every partition, but I'm not sure that upstream would like that.
Kibi, a question regarding the handling of the the
u-boot-menu-installer package: As it only contains shell scripts,
in conformance with normal policy rules I have marked it as an
arch-all package that limits its execution to riscv64 with an
"isinstallable" file, but AIUI that would mean that it would
potentially be pulled in by d-i builds for other architectures,
although it wouldn't be executed there. Should I make a
riscv64-specific package out of it due to potential d-i image
size issues on armel?
Another thing that needs to be tackled in d-i is an annoying
property of qemu's riscv64 "virt" machine: The "virt" machine
emulates both a normal serial console (/dev/ttyS0) and a HVC
console (/dev/ttyhvc0). Unfortunately in qemu both share the
same physical console device and systemd starts a getty on both
/dev/ttyS0 and /dev/ttyhvc0 so that we have two getty instances
running on the same physical console which wreks havoc. I would
therefore like to add a job to finish-install that tells systemd
to run no getty on dev/ttyhvc0 by creating a symlink from
/etc/systemd/system/serial-getty@hvc0.service to /dev/null inside
/target if it detects that it is run on a qemu riscv64 "virt"
machine. Would that be ok for you?
Regards,
Karsten
--
Ich widerspreche hiermit ausdrücklich der Nutzung sowie der
Weitergabe meiner personenbezogenen Daten für Zwecke der Werbung
sowie der Markt- oder Meinungsforschung.
Reply to: