Hi,
Several people have raised the possibility of replacing the coreboot BIOS emulation for option roms with SeaBIOS.
My original goal with SeaBIOS was to make it a payload that was capable of booting the system. However, I can understand the desire to leave coreboot as it is and add a little bit of bios emulation so that option roms work. It may also be useful to have some minimal support for simple calls from the payload. (For an example of a payload use - see the recent thread on Linux failing due to EBDA not being initialized.)
On that note, I spent a few minutes to see how much I could strip down seabios to make it as small as possible. If I turn off everything besides basic coreboot support, I can get the lzma compressed rom down to 5695 bytes. Note that this still includes e820 map support, timer support, acpi/mptable/pir table relocation, and many other basic bios features. It's probably a good idea to turn on pcibios support as option roms tend to want this (rom then totals 6113 bytes). Also keyboard support might be useful to some payloads (total 8131 bytes).
So, I can see a mode where coreboot would lzma uncompress a minimal seabios into 0xf0000, call into seabios, seabios would then init itself and return to coreboot. Then coreboot would finish initialization and launch the payload from flash.
I can see where the above would be useful if the payload is always coming out of flash. However, if the user ever needs to boot using seabios (or via a scsi/pxe option rom) then I think seabios needs to be the payload and needs to drive the bootup.
If there is interest in doing this, we'll need to figure out how to work out the interactions. Zhang Rui is currently working on having seabios return to coreboot. As for code integration - I'd like to avoid forking the seabios code. Perhaps it would be okay to simply copy a seabios binary into the svn repo with directions on how to build it manually. (This is what qemu and bochs do for their bios blobs.)
Thoughts? -Kevin
On Mon, Jul 21, 2008 at 11:09:21PM -0400, Kevin O'Connor wrote:
(total 8131 bytes).
Sweet.
As for code integration - I'd like to avoid forking the seabios code.
With our technology and tools, I am quite sure source can be shared even if there are two slightly different build methods.
//Peter
On 21/07/08 23:09 -0400, Kevin O'Connor wrote:
If there is interest in doing this, we'll need to figure out how to work out the interactions. Zhang Rui is currently working on having seabios return to coreboot. As for code integration - I'd like to avoid forking the seabios code. Perhaps it would be okay to simply copy a seabios binary into the svn repo with directions on how to build it manually. (This is what qemu and bochs do for their bios blobs.)
buildrom can handle the effort to build it and install it if needed. The whole concern about separate payloads goes away for v3 - since technically, the whole thing is separate payloads. But for V2, I don't think there is a problem with building the blob and inserting it into the final coreboot build.
For its part, SeaBIOS could have a --build-minimal-coreboot mode (or whatever), so it would all be easy to build and integrate with a minimum of effort. I can think of a few logistical concerns:
buildrom probably would need a seabios-coreboot target as well as seabios-as-payload target, and we would need to figure out how to configure both buildrom and coreboot to not build or use the minimal seabios if seabios is a payload.
Not insurmountable issues, but stuff to think about.
Jordan
2008/7/22, Kevin O'Connor kevin@koconnor.net:
Hi,
Several people have raised the possibility of replacing the coreboot BIOS emulation for option roms with SeaBIOS.
[...]
So, I can see a mode where coreboot would lzma uncompress a minimal seabios into 0xf0000, call into seabios, seabios would then init itself and return to coreboot. Then coreboot would finish initialization and launch the payload from flash.
I can see where the above would be useful if the payload is always coming out of flash. However, if the user ever needs to boot using seabios (or via a scsi/pxe option rom) then I think seabios needs to be the payload and needs to drive the bootup.
so if I want to write the int13 for scsi booting, should I write interrupt function in coreboot and inject it to int13, or just write codes in seabios?
If there is interest in doing this, we'll need to figure out how to work out the interactions. Zhang Rui is currently working on having seabios return to coreboot. As for code integration - I'd like to avoid forking the seabios code. Perhaps it would be okay to simply copy a seabios binary into the svn repo with directions on how to build it manually. (This is what qemu and bochs do for their bios blobs.)
Maybe this is the simplest way.
On Tue, Aug 05, 2008 at 12:44:55PM +0800, Zhang Rui wrote:
2008/7/22, Kevin O'Connor kevin@koconnor.net:
I can see where the above would be useful if the payload is always coming out of flash. However, if the user ever needs to boot using seabios (or via a scsi/pxe option rom) then I think seabios needs to be the payload and needs to drive the bootup.
so if I want to write the int13 for scsi booting, should I write interrupt function in coreboot and inject it to int13, or just write codes in seabios?
I'm not sure what you mean. The difficulty is going to be in passing the information from the coreboot option rom scan to seabios so that seabios can properly boot the machine (and fail over to an alternative boot source if necessary). I suppose one could add the legacy bios bootup rules to coreboot, but I don't like that idea much.
-Kevin
Hello,
2008/8/6, Kevin O'Connor kevin@koconnor.net:
On Tue, Aug 05, 2008 at 12:44:55PM +0800, Zhang Rui wrote:
so if I want to write the int13 for scsi booting, should I write interrupt function in coreboot and inject it to int13, or just write codes in seabios?
I'm not sure what you mean. The difficulty is going to be in passing the information from the coreboot option rom scan to seabios so that seabios can properly boot the machine (and fail over to an alternative boot source if necessary). I suppose one could add the legacy bios bootup rules to coreboot, but I don't like that idea much.
My understanding is this: 1. the option rom is some place SeaBIOS can find. So we can use SeaBIOS as a payload to boot. 2. the option rom is in zipped in coreboot.rom. So I should copy bin of SeaBIOS to coreboot and let the scsi controller option rom install int13 in coreboot. So some boot loader can load the OS from scsi storage.
Is this OK?
Best regards. Zhang Rui
On Fri, 8 Aug 2008 00:11:23 +0800, "Zhang Rui" zrfail@gmail.com wrote:
Hello,
2008/8/6, Kevin O'Connor kevin@koconnor.net:
On Tue, Aug 05, 2008 at 12:44:55PM +0800, Zhang Rui wrote:
so if I want to write the int13 for scsi booting, should I write interrupt function in coreboot and inject it to int13, or just write codes in seabios?
I'm not sure what you mean. The difficulty is going to be in passing the information from the coreboot option rom scan to seabios so that seabios can properly boot the machine (and fail over to an alternative boot source if necessary). I suppose one could add the legacy bios bootup rules to coreboot, but I don't like that idea much.
My understanding is this:
- the option rom is some place SeaBIOS can find. So we can use
SeaBIOS as a payload to boot. 2. the option rom is in zipped in coreboot.rom. So I should copy bin of SeaBIOS to coreboot and let the scsi controller option rom install int13 in coreboot. So some boot loader can load the OS from scsi storage.
Maybe I missed something.... Normally option roms are supposed to get copied to memory just below the 4G boundry (bios size - 4G) and then exicuted from there. Why not just have seabios copy it to memory and exicute it there??
On Thu, Aug 07, 2008 at 02:52:11PM -0400, Joseph Smith wrote:
Maybe I missed something.... Normally option roms are supposed to get copied to memory just below the 4G boundry (bios size - 4G) and then exicuted from there. Why not just have seabios copy it to memory and exicute it there??
Option roms are generally stored in eeproms on PCI cards. However, some option roms for devices embedded on the motherboard are stored in the system flash instead.
The option roms need to be copied to memory between 0xc0000 and 0xeffff and then executed in X86 real mode.
-Kevin
On Thu, 7 Aug 2008 19:09:02 -0400, Kevin O'Connor kevin@koconnor.net wrote:
On Thu, Aug 07, 2008 at 02:52:11PM -0400, Joseph Smith wrote:
Maybe I missed something.... Normally option roms are supposed to get copied to memory just below the
4G
boundry (bios size - 4G) and then exicuted from there. Why not just have seabios copy it to memory and exicute it there??
Option roms are generally stored in eeproms on PCI cards. However, some option roms for devices embedded on the motherboard are stored in the system flash instead.
Right sorry, I was talking about embedded devices requiring option roms, like onboard vga.
Hi Zhang,
On Fri, Aug 08, 2008 at 12:11:23AM +0800, Zhang Rui wrote:
2008/8/6, Kevin O'Connor kevin@koconnor.net:
On Tue, Aug 05, 2008 at 12:44:55PM +0800, Zhang Rui wrote:
so if I want to write the int13 for scsi booting, should I write interrupt function in coreboot and inject it to int13, or just write codes in seabios?
I'm not sure what you mean. The difficulty is going to be in passing the information from the coreboot option rom scan to seabios so that seabios can properly boot the machine (and fail over to an alternative boot source if necessary). I suppose one could add the legacy bios bootup rules to coreboot, but I don't like that idea much.
My understanding is this:
- the option rom is some place SeaBIOS can find. So we can use
SeaBIOS as a payload to boot. 2. the option rom is in zipped in coreboot.rom. So I should copy bin of SeaBIOS to coreboot and let the scsi controller option rom install int13 in coreboot. So some boot loader can load the OS from scsi storage.
Is this OK?
I'm sorry, but I don't understand what you are asking (or suggesting).
-Kevin
-
Jordan Crouse -
Joseph Smith -
Kevin O'Connor -
Peter Stuge -
Zhang Rui