Vincent Legoll wrote:
And a coreboot using them could probably be argued to be a derivative work of the factory BIOS, and that is not so good from a licensing perspective.
That would be subject to local copyright laws, I think, and providing a way to load external ACPI tables would not be a problem in itself.
Remember though that just using "foreign" acpi tables will not work usually:
* Many DSDTs have pointers to other tables / data which need to be fixed up during runtime or they will access memory in stupid locations * Same applies for IO locations of certain hardware * The ACPI code often communicates with an SMI handler in order to do the deed. If there is no SMI handler there will not be a working ACPI either.
Please look at the ACPI implementation in coreboot to get an idea what is currently there. It will evolve over time. And if you have a system that needs ACPI or benefits from it, the project would gain a lot more if you developed ACPI support for that board instead of borrowing a foreign implementation.
What the final user does with his right or behind his closed doors has no relationship with the fact that we allow to load external files.
What good is going through the effort of replacing your bios if you replace it with a free-/non-free hybrid?
Because we could certainly create the tables from scratch ourselves if we would like... (OK that would certainly be hard, but still...)
We did that for a couple of boards already.
What would be cool, is an option in the coreboot build process to use the ACPI tools to extract tables from the running legacy BIOS and stuff them in the image being built. But would that be technically possible ?
Besides the fact that those tables wouldnt work with coreboot, I believe technically it could be done, as long as you compile on the very system you want to flash. (In which case you exactly have one try to get it right ;)
Stefan