On 16/07/08 13:59 -0600, Myles Watson wrote:
-----Original Message----- From: Jordan Crouse [mailto:jordan.crouse@amd.com] Sent: Wednesday, July 16, 2008 1:55 PM To: Myles Watson Cc: Kevin O'Connor; Carl-Daniel Hailfinger; Coreboot Subject: Re: SeaBIOS debug output
On 16/07/08 12:43 -0600, Myles Watson wrote:
On Fri, Jul 11, 2008 at 12:51 PM, Kevin O'Connor kevin@koconnor.net
wrote:
On Fri, Jul 11, 2008 at 07:58:35PM +0200, Carl-Daniel Hailfinger
wrote:
Can seabios somehow complement x86emu as a way to let certain problematic VBIOS images run?
If you mean run seabios under x86emu - I'm not sure. Seabios currently does its initialization in 32bit mode which x86emu may not like.
If you mean using seabios to implement the option rom scan - then yes, I think this is what Stefan suggested and Zhang Rui is working on. If I understand correctly, they want to load the seabios blob into ram, have seabios do its init, run the option roms, and then jump back to coreboot for the rest of the boot. Presumably, coreboot would also use seabios to boot the machine if the user wanted that.
The thing to be careful of here is making sure coreboot and seabios don't stomp on each other. This may not be such a big deal - seabios doesn't currently write to any ram above 1MiB - if coreboot didn't write to any ram below 1MiB after launching seabios then maybe it would work.
I for one don't understand what needs to be done in coreboot after the option ROM scans. It seems like it would help us discuss the possible solutions if we could enumerate that.
I don't think the Coreboot->SeaBIOS->Coreboot->Payload route means that SeaBIOS has to return to Coreboot. It seems like Coreboot can load whatever should come after SeaBIOS into RAM and have SeaBIOS jump there.
This seems like semantics to me - the jmp will be to an arbitrary address - it doesn't really matter if it goes back to coreboot or if it goes to the payload. If it jumped to the payload, SeaBIOS will have to be told _where_ to jump anyway, since the payload can live anywhere. All we really need to do is set up an interface to pass a address to SeaBIOS, and then its up to coreboot to figure out what they want to do after SeaBIOS is done.
My point was that there didn't need to be a preservation of stack state, global variables, etc. When I think of a return from a function call, it seems a lot more complex than jumping to a separate payload. I thought that was the problem.
Okay I see what you mean.
Jordan