Hi,
On 10/22/24 05:44, Aurelien Jarno wrote:
This is a native package useful for the riscv64 port, but which might also be useful for some arm boards, therefore the goal is to provide the binary as a arch:all package.
I remember the absolute insanity when ACPI was new and we basically
assumed any pre-2000 BIOS would have bad tables, and if you wanted ACPI,
you needed to bring your own tables.
I do not wish to repeat this experience, and my feeling is that the way
the boot specifications are written for riscv, with every side pushing responsibility away from themselves, we are going exactly that way.
Information about mainboard resources needs to be provided by the
bootloader to the OS. Whether that happens as a proper device tree, a
flat one, or as instructions how to build one (as with ACPI) is not
relevant as much as who is responsible for determining how much RAM is
actually present, and where.
I wonder if it would make sense for Debian to throw a bit of weight
around and communicate to vendors that they can not expect us to ship
and update DTBs for their devices in a stable release, and if they want
trixie to be bootable without any vendor specific tricks, they ought to
provide a device tree containing mainboard resources from their
first-stage bootloader so it is already accessible to OpenSBI, and
whatever bootloader is called from that will only amend it with runtime information like commandline parameters and address assignments of PCIe devices, not replace it as a whole -- because that is a complete
maintenance and usability nightmare.
Simon
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)