On 09/07/08 21:40 -0400, Kevin O'Connor wrote:
Hi,
On Wed, Jul 09, 2008 at 11:43:57AM -0600, Myles Watson wrote:
On Tue, Jul 8, 2008 at 7:41 PM, Kevin O'Connor kevin@koconnor.net wrote:
Did you have coreboot init the vga option rom first? If so, you probably want to disable that.
That lets me get farther, which begs the question why it's not reentrant. Does your code register your handlers over the existing ones? Should it?
SeaBIOS has to initialize the 8086 real mode irq vectors on startup. It does overwrite the 0x10 handler that the vga bios may have installed. I don't see anyway around this - the contents of the irq table could be junk and not initializing it would lead to mysterious crashes.
What if coreboot ensured that it wasn't junk before you saw it?
Also, I don't think we can rely on an emulator to setup the memory associated with option roms. It's fine for initializing the hardware, but its another thing to rely on an emulator to initialize the software interfaces.
So, we need to have SeaBIOS do the option rom scan.
I'm concerned that in a payload chooser you'll want to have graphical output to allow the user to choose SeaBIOS. If you can't run the VGA BIOS first ... that seems like a problem.
This was something that Stefan brought up. He suggested having SeaBIOS return to coreboot and then let coreboot select the payload. However, I'm not convinced that this is the best way to go. Making sure that SeaBIOS and coreboot don't stomp on each other could be difficult.
Another possibility is to teach SeaBIOS how to launch payloads from flash.
We could also make SeaBIOS a special "must absolutely, positively run first" payload in the chooser so that it executes before we try to access the display. I am convinced we can find a reasonable solution to the problem.
Jordan