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
