Hi,
I've made some recent progress with "legacybios". The code will now locate and parse the coreboot table. This means that "legacybios" will now have the correct ram size and will properly populate the e820 map with the info. I've confirmed that my epia-m continues to boot into linux with the recent changes.
I've also fixed a few bugs - slave ide drives are now working for me and apm no longer crashes the linux kernel.
For those that are interested, the code is in git - see:
My next step is going to be getting bios tables (pir, acpi) working so that the legacybios payload doesn't overwrite them. I plan on hacking coreboot-v2 so that it deploys the tables to the top of ram instead of 0xf0000. I then plan on having legacybios locate the tables (by looking at the coreboot table) and then copy the subset of tables that must reside in the 0xf0000 segment.
For those that remember the discussion at:
http://www.coreboot.org/pipermail/coreboot/2008-May/034688.html
I'm basically advocating option (c).
Finally, I've successfully booted windows xp and windows vista under qemu (without using coreboot). Once I get the standard bios tables working, I'll see if I can get them running too.
-Kevin
On Sun, Jun 08, 2008 at 11:37:40PM -0400, Kevin O'Connor wrote:
I've made some recent progress with "legacybios".
One more update - the freedos v1.0 live cd boots and runs on my epia-m. I've also confirmed regular PS2 style keyboard and mouse are working.
-Kevin
-----Original Message----- From: coreboot-bounces@coreboot.org [mailto:coreboot-bounces@coreboot.org] On Behalf Of Kevin O'Connor Sent: Sunday, June 08, 2008 11:38 PM To: coreboot@coreboot.org Subject: [coreboot] latest legacybios update
Hi,
I've made some recent progress with "legacybios". The code will now locate and parse the coreboot table. This means that "legacybios" will now have the correct ram size and will properly populate the e820 map with the info. I've confirmed that my epia-m continues to boot into linux with the recent changes.
I've also fixed a few bugs - slave ide drives are now working for me and apm no longer crashes the linux kernel.
For those that are interested, the code is in git - see:
My next step is going to be getting bios tables (pir, acpi) working so that the legacybios payload doesn't overwrite them. I plan on hacking coreboot-v2 so that it deploys the tables to the top of ram instead of 0xf0000. I then plan on having legacybios locate the tables (by looking at the coreboot table) and then copy the subset of tables that must reside in the 0xf0000 segment.
For those that remember the discussion at:
http://www.coreboot.org/pipermail/coreboot/2008-May/034688.html
I'm basically advocating option (c).
Finally, I've successfully booted windows xp and windows vista under qemu (without using coreboot). Once I get the standard bios tables working, I'll see if I can get them running too.
Great work Kevin :-)
Thanks, Joseph Smith Set-Top-Linux www.settoplinux.org
On Sun, Jun 08, 2008 at 11:37:40PM -0400, Kevin O'Connor wrote:
I plan on hacking coreboot-v2 so that it deploys the tables to the top of ram instead of 0xf0000. I then plan on having legacybios locate the tables (by looking at the coreboot table) and then copy the subset of tables that must reside in the 0xf0000 segment.
For those that remember the discussion at:
http://www.coreboot.org/pipermail/coreboot/2008-May/034688.html
I'm basically advocating option (c).
I still don't want coreboot to know about BIOS tables at all.
Alas, it already does, there is both PIR and ACPI.
Do we really want these BIOS tables to be created by coreboot?
If yes, why shouldn't LegacyBIOS simply be included in coreboot?
If no, how can we fix that?
I would much prefer if any and all table generation could be handled by LegacyBIOS or maybe another, separate, payload. I think it is important to isolate coreboot from BIOSisms, so that new, modern, payloads don't start using BIOS tables created by coreboot because that's what the other kids did, or because it was the only way the information was accessible. I'd like to move away from that scenario.
Is it really the best we can do? :\
//Peter
Peter Stuge wrote:
Do we really want these BIOS tables to be created by coreboot?
If yes, why shouldn't LegacyBIOS simply be included in coreboot?
I definitely think it should. We have half a legacybios in there for VGA init anyways. Obviously as an option. Or, rather, as a dependency when you choose the option "option rom based VGA init" or the option "int13 bootloader".
Stefan
On Mon, 09 Jun 2008 19:20:30 +0200, Stefan Reinauer stepan@coresystems.de wrote:
Peter Stuge wrote:
Do we really want these BIOS tables to be created by coreboot?
If yes, why shouldn't LegacyBIOS simply be included in coreboot?
I definitely think it should. We have half a legacybios in there for VGA init anyways. Obviously as an option. Or, rather, as a dependency when you choose the option "option rom based VGA init" or the option "int13 bootloader".
I like your take on this Stefan. Why not just make it an option in coreboot?
On Mon, Jun 09, 2008 at 01:23:21PM -0400, Joseph Smith wrote:
If yes, why shouldn't LegacyBIOS simply be included in coreboot?
I definitely think it should. We have half a legacybios in there for VGA init anyways. Obviously as an option. Or, rather, as a dependency when you choose the option "option rom based VGA init" or the option "int13 bootloader".
I like your take on this Stefan. Why not just make it an option in coreboot?
Tricky because it drastically changes coreboot's demarcation point.
I also like Stefan's thinking to use LegacyBIOS rather than the built-in half-baked stuff for VGA init, and int 13.
That's just one rather simple BIOSism though, the callbacks during coreboot runtime. Whether they should remain for the payload is another matter, as are the tables.
//Peter
Peter Stuge wrote:
I still don't want coreboot to know about BIOS tables at all.
Alas, it already does, there is both PIR and ACPI.
Because they are required by Linux.
Do we really want these BIOS tables to be created by coreboot?
probably.
If yes, why shouldn't LegacyBIOS simply be included in coreboot?
maybe but legacybios has a lot of things coreboot (for Linux) doesn't need. They are required for other OS.
If no, how can we fix that?
I would much prefer if any and all table generation could be handled by LegacyBIOS or maybe another, separate, payload.
Then that payload has to have the knowledge of every cpu, chipset, and motherboard configuration to extract the information. That is difficult which is why the OS leaves it up the the BIOS. It make sense that the tables are generated and used by the configuration code.
Marc
On Mon, Jun 09, 2008 at 11:23:51AM -0600, Marc Jones wrote:
I still don't want coreboot to know about BIOS tables at all.
Alas, it already does, there is both PIR and ACPI.
Because they are required by Linux.
Wasn't that supposed to change though? Does anyone know what happened with the x86 device tree?
Do we really want these BIOS tables to be created by coreboot?
probably.
If yes, why shouldn't LegacyBIOS simply be included in coreboot?
maybe but legacybios has a lot of things coreboot (for Linux) doesn't need. They are required for other OS.
Yep, but it is so nice to optimize them away when running Linux.
I would much prefer if any and all table generation could be handled by LegacyBIOS or maybe another, separate, payload.
Then that payload has to have the knowledge of every cpu, chipset, and motherboard configuration to extract the information. That is difficult which is why the OS leaves it up the the BIOS. It make sense that the tables are generated and used by the configuration code.
We already have some if not all of this information in coreboot. I think the ideal would be to allow payloads to use all that information in a handy way, rather than only through BIOS tables.
Seems this is our hot potato.
//Peter
On Mon, 9 Jun 2008 19:39:50 +0200, Peter Stuge peter@stuge.se wrote:
On Mon, Jun 09, 2008 at 11:23:51AM -0600, Marc Jones wrote:
I still don't want coreboot to know about BIOS tables at all.
Alas, it already does, there is both PIR and ACPI.
Because they are required by Linux.
Wasn't that supposed to change though? Does anyone know what happened with the x86 device tree?
Do we really want these BIOS tables to be created by coreboot?
probably.
If yes, why shouldn't LegacyBIOS simply be included in coreboot?
maybe but legacybios has a lot of things coreboot (for Linux) doesn't need. They are required for other OS.
Yep, but it is so nice to optimize them away when running Linux.
Thus making it a coreboot option for other OS's
I would much prefer if any and all table generation could be handled by LegacyBIOS or maybe another, separate, payload.
Then that payload has to have the knowledge of every cpu, chipset, and motherboard configuration to extract the information. That is difficult which is why the OS leaves it up the the BIOS. It make sense that the tables are generated and used by the configuration code.
We already have some if not all of this information in coreboot. I think the ideal would be to allow payloads to use all that information in a handy way, rather than only through BIOS tables.
Why not just have it so legacybios just reads this info from coreboot and creates the desired tables?
On Mon, Jun 09, 2008 at 05:39:58PM -0400, Joseph Smith wrote:
I would much prefer if any and all table generation could be handled by LegacyBIOS or maybe another, separate, payload.
Then that payload has to have the knowledge of every cpu, chipset, and motherboard configuration to extract the information. That is difficult which is why the OS leaves it up the the BIOS. It make sense that the tables are generated and used by the configuration code.
We already have some if not all of this information in coreboot. I think the ideal would be to allow payloads to use all that information in a handy way, rather than only through BIOS tables.
Why not just have it so legacybios just reads this info from coreboot and creates the desired tables?
Yes, that is exactly how I would like it to work.
//Peter
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Yes, that is exactly how I would like it to work.
Sorry I think this is not possible due to ACPI bloatness. It would require ASL compiler RUNTIME. And as Marc already wrote, the legacybios would need to know lot a lot of details about each board. I would suggest to leave it as it is and let the coreboot create the tables. If you dont like them, you can always ignore/delete them (or not create if you are creating some OS which can do that)
Rudolf
-----Original Message----- From: coreboot-bounces@coreboot.org [mailto:coreboot-bounces@coreboot.org] On Behalf Of Rudolf Marek Sent: Monday, June 09, 2008 6:20 PM To: coreboot@coreboot.org Subject: Re: [coreboot] coreboot BIOSisms
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Yes, that is exactly how I would like it to work.
Sorry I think this is not possible due to ACPI bloatness. It would require ASL compiler RUNTIME. And as Marc already wrote, the legacybios would need to know lot a lot of details about each board. I would suggest to leave it as it is and let the coreboot create the tables. If you dont like them, you can always ignore/delete them (or not create if you are creating some OS which can do that)
Couldn't we just add a little mini program in between the two that is just responsible for reporting all of the necessary data from coreboot to legacybios?
Thanks, Joseph Smith Set-Top-Linux www.settoplinux.org
On Mon, Jun 09, 2008 at 07:03:46PM +0200, Peter Stuge wrote:
On Sun, Jun 08, 2008 at 11:37:40PM -0400, Kevin O'Connor wrote:
http://www.coreboot.org/pipermail/coreboot/2008-May/034688.html
I'm basically advocating option (c).
Do we really want these BIOS tables to be created by coreboot?
If yes, why shouldn't LegacyBIOS simply be included in coreboot?
If no, how can we fix that?
Hi Peter,
I'm torn on this question myself. I can see both sides of the issue.
I do think there are some high-level requirements:
* These tables (PIR, mptable, acpi, smbios) need to be generated one way or another. All the major OSs in use today need them - a machine that can not run all the major OSs is at a distinct disadvantage in the market place.
* It is a bad idea to force legacybios (or any payload) to be board specific. Doing so would require vendors to commit code to multiple repos. It would fragment the development efforts and lead to confusion.
* Most of the info in the tables can not be reasonably auto-detected by the payload. Thus, one way or another, the info needs to be passed into them.
* It makes no sense to have coreboot export info in a coreboot specific format if that info is used purely by the payload to export it in a different format. For example, consider the smbios "system enclosure" table - neither coreboot nor legacybios have any need to know how many power cords are attached to the machine. Making a coreboot "num power cords" field just so legacybios can translate that to the smbios field is a waste. (There are plenty of these information fields - take a look at the acpi and smbios specs.)
Given the above, I see two possibilities.
The first involves having coreboot build the standard tables. As was discussed, this exposes coreboot to some ugliness.
The second would involve passing a few key pieces of info to the payload and then have the payload build the tables with just the bare minimum amount of data. This is what bochs/qemu do today, and it seems to work reasonably well. Most of the fields seem pointless anyway - for example, I can't imagine why an app would care how many power cords the machine had - and if it did care, I can't imagine it would trust the bios.
Unfortunately, one big issue with option two is that there is no good way to pass these ad-hoc values to the payload today. Some of the larger blobs (eg, the AML code) could be put into a lar segment. However, v2 doesn't support LAR. Many of the smaller fields (eg, num cpus, uuid, apic address) are too ad-hoc and numerous to pass via coreboot tables. (And again, why define a new coreboot table if we can reuse an already defined acpi/mptable table?)
I'm open to ideas.
-Kevin
Given the above, I see two possibilities.
The first involves having coreboot build the standard tables.
Like I said why not just have a mini program between the two that handles this operation. It could be added to coreboot or legacybios as an option module. The mini program would read the coreboot tables and what ever else it needed and then set these tables up in a format that coresponds with legacybios, and finally passes the tables to legacybios. Does it have to be more complicated than that?
Joseph Smith wrote:
Given the above, I see two possibilities.
The first involves having coreboot build the standard tables.
Like I said why not just have a mini program between the two that handles this operation. It could be added to coreboot or legacybios as an option module. The mini program would read the coreboot tables and what ever else it needed and then set these tables up in a format that coresponds with legacybios, and finally passes the tables to legacybios. Does it have to be more complicated than that?
Why not have one or the other do it, thus saving another instance with knowledge around?
On Tue, 10 Jun 2008 16:28:54 +0200, Stefan Reinauer stepan@coresystems.de wrote:
Joseph Smith wrote:
Given the above, I see two possibilities.
The first involves having coreboot build the standard tables.
Like I said why not just have a mini program between the two that
handles
this operation. It could be added to coreboot or legacybios as an option module. The mini program would read the coreboot tables and what ever
else
it needed and then set these tables up in a format that coresponds with legacybios, and finally passes the tables to legacybios. Does it have to
be
more complicated than that?
Why not have one or the other do it, thus saving another instance with knowledge around?
Yup one or the other...
Like I said why not just have a mini program between the two that handles this operation. It could be added to coreboot or legacybios as an option module. The mini program would read the coreboot tables and what ever else it needed and then set these tables up in a format that coresponds with legacybios, and finally passes the tables to legacybios. Does it have to be more complicated than that?
Yes if ACPI is involved. Please do try to get ACPI support working for your board. Or look at least on DSDT table from the "normal" BIOS. The whole thing with ACPI is not matter of simple tables. ACPI needs to know a LOT about the BOARD, CHIPSET, CPU. You cant have that in separate payload. It is not matter to re-invent all the tables. ACPI contains its own bytecode, what are you suggesting is building in a runtime compiler for the the tables, not telling about the source code for the tables ;)
This is the reason why I really want to have this in coreboot. If you dont like it do not compile it in.
Rudolf
On Tue, 10 Jun 2008 17:33:29 +0200, Rudolf Marek r.marek@assembler.cz wrote:
Like I said why not just have a mini program between the two that
handles
this operation. It could be added to coreboot or legacybios as an option module. The mini program would read the coreboot tables and what ever
else
it needed and then set these tables up in a format that coresponds with legacybios, and finally passes the tables to legacybios. Does it have to
be
more complicated than that?
Yes if ACPI is involved. Please do try to get ACPI support working for your board. Or look at least on DSDT table from the "normal" BIOS. The whole thing with ACPI is not matter of simple tables. ACPI needs to know a LOT about the BOARD, CHIPSET, CPU. You cant have that in separate payload. It is not matter to re-invent all the tables. ACPI contains its own bytecode, what are you suggesting is building in a runtime compiler for the the tables, not telling about the source code for the tables ;)
Correct me if I am wrong, currently we don't create the ACPI tables. We just use a hex version from the original bios correct? Why not just pass this along to legacybios and covert it if needed?
This is the reason why I really want to have this in coreboot. If you dont like it do not compile it in.
That's why I think we should just make it an option module.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
Correct me if I am wrong, currently we don't create the ACPI tables. We just use a hex version from the original bios correct? Why not just pass this along to legacybios and covert it if needed?
Well nope. I'm using my own tables, compiled from source code. Please note that some ACPI tables are not static, but are created for specific CPU just plugged in.
This is the reason why I really want to have this in coreboot. If you dont like it do not compile it in.
That's why I think we should just make it an option module.
Oke that would work for me.
Rudolf
Hi Joseph,
On Tue, Jun 10, 2008 at 08:46:07AM -0400, Joseph Smith wrote:
Given the above, I see two possibilities.
The first involves having coreboot build the standard tables.
Like I said why not just have a mini program between the two that handles this operation.
Where does this "mini program" get the data? It will face the same issues I outlined in my previous email.
It could be added to coreboot or legacybios as an option module. The mini program would read the coreboot tables and what ever else it needed and then set these tables up in a format that coresponds with legacybios, and finally passes the tables to legacybios.
The coreboot table today does not provide sufficient information to build the acpi/pir/mptable/smbios tables.
We could extend the coreboot table - but what's the point of defining our own intermediate format. For example, if the end consumer wants an smbios table, why translate from "coreboot->coreboot table->legacybios->smbios table" when we can just go from "coreboot->smbios table"?
Does it have to be more complicated than that?
Adding an additional program in between seems to make things more complicated.
Thanks, -Kevin
-----Original Message----- From: coreboot-bounces@coreboot.org [mailto:coreboot-bounces@coreboot.org] On Behalf Of Kevin O'Connor Sent: Tuesday, June 10, 2008 7:02 PM To: Joseph Smith Cc: coreboot@coreboot.org Subject: Re: [coreboot] coreboot BIOSisms
Hi Joseph,
On Tue, Jun 10, 2008 at 08:46:07AM -0400, Joseph Smith wrote:
Given the above, I see two possibilities.
The first involves having coreboot build the standard tables.
Like I said why not just have a mini program between the two that
handles
this operation.
Where does this "mini program" get the data? It will face the same issues I outlined in my previous email.
It could be added to coreboot or legacybios as an option module. The mini program would read the coreboot tables and what ever
else
it needed and then set these tables up in a format that coresponds with legacybios, and finally passes the tables to legacybios.
The coreboot table today does not provide sufficient information to build the acpi/pir/mptable/smbios tables.
We could extend the coreboot table - but what's the point of defining our own intermediate format. For example, if the end consumer wants an smbios table, why translate from "coreboot->coreboot table->legacybios->smbios table" when we can just go from "coreboot->smbios table"?
Does it have to be more complicated than that?
Adding an additional program in between seems to make things more complicated.
Just trying to help with the brain storming process. I am not in any way trying to make things more complicated. I just think It is going to take a lot of work, changing the coreboot core code. And very careful at that not to break the core code from using other payloads. That's why I am suggesting an option module.
Thanks, Joseph Smith Set-Top-Linux www.settoplinux.org
On Tue, Jun 10, 2008 at 07:02:26PM -0400, Kevin O'Connor wrote:
For example, if the end consumer wants an smbios table,
This is exactly my point:
End consumer is oblivious to these data structures, and rightly so. End consumer only wants $kernel to run and be featureful.
$kernel wants BIOSisms to run and be featureful.
We have to provide BIOSisms for $kernels for now.
But we have a unique opportunity to revise these data structures now!
By creating a good intermediate format, we will eventually be able to replace many if not all BIOSisms with something better documented, maybe even something simpler and certainly something nicer.
why translate from "coreboot->coreboot table->legacybios->smbios table" when we can just go from "coreboot->smbios table"?
Staying true to the design that coreboot is not a BIOS, but something better.
Adding an additional program in between seems to make things more complicated.
Short term, yes - slightly more complicated but much better structured. Long term the additional program dies.
//Peter
Hi Peter!
On Wed, Jun 11, 2008 at 04:17:49AM +0200, Peter Stuge wrote:
By creating a good intermediate format, we will eventually be able to replace many if not all BIOSisms with something better documented, maybe even something simpler and certainly something nicer.
This is why I'm "torn" on the issue. I can see the value in a good intermediate format - one that would allow coreboot to easily export a wide variety of static and dynamic data.
Unfortunately, I don't believe there is a good intermediate format available today. LAR looks nice, but it only seems useful for large blobs and it isn't supported by v2. The coreboot table is effectively the same technology as the binary ACPI/pir/mptable/smbios tables. I don't see a compelling advantage to defining new coreboot tables over using existing standard tables.
why translate from "coreboot->coreboot table->legacybios->smbios table" when we can just go from "coreboot->smbios table"?
Staying true to the design that coreboot is not a BIOS, but something better.
I'm not really sure what that means. Coreboot doing something different from a "BIOS" does not inherently mean that coreboot is better. So, if there is an intermediate format with compelling features - then I'm all for it. But, if a new intermediate format is just different or only slightly better - then I'd recommend using the existing standards.
Adding an additional program in between seems to make things more complicated.
Short term, yes - slightly more complicated but much better structured. Long term the additional program dies.
I agree 100% that if acpi/pir/mptable/smbios table generation is added to coreboot that it should be optional.
Thanks, -Kevin
On Wed, Jun 11, 2008 at 12:22:32AM -0400, Kevin O'Connor wrote:
On Wed, Jun 11, 2008 at 04:17:49AM +0200, Peter Stuge wrote:
By creating a good intermediate format, we will eventually be able to replace many if not all BIOSisms with something better documented, maybe even something simpler and certainly something nicer.
This is why I'm "torn" on the issue. I can see the value in a good intermediate format - one that would allow coreboot to easily export a wide variety of static and dynamic data.
Unfortunately, I don't believe there is a good intermediate format available today.
That's right. It doesn't exist yet.
LAR looks nice, but it only seems useful for large blobs and it isn't supported by v2.
And LAR has been heavily optimized for flash, so is probably not the best candidate.
The coreboot table is effectively the same technology as the binary ACPI/pir/mptable/smbios tables. I don't see a compelling advantage to defining new coreboot tables over using existing standard tables.
For one thing, there would be a single table instead of many.
Staying true to the design that coreboot is not a BIOS, but something better.
I'm not really sure what that means. Coreboot doing something different from a "BIOS" does not inherently mean that coreboot is better.
I think it does, just because "BIOS" is so old and implies many other things. I consider doing even almost the same thing but with a new name and more together to be a big improvement. (Basically what coreboot is all about.)
So, if there is an intermediate format with compelling features - then I'm all for it.
Would you be interested in helping with development of that format, or do you only wish to use it when it becomes available?
But, if a new intermediate format is just different or only slightly better - then I'd recommend using the existing standards.
The container format can't be very different - it will still be one data structure in RAM.
But could the contents be improved upon?
Of course, as mere producers we don't care too much, it would be interesting to discuss also with the consumers.
One consumer opinion is "why change what works" which is understandable, but is it really the only one?
//Peter
Hi Peter,
On Wed, Jun 11, 2008 at 10:03:37AM +0200, Peter Stuge wrote:
On Wed, Jun 11, 2008 at 12:22:32AM -0400, Kevin O'Connor wrote:
So, if there is an intermediate format with compelling features - then I'm all for it.
Would you be interested in helping with development of that format, or do you only wish to use it when it becomes available?
I'm not interested in writing code for an intermediate format at this time. I'm full of opinions, but I'm not sure that will move us forward.
In general, I think the simpler the intermediate format the better. For example, I think an area of memory with a simple list of ascii "key=value\n" pairs would work fine.
-Kevin
-
Joseph Smith -
Kevin O'Connor -
Marc Jones -
Peter Stuge -
Rudolf Marek -
Stefan Reinauer