On 2022-04-01, Steve McIntyre wrote: > On Sat, Mar 26, 2022 at 09:30:25AM +0100, Domenico Andreoli wrote: >>How the u-boot boot.scr is supposed to be created on a riscv machine? >> >>On arm, flash-kernel would do the job. Is there any better alternative >>or is it going to be used on riscv as well? >> >>What are the plans here? > > I'm assuming that for riscv devices using U-Boot we should add > flash-kernel there too. We'll need to build a hardware database there > too. AFAICS Vagrant (in CC) is the most active flash-kernel developer > at the moment, maybe he can help you.
I think someone was working on patches for riscv64 for flash-kernel; definitely discussed it recently, at least. That said, I'm not terribly fond of flash-kernel... so I wonder if it is the best way forward for a newer architecture. Mostly on arm* and riscv64 I use the u-boot-menu package to generate a syslinux-style extlinux.conf file, as it presents a menu to select between kernel versions and doesn't need device-specific knowledge about which .dtb to use; it defaults to using the appropriate .dtb from /usr/lib/linux-image-VERSION/. In some ways generating a boot.scr with flash-kernel is a bit more flexible, such as the various /etc/flash-kernel/*.d hooks, if you need to do something clever like use an alternate .dtb to the one u-boot thinks you should use, or modify the .dtb in flight... At least now flash-kernel and u-boot-menu play reasonably well together; having both installed is perfectly reasonable. At some point it might be nice to drop flash-kernel for the most part on armhf and riscv64 (and arm64?) platforms in debian-installer, though I haven't invested the time to figure out what all that might take. For one thing, *most* of flash-kernel's manually curated all.db could be replaced with something generated at kernel build time (parsing out the model entries from their respective .dtb files). Most of the entries in all.db for armhf and arm64 are pretty much boilerplate if they use bootscr.uboot-generic. The few that aren't could be treated as exceptional odd ducks. The older armel systems, maybe keep around as long as armel is kept around. That said, the curated flash-kernel all.db means someone has (probably?) at some point tested that a particular setup works... though it also means another set of hoops to jump through to enable a previously unsupported platform. Another option would be instead to copy *all* the .dtb files for a particular kernel version into /boot/dtbs/VERSION/; this might require bumping the default size of /boot from 256MB(I think?) to 512MB; I almost always make my /boot partitions larger than the default for debian-installer. Or have the kernel package install them directly into /boot; that would definitely require bumping the default /boot size a bit. For the u-boot based arm64 platforms currently supported in debian-installer, it uses the syslinux-style extlinux.conf instead of generating a boot script. I've thought about migrating armhf over. Maybe riscv64 should take that approach as well? Then, of course, there's the whole "just use UEFI" angle... not sure what the state of UEFI implementations for riscv64 are. If it uses a modern u-boot, it should have a fairly capable EFI implementation, even if it doesn't have a "pure" or "native" UEFI implementation. Wow, clearly I have *opinions* on all this... So many opinions, so little time for implementation! live well, vagrant
signature.asc
Description: PGP signature
