Hello,
While I still have that info fresh in my head, I wrote what I did for the Shuttle SN25P mainboard port.
main page: http://www.coreboot.org/Shuttle_SN25P linked from entry in supported mainboards
Thanks to all who helped me getting there, I hope collaboration will continue.
Vincent Legoll wrote:
Great notes!
Only comment I can think of is to keep the tested kernel options around even if they are discarded as not being useful, to keep record of what has been tried.
//Peter
On Thu, Sep 4, 2008 at 4:11 PM, Peter Stuge peter@stuge.se wrote:
Vincent Legoll wrote:
Great notes!
Only comment I can think of is to keep the tested kernel options around even if they are discarded as not being useful, to keep record of what has been tried.
I'll try to keep a StepByStep section with all necessary infos.
But I intend to have a coreboot which is able to run the linux kernel without special parameters, is that a realistic goal to aim for ?
Remember, I'm a newbie, I don't really understand (yet) what I'm modifying in coreboot...
An area where I need something explained (that I didn't found in the wiki) is: what would be required to have ACPI working ?
Couldn't we extract the tables from legacy BIOS and use them within coreboot, if we don't stuff them in svn we should be fine. At least as fine as people who extract them and load them with the linux kernel... Or are there other things in ACPI that cannot be extracted ?
Vincent Legoll wrote:
But I intend to have a coreboot which is able to run the linux kernel without special parameters, is that a realistic goal to aim for ?
I think so.
An area where I need something explained (that I didn't found in the wiki) is: what would be required to have ACPI working ?
Couldn't we extract the tables from legacy BIOS and use them within coreboot, if we don't stuff them in svn we should be fine.
No, you would be fine, noone else. We can't redistribute ACPI tables from the factory BIOS. 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.
//Peter
On Thu, Sep 4, 2008 at 4:49 PM, Peter Stuge peter@stuge.se wrote:
An area where I need something explained (that I didn't found in the wiki) is: what would be required to have ACPI working ?
Couldn't we extract the tables from legacy BIOS and use them within coreboot, if we don't stuff them in svn we should be fine.
No, you would be fine, noone else. We can't redistribute ACPI tables from the factory BIOS.
I explicitely said they wouldn't be redistributed, just as the linux kernel can have an updated DSDT to boot with, we could certainly allow the load of external ACPI tables. But we wouldn't need to distribute them.
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.
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.
Because we could certainly create the tables from scratch ourselves if we would like... (OK that would certainly be hard, but still...)
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 ?
Hi,
The problem with use of original ACPI tables is different resources which might be static in the tables. Like I/O ports (legacy, smbus, pmio etc etc) Plus there might be some regions of memory reserved, which are not on Coreboot etc.
Basically it is not so difficult to create your own ACPI tables.
Check this http://www.coreboot.org/ACPI_in_coreboot
I'm using my own ACPI tables and it works very well.
Rudolf
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
-
Peter Stuge -
Rudolf Marek -
Stefan Reinauer -
Vincent Legoll