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
-----BEGIN PGP SIGNATURE-----
iHUEARYKAB0WIQRlgHNhO/zFx+LkXUXcUY/If5cWqgUCYkaXGgAKCRDcUY/If5cW qkOkAP44IhSPFZQ6dOa4M1hxYalULvu9jV1/q3n12eLge/g1gAEAyRNY0+fsOWat +yHY+fAj1hPodjZlEGJH9ZVQufsYDgc=
=Mb0N
-----END PGP SIGNATURE-----
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)