Kevin,
When I increase the debug level in SeaBIOS, I see the enter handle_10 messages in hardware, but not in qemu. Do you see that as well?
Thanks, Myles
Hi,
On Tue, Jul 08, 2008 at 03:26:45PM -0600, Myles Watson wrote:
When I increase the debug level in SeaBIOS, I see the enter handle_10 messages in hardware, but not in qemu. Do you see that as well?
Okay - if you're seeing handle_10 messages then this means the vga bios did not init properly. (Normally, the vga bios takes over int 0x10.)
Did you have coreboot init the vga option rom first? If so, you probably want to disable that.
-Kevin
On Tue, Jul 8, 2008 at 7:41 PM, Kevin O'Connor kevin@koconnor.net wrote:
Hi,
On Tue, Jul 08, 2008 at 03:26:45PM -0600, Myles Watson wrote:
When I increase the debug level in SeaBIOS, I see the enter handle_10 messages in hardware, but not in qemu. Do you see that as well?
Okay - if you're seeing handle_10 messages then this means the vga bios did not init properly. (Normally, the vga bios takes over int 0x10.)
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?
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.
Now I can boot the Linux CDs and here's the trace from XP. It gets to the "Setup is inspecting your computer's hardware configuration..." and hangs. I was surprised at the "sendmouse: keyboard input buffer full" message, because I didn't press any keys.
One step closer...
Thanks, Myles
sectors=296508 579MB medium detected await_ide: (TIMEOUT,BSY,!BSY,!BSY_DRQ,!BSY_!DRQ,!BSY_RDY) 3 time= 32 timeout= 32000 await_ide: (TIMEOUT,BSY,!BSY,!BSY_DRQ,!BSY_!DRQ,!BSY_RDY) 3 time= 64 timeout= 32000 Booting from 00000000:00007c00 await_ide: (TIMEOUT,BSY,!BSY,!BSY_DRQ,!BSY_!DRQ,!BSY_RDY) 3 time= 32 timeout= 32000 await_ide: (TIMEOUT,BSY,!BSY,!BSY_DRQ,!BSY_!DRQ,!BSY_RDY) 3 time= 32 timeout= 32000 await_ide: (TIMEOUT,BSY,!BSY,!BSY_DRQ,!BSY_!DRQ,!BSY_RDY) 3 time= 32 timeout= 32000 await_ide: (TIMEOUT,BSY,!BSY,!BSY_DRQ,!BSY_!DRQ,!BSY_RDY) 3 time= 64 timeout= 32000 enter handle_10: a=00002000 b=00000000 c=00000000 d=00020000 si=00000000 di=000014ea ds=000022f3 es=000022f3 ip=000016dc cs=0000c000 f=00000216 r=000014a6 await_ide: (TIMEOUT,BSY,!BSY,!BSY_DRQ,!BSY_!DRQ,!BSY_RDY) 3 time= 32 timeout= 32000 await_ide: (TIMEOUT,BSY,!BSY,!BSY_DRQ,!BSY_!DRQ,!BSY_RDY) 3 time= 64 timeout= 32000 await_ide: (TIMEOUT,BSY,!BSY,!BSY_DRQ,!BSY_!DRQ,!BSY_RDY) 3 time= 32 timeout= 32000 fail handle_1ab10e: a=4153b10e b=00000000 c=00000000 d=20491a49 si=00000000 di=00000d34 ds=0000f000 es=00001a49 ip=000077dd cs=00001000 f=00000246 r=00000cea fail get_device: a=0000153f b=0000000e c=00000002 d=00040082 si=0000146a di=00000000 ds=00001a49 es=000051da ip=00005dd4 cs=00001000 f=00000216 r=00000d0e enter handle_11: a=00000000 b=0000000c c=00000040 d=00040000 si=00001338 di=00000000 ds=00001a49 es=00000040 ip=0000412e cs=00001000 f=00000246 r=00000d06 sendmouse: keyboard input buffer full
Kevin,
Here are the failures from ReactOS 0.3.4 (free windows clone.) It hangs on language selection.
Thanks, Myles
Booting from 00000000:00007c00 fail get_device: a=cdcd41cd b=000155aa c=00000081 d=00077d82 si=0001e981 di=00000000 ds=00008c90 es=00000003 ip=0000969f cs=00000000 f=00000246 r=00006fde fail get_device: a=00100800 b=00000000 c=0def0000 d=00000082 si=00000001 di=00000000 ds=000096e3 es=00000000 ip=0000969f cs=00000000 f=00000246 r=00006fde
I'm trying to zero in on the differences between qemu and my s2892. I thought this part of the log was interesting:
Something is affecting the serial port (maybe sending backspaces?)
From qemu:
Space that gets eaten 0___________________20___________________40____________________________________80 enter handle_17: a=00000178 b=00000008 c=00000040 d=000a0000 si=00005017 di=00000000 ds=00001a49 es=00000040 ip=00003dd6 cs=00001000 f=00000206 r=00000c48 enter handle_17: a=00000200 b=00000008 c=00000040 d=000a0000 si=00005017 di=00000000 ds=00001a49 es=00000040 ip=0000a2fc cs=00001000 f=00000206 r=00000c3e enter handle_11: a=00000000 b=00000007 c=00000040 d=000a0000 si=00001338 di=00000000 ds=00001a49 es=00005030 ip=0000412e cs=00001000 f=00000202 r=00000d06 KBD: int09h_handler(): unknown scancode read: 0x00000061! DSsDSsDSsDSsfail_with_code floppy_13XX: a=00001505 b=00000001 c=0000000d d=000a5000 si=00005017 di=00000000 ds=00001a49 es=00005040 ip=000055be cs=00001000 f=00000212 r=00000c02 Returning 00000001
Space that gets eaten 0___________________20___________________40____________________________________80
From the s2892:
Space that gets eaten 0___________________20___________________40_________enter handle_11: a=00000000 b=0000000c c=00000040 d=00040000 si=00001338 di=00000000 ds=00001a49 es=00000040 ip=0000412e cs=00001000 f=00000246 r=00000d06 sendmouse: keyboard input buffer full
Thanks, Myles
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.
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.
Now I can boot the Linux CDs and here's the trace from XP. It gets to the "Setup is inspecting your computer's hardware configuration..." and hangs. I was surprised at the "sendmouse: keyboard input buffer full" message, because I didn't press any keys.
Okay - the message "sendmouse: keyboard input buffer full" is a PANIC call - so the bios itself shuts down the machine at that point.
I haven't seen this error. There are a couple of things I can think of:
* the ps2 port isn't initialized. On seabios, I've stopped calling the low level keyboard init when used with coreboot (see keyboard_init() in kbd.c). You could try enabling that.
* there is some kind of a run-away interrupt on your hardware. The keyboard is on int 1 and the mouse is on int 12. Those aren't normally used by other devices so this seems less likely.
* The mouse code may not be that flexible. You could try disabling CONFIG_PS2_MOUSE and see if that helps.
* You might want to double check that you don't have the keyboard and mouse swapped in the ps2 ports. You might want to also try booting without the mouse plugged in.
I have noticed that the mouse and keyboard code are both writing to the same ps2 io ports and that they aren't necessarily safe wrt to mouse and keyboard interrupts. This is a problem inherited from the bochs code. I plan to look at this, but it's not going to be a quick fix.
Thanks, -Kevin
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
On Thu, Jul 10, 2008 at 08:39:01AM -0600, Jordan Crouse wrote:
On 09/07/08 21:40 -0400, Kevin O'Connor wrote:
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?
Well, sure, we could do that. However, that leads to multiple software components needing to know about the quirky 8086 bios requirements. I'd think we'd be better off moving that all into one place. Coreboot could start with a stripped down bios init stage and seabios could follow up with the full init, but I suspect that various option roms would want more and more parts of the full init present..
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.
I totally agree that this is solvable.
It's worth noting that the init stage and boot stage of seabios is all 32bit gcc compiled C code. (There is as much 32bit code as there is 16bit code in seabios today.) So, whether the boot menu is in seabios, coreboot, or a chooser - I don't think it makes a tremendous difference.
-Kevin
On 11/07/08 11:17 -0400, Kevin O'Connor wrote:
On Thu, Jul 10, 2008 at 08:39:01AM -0600, Jordan Crouse wrote:
On 09/07/08 21:40 -0400, Kevin O'Connor wrote:
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?
Well, sure, we could do that. However, that leads to multiple software components needing to know about the quirky 8086 bios requirements. I'd think we'd be better off moving that all into one place. Coreboot could start with a stripped down bios init stage and seabios could follow up with the full init, but I suspect that various option roms would want more and more parts of the full init present..
Hmm - I'm starting to see Stefan's concerns. Many of our payloads don't need SeaBIOS functionality, but most need (or at least will use) option ROMs (especially our good friend VGA). If there is going to be some conflict between coreboot and SeaBIOS in this area, then really, the only option is to put SeaBIOS into coreboot. I don't really favor forcing folks to start using the payload chooser to load SeaBIOS in order to grok VGA ROMs. That seems like it is asking too much of the end developer.
Jordan
Hi,
On Fri, Jul 11, 2008 at 10:04:27AM -0600, Jordan Crouse wrote:
Hmm - I'm starting to see Stefan's concerns. Many of our payloads don't need SeaBIOS functionality, but most need (or at least will use) option ROMs (especially our good friend VGA). If there is going to be some conflict between coreboot and SeaBIOS in this area, then really, the only option is to put SeaBIOS into coreboot.
I'm unconvinced that integrating SeaBIOS and coreboot at a source code level is a good plan. SeaBIOS is also applicable to qemu and kvm - I think there is a big advantage to having seabios used as the bios for emulators - that community of users and developers is currently much larger than coreboot.
I can see a setup where coreboot initializes the machine and hands control over to SeaBIOS (as a payload) and then SeaBIOS boots the OS (including enablement of vga). It may be too simplisitc, but I see benefit to keeping coreboot focused on hardware initialization, while the payload focuses on OS booting.
I don't really favor forcing folks to start using the payload chooser to load SeaBIOS in order to grok VGA ROMs. That seems like it is asking too much of the end developer.
I agree. However, if seabios was the payload and it pulled the chooser out of flash (or the chooser was linked into seabios), then maybe we could sidestep this issue. That is, instead of going coreboot->chooser->seabios->chooser->OS we could go coreboot->seabios->chooser->OS.
-Kevin
On 11/07/08 13:10 -0400, Kevin O'Connor wrote:
Hi,
On Fri, Jul 11, 2008 at 10:04:27AM -0600, Jordan Crouse wrote:
Hmm - I'm starting to see Stefan's concerns. Many of our payloads don't need SeaBIOS functionality, but most need (or at least will use) option ROMs (especially our good friend VGA). If there is going to be some conflict between coreboot and SeaBIOS in this area, then really, the only option is to put SeaBIOS into coreboot.
I'm unconvinced that integrating SeaBIOS and coreboot at a source code level is a good plan. SeaBIOS is also applicable to qemu and kvm - I think there is a big advantage to having seabios used as the bios for emulators - that community of users and developers is currently much larger than coreboot.
So clearly we have much less in common then we previously thought.
I can see a setup where coreboot initializes the machine and hands control over to SeaBIOS (as a payload) and then SeaBIOS boots the OS (including enablement of vga). It may be too simplisitc, but I see benefit to keeping coreboot focused on hardware initialization, while the payload focuses on OS booting.
I would agree, except that where exactly optionROMs live is debatable. Is it hardware initialization? Is it OS support? A little bit of both? The problem is that the vast majority of coreboot setups in the world today do not need SeaBIOS. but all except for the Geode require optionROMs.
I don't really favor forcing folks to start using the payload chooser to load SeaBIOS in order to grok VGA ROMs. That seems like it is asking too much of the end developer.
I agree. However, if seabios was the payload and it pulled the chooser out of flash (or the chooser was linked into seabios), then maybe we could sidestep this issue. That is, instead of going coreboot->chooser->seabios->chooser->OS we could go coreboot->seabios->chooser->OS.
I'm not sure if that works well for anybody, especially you. The chooser would have zero value for your other customers, and I don't think that SeaBIOS wants to acquire the intrinsic LAR knowledge and configuration that the chooser has to deal with today. SeaBIOS is functional, the chooser is silly, non essential eyecandy. The two do not fit well together.
I am going on record as saying that I think it is a mistake to go down the path of making SeaBIOS a mandatory but separate payload for coreboot. I think there has to be a better way.
Jordan
Hi Jordan,
On Fri, Jul 11, 2008 at 11:32:06AM -0600, Jordan Crouse wrote:
I am going on record as saying that I think it is a mistake to go down the path of making SeaBIOS a mandatory but separate payload for coreboot. I think there has to be a better way.
I really don't want to see the seabios code forked.
As to the details of how seabios and coreboot interact -- I don't know the best way. I have some ideas, but I concede they may not be best.
So, if someone has some alternative ideas and wants to try coding them up - I'd be happy to assist.
Cheers, -Kevin
On 11.07.2008 19:54, Kevin O'Connor wrote:
Hi Jordan,
On Fri, Jul 11, 2008 at 11:32:06AM -0600, Jordan Crouse wrote:
I am going on record as saying that I think it is a mistake to go down the path of making SeaBIOS a mandatory but separate payload for coreboot. I think there has to be a better way.
I really don't want to see the seabios code forked.
As to the details of how seabios and coreboot interact -- I don't know the best way. I have some ideas, but I concede they may not be best.
So, if someone has some alternative ideas and wants to try coding them up - I'd be happy to assist.
Can seabios somehow complement x86emu as a way to let certain problematic VBIOS images run?
Regards, Carl-Daniel
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.
-Kevin
On Fri, Jul 11, 2008 at 01:10:28PM -0400, Kevin O'Connor wrote:
coreboot->seabios->chooser->OS
I don't like this because of how it makes a BIOS API be the de facto standard for payloads.
On Fri, Jul 11, 2008 at 02:51:12PM -0400, Kevin O'Connor wrote:
If you mean using seabios to implement the option rom scan
..
maybe it would work.
Yes, I think it would work very well.
//Peter
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. Maybe to Peter's alternate boot interface. If it replaces the emulator from Coreboot, it no longer qualifies as a "mandatory payload", but I don't think we need to fork the source. I like the idea of having a broad user base testing as much common code as possible.
On Fri, Jul 11, 2008 at 02:51:12PM -0400, Kevin O'Connor wrote:
If you mean using seabios to implement the option rom scan
..
maybe it would work.
Yes, I think it would work very well.
SeaBIOS has no way of knowing where onboard ROMs are stored. That seems like a problem that needs to be solved.
Thanks, Myles
Myles Watson wrote:
On Fri, Jul 11, 2008 at 02:51:12PM -0400, Kevin O'Connor wrote:
If you mean using seabios to implement the option rom scan
..
maybe it would work.
Yes, I think it would work very well.
SeaBIOS has no way of knowing where onboard ROMs are stored. That seems like a problem that needs to be solved.
Yes, I think the seabios should not probe for option roms actively in a coreboot scenario, but rather
1) do init 2) wait for coreboot to copy and call the option roms 3) do some exit / cleanup 4) finish coreboot ... 5) call int19 if seabios is _also_ going to be used as payload.
On Wed, Jul 16, 2008 at 08:57:15PM +0200, Stefan Reinauer wrote:
Myles Watson wrote:
SeaBIOS has no way of knowing where onboard ROMs are stored. That seems like a problem that needs to be solved.
Finding the option roms is easy - they are located between 0xc0000 and 0xe0000 and are 2KiB aligned.
Yes, I think the seabios should not probe for option roms actively in a coreboot scenario, but rather
- do init
- wait for coreboot to copy and call the option roms
- do some exit / cleanup
- finish coreboot
... 5) call int19 if seabios is _also_ going to be used as payload.
What is the benefit to coreboot doing the option rom scan?
Each option rom can inform the bios that it is capable of booting the system. Seabios knows how to build the list of bootable option roms and can then interate through them during bootup. It would be a pain to have to implement this in coreboot.
-Kevin
Kevin,
-----Original Message----- From: Kevin O'Connor [mailto:kevin@koconnor.net] Sent: Wednesday, July 16, 2008 7:20 PM To: Stefan Reinauer Cc: Myles Watson; Jordan Crouse; Carl-Daniel Hailfinger; Coreboot Subject: Re: [coreboot] SeaBIOS debug output
On Wed, Jul 16, 2008 at 08:57:15PM +0200, Stefan Reinauer wrote:
Myles Watson wrote:
SeaBIOS has no way of knowing where onboard ROMs are stored. That seems like a problem that needs to be solved.
Finding the option roms is easy - they are located between 0xc0000 and 0xe0000 and are 2KiB aligned.
That can be true after Coreboot copies them there. Devices which have option ROMs on the card are located somewhere in the PCI address space until they are copied. On-board devices have their option ROMs contained somewhere in the BIOS chip.
Thanks, Myles
Hi Myles,
On Wed, Jul 16, 2008 at 07:29:29PM -0600, Myles Watson wrote:
Finding the option roms is easy - they are located between 0xc0000 and 0xe0000 and are 2KiB aligned.
That can be true after Coreboot copies them there. Devices which have option ROMs on the card are located somewhere in the PCI address space until they are copied. On-board devices have their option ROMs contained somewhere in the BIOS chip.
Right. I'm a proponent of having coreboot be responsible for copying the option roms to their locations in ram. Once coreboot loads the option roms then seabios can easily locate and run them.
-Kevin
On Wed, Jul 16, 2008 at 6:47 PM, Kevin O'Connor kevin@koconnor.net wrote:
Hi Myles,
On Wed, Jul 16, 2008 at 07:29:29PM -0600, Myles Watson wrote:
Finding the option roms is easy - they are located between 0xc0000 and 0xe0000 and are 2KiB aligned.
That can be true after Coreboot copies them there. Devices which have option ROMs on the card are located somewhere in the PCI address space until they are copied. On-board devices have their option ROMs contained somewhere in the BIOS chip.
Right. I'm a proponent of having coreboot be responsible for copying the option roms to their locations in ram. Once coreboot loads the option roms then seabios can easily locate and run them.
you're assuming they would all fit at one time into 64k. Not necessarily the case. What has to happen is copy (or map) the rom, run it, remove it, and so on. At least that's how I remember it working. It was easier in the emulator as the copy step is not needed.
Whatever happens with this discussion, we still need to be able to run with things like linux as payload and seabios not there. At linuxworld next month, at least one booth will be showing Intel's rapidboot, which we all know as linux-as-booloader.
intel is showing that linux can be used as a bootloader. I wish they'd gotten the memo 10 years ago but better late than never.
ron
On 20.07.2008 22:57, ron minnich wrote:
On Wed, Jul 16, 2008 at 6:47 PM, Kevin O'Connor kevin@koconnor.net wrote:
Hi Myles,
On Wed, Jul 16, 2008 at 07:29:29PM -0600, Myles Watson wrote:
Finding the option roms is easy - they are located between 0xc0000 and 0xe0000 and are 2KiB aligned.
That can be true after Coreboot copies them there. Devices which have option ROMs on the card are located somewhere in the PCI address space until they are copied. On-board devices have their option ROMs contained somewhere in the BIOS chip.
Right. I'm a proponent of having coreboot be responsible for copying the option roms to their locations in ram. Once coreboot loads the option roms then seabios can easily locate and run them
you're assuming they would all fit at one time into 64k. Not necessarily the case. What has to happen is copy (or map) the rom, run it, remove it, and so on. At least that's how I remember it working. It was easier in the emulator as the copy step is not needed.
If any of the option ROMs install interrupt handlers (video etc.) they may have to remain in memory after being run.
Whatever happens with this discussion, we still need to be able to run with things like linux as payload and seabios not there. At linuxworld next month, at least one booth will be showing Intel's rapidboot, which we all know as linux-as-booloader.
intel is showing that linux can be used as a bootloader. I wish they'd gotten the memo 10 years ago but better late than never.
The most interesting thing about this is that they must have figured out a way to boot Windows from Linux. Maybe some of their code can be reused for SeaBIOS.
Regards, Carl-Daniel
On 21/07/08 01:09 +0200, Carl-Daniel Hailfinger wrote:
On 20.07.2008 22:57, ron minnich wrote: The most interesting thing about this is that they must have figured out a way to boot Windows from Linux. Maybe some of their code can be reused for SeaBIOS.
Amazingly, after the events of the last few months, booting Windows from OSS has gone from "gee-whiz" to "well-duh!".
Jordan
On Mon, Jul 21, 2008 at 7:59 AM, Jordan Crouse jordan.crouse@amd.com wrote:
Amazingly, after the events of the last few months, booting Windows from OSS has gone from "gee-whiz" to "well-duh!".
The next movie for youtube: boot linux from flash, boot windows from there, linux is the new standard windows boot system :-)
ron
Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net writes:
On 20.07.2008 22:57, ron minnich wrote:
On Wed, Jul 16, 2008 at 6:47 PM, Kevin O'Connor kevin@koconnor.net wrote:
Hi Myles,
On Wed, Jul 16, 2008 at 07:29:29PM -0600, Myles Watson wrote:
Finding the option roms is easy - they are located between 0xc0000 and 0xe0000 and are 2KiB aligned.
That can be true after Coreboot copies them there. Devices which have option ROMs on the card are located somewhere in the PCI address space until they are copied. On-board devices have their option ROMs contained somewhere in the BIOS chip.
Right. I'm a proponent of having coreboot be responsible for copying the option roms to their locations in ram. Once coreboot loads the option roms then seabios can easily locate and run them
you're assuming they would all fit at one time into 64k. Not necessarily the case. What has to happen is copy (or map) the rom, run it, remove it, and so on. At least that's how I remember it working. It was easier in the emulator as the copy step is not needed.
If any of the option ROMs install interrupt handlers (video etc.) they may have to remain in memory after being run.
The space for options ROMS is 3*64K or 192K 0xc0000 0xd0000 0xe0000 with 0xf0000 consumed by the BIOS.
Further a well behaved option ROM will trim it's size after initialization which allows you to pack in even more.
For coreboot this is a don't care. For SEABIOS it is interesting.
Eric
On Tue, Jul 22, 2008 at 05:13:37AM -0700, Eric W. Biederman wrote:
The space for options ROMS is 3*64K or 192K 0xc0000 0xd0000 0xe0000 with 0xf0000 consumed by the BIOS.
Looks like some specs disagree here. The pnpbios spec says 0xc0000 - 0xf0000 while the bios boot spec says 0xc0000 - 0xe0000.
Further a well behaved option ROM will trim it's size after initialization which allows you to pack in even more.
Well, that certainly complicates things. I can't think of a good way to support this.
-Kevin
On Wed, Jul 23, 2008 at 09:51:23PM -0400, Kevin O'Connor wrote:
Looks like some specs disagree here. The pnpbios spec says 0xc0000 - 0xf0000 while
Maybe this is memory addresses inclusive?
the bios boot spec says 0xc0000 - 0xe0000.
And this is 64k start addresses exclusive?
//Peter
On Tue, Jul 29, 2008 at 03:09:18PM +0200, Peter Stuge wrote:
On Wed, Jul 23, 2008 at 09:51:23PM -0400, Kevin O'Connor wrote:
Looks like some specs disagree here. The pnpbios spec says 0xc0000 - 0xf0000 while
Maybe this is memory addresses inclusive?
the bios boot spec says 0xc0000 - 0xe0000.
And this is 64k start addresses exclusive?
I think the specs are just different. You can find the specs I'm using by google'ing "pnpbiosspecificationv10a.pdf" and "specsbbs101.pdf".
-Kevin
On Tue, Jul 29, 2008 at 09:17:45PM -0400, Kevin O'Connor wrote:
The pnpbios spec says 0xc0000 - 0xf0000 while the bios boot spec says 0xc0000 - 0xe0000.
I think the specs are just different. You can find the specs I'm using by google'ing "pnpbiosspecificationv10a.pdf" and "specsbbs101.pdf".
--8<-- pnpbiosspecificationv10a.pdf page 12 2.3 scanning the C0000h to EFFFFh address space on 2K boundaries -->8--
--8<-- pnpbiosspecificationv10a.pdf page 15 2.5 Step 5 from C0000h to EFFFFh on every 2K boundary -->8--
--8<-- pnpbiosspecificationv10a.pdf page 21 3.4 Step 2 from C0000h to EFFFFh on every 2k boundary -->8--
--8<-- specsbbs101.pdf page 12 3.3 between system memory addresses C0000h and EFFFFh on a 2k boundary -->8--
--8<-- specsbbs101.pdf page 12 3.4 between C0000h and EFFFFh on a 2k boundary -->8--
--8<-- specsbbs101.pdf page 24 6.1.2 All option ROMs must be mapped into system memory between C0000h and EFFFFh. -->8--
--8<-- specsbbs101.pdf page 27 6.4.3 A scan for Legacy option ROMs in system memory from C0000h to EFFFFh on 2k boundaries is performed in the order of lowest to highest. -->8--
I can not find e0000 anywhere in specsbbs101.pdf.
//Peter
Hi Peter,
On Wed, Jul 30, 2008 at 12:41:12PM +0200, Peter Stuge wrote:
On Tue, Jul 29, 2008 at 09:17:45PM -0400, Kevin O'Connor wrote:
The pnpbios spec says 0xc0000 - 0xf0000 while the bios boot spec says 0xc0000 - 0xe0000.
I can not find e0000 anywhere in specsbbs101.pdf.
You're right. I must have confused that document with another - or been just confused in general.
In any case, the specs are clear - 0xe0000-0xf0000 is available for option roms.
Sorry for the confusion. -Kevin
Whatever happens with this discussion, we still need to be able to run with things like linux as payload and seabios not there. At linuxworld next month, at least one booth will be showing Intel's rapidboot, which we all know as linux-as-booloader.
intel is showing that linux can be used as a bootloader. I wish they'd gotten the memo 10 years ago but better late than never.
I think it is funny that they are even calling it a "payload". Is that a slap in coreboot's face or what???
Hi Ron,
On Sun, Jul 20, 2008 at 01:57:45PM -0700, ron minnich wrote:
On Wed, Jul 16, 2008 at 6:47 PM, Kevin O'Connor kevin@koconnor.net wrote:
Right. I'm a proponent of having coreboot be responsible for copying the option roms to their locations in ram. Once coreboot loads the option roms then seabios can easily locate and run them.
you're assuming they would all fit at one time into 64k. Not necessarily the case. What has to happen is copy (or map) the rom, run it, remove it, and so on. At least that's how I remember it working.
There is 128KiB for option roms (the 0xc0000 and 0xd0000 segments).
Stefan also mentioned the idea of swapping option roms in and out. I don't see how this would work. If an option rom wants to be part of the boot up process it needs to register itself by "hooking" various 16bit handlers and registering pointers to its own code. If the option rom is then swapped out those pointers would be left dangling.
I suppose one could swap out an option rom that wasn't part of the boot up process, but it seems odd to me that manufacturers would have option roms for cards that weren't part of the boot. After all, I'd guess it is significantly cheaper to develop a cheap windows driver that initializes the hardware than it is to write esoteric 16bit code, and shipping a cdrom must be cheaper than putting eeproms on cards.
If we're really strapped for size, I suppose we could use the 0xe0000 and maybe even part of the 0xf0000 segments for option roms. However, this isn't strictly in spec for option roms.
In any case, I don't see why we need to optimize this. Normal BIOSs seem to get by fine without needing to do anything special.
Whatever happens with this discussion, we still need to be able to run with things like linux as payload and seabios not there.
I agree. I never envisioned SeaBIOS being a mandatory part of coreboot.
-Kevin
On Mon, Jul 21, 2008 at 6:14 PM, Kevin O'Connor kevin@koconnor.net wrote:
In any case, I don't see why we need to optimize this. Normal BIOSs seem to get by fine without needing to do anything special.
Consider the case of two video cards that have to get initialized. coreboot can do this today. But it does require the emulator to provide the right rom image at virtual C0000 at the right time. This case was tested years ago and works quite well.
ron
On Mon, Jul 21, 2008 at 09:00:25PM -0700, ron minnich wrote:
On Mon, Jul 21, 2008 at 6:14 PM, Kevin O'Connor kevin@koconnor.net wrote:
In any case, I don't see why we need to optimize this. Normal BIOSs seem to get by fine without needing to do anything special.
Consider the case of two video cards that have to get initialized. coreboot can do this today. But it does require the emulator to provide the right rom image at virtual C0000 at the right time. This case was tested years ago and works quite well.
The OS can initialize the second head too. I don't think we need to initialize it in the boot phase.
-Kevin
On Wed, Jul 23, 2008 at 6:53 PM, Kevin O'Connor kevin@koconnor.net wrote:
The OS can initialize the second head too. I don't think we need to initialize it in the boot phase.
Really? Which OS?
I.e. what assumptions are you making when you say "OS"? Linux?
ron
On Thu, Jul 24, 2008 at 08:22:40AM -0700, ron minnich wrote:
On Wed, Jul 23, 2008 at 6:53 PM, Kevin O'Connor kevin@koconnor.net wrote:
The OS can initialize the second head too. I don't think we need to initialize it in the boot phase.
Really? Which OS?
I.e. what assumptions are you making when you say "OS"? Linux?
Hi Ron,
It is my understanding that a COTS bios will only initialize the first VGA card. I know multiple vga cards work on at least Windows and Linux. I therefore concluded that these OSes can initialize secondary vga cards (at least with the proper drivers installed).
If I've missed something, please let me know.
In particular, if there is evidence that a COTS bios will swap option roms then I'll treat it as a requirement for seabios (and/or coreboot). However, I'm not interested in trying to make option rom processing "better" than a COTS bios - I think the whole option rom thing is a disaster - we do it for compatibility, not as a feature.
-Kevin
Kevin O'Connor wrote:
On Mon, Jul 21, 2008 at 09:00:25PM -0700, ron minnich wrote:
On Mon, Jul 21, 2008 at 6:14 PM, Kevin O'Connor kevin@koconnor.net wrote:
In any case, I don't see why we need to optimize this. Normal BIOSs seem to get by fine without needing to do anything special.
Consider the case of two video cards that have to get initialized. coreboot can do this today. But it does require the emulator to provide the right rom image at virtual C0000 at the right time. This case was tested years ago and works quite well.
The OS can initialize the second head too. I don't think we need to initialize it in the boot phase.
If we plan to replace our current bios emulation with seabios for any option rom initialization, we should not introduce new regressions per design.
Any "Normal BIOS" will copy an option rom in place before executing it. Most remove it afterwards. So when dealing with compatibility to them, we should aim to do things similarly
Hi Stefan,
On Thu, Jul 24, 2008 at 06:09:57PM +0200, Stefan Reinauer wrote:
Any "Normal BIOS" will copy an option rom in place before executing it. Most remove it afterwards.
This is surprising to me.
A typical VGA rom is going to hook int 0x10, a typical SCSI rom is going to hook int 0x13, and a typical PXE rom is going to hook int 0x19. None of these can then be removed.
I suppose there could be some cards that just use an option rom to init the hardware and are then eligible for removal. However, that seems like it would be a very expensive way to init hardware, and so I didn't think it would be common.
So when dealing with compatibility to them, we should aim to do things similarly
I completely agree.
Eric pointed out how an option rom can "resize" itself (and thus can also resize itself to zero). This does put a wrinkle in things - having coreboot deploy the roms and seabios run them may not be possible.
-Kevin
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.
Jordan
-----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.
Thanks, Myles
Jordan
-- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc.
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
On Wed, Jul 16, 2008 at 12:43:31PM -0600, Myles Watson wrote:
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 agree.
It seems like Coreboot can load whatever should come after SeaBIOS into RAM and have SeaBIOS jump there.
Sounds good to me. All we need to do is pass a start address into seabios and then seabios can add it to the list of boot options.
One thing to be careful here is that the second payload must be above 1M (so seabios doesn't stomp on it). Also, as Carl-Daniel points out, there is nothing stopping an option rom from stomping on the second payload.
In any case, if someone is willing to code this into coreboot, I'll add the corresponding parts to seabios.
-Kevin
On Wed, Jul 16, 2008 at 09:36:16PM -0400, Kevin O'Connor wrote:
stomping on the second payload.
Could be avoided by having seabios load payloads and maybe even ROMs from the larball that is the flash chip.
//Peter
On 17.07.2008 03:53, Peter Stuge wrote:
On Wed, Jul 16, 2008 at 09:36:16PM -0400, Kevin O'Connor wrote:
stomping on the second payload.
Could be avoided by having seabios load payloads and maybe even ROMs from the larball that is the flash chip.
The stomping problem is still there in that case. If there's any stack, it can be stomped on by the code executed from the option ROM. I can see two ways out, both not really nice: - checksum all important code and data, then compare the result - reload all code, checksum only the data - reload all code, preserve no data (which would include BIOS tables)
Regards, Carl-Daniel
On 16/07/08 21:36 -0400, Kevin O'Connor wrote:
On Wed, Jul 16, 2008 at 12:43:31PM -0600, Myles Watson wrote:
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 agree.
It seems like Coreboot can load whatever should come after SeaBIOS into RAM and have SeaBIOS jump there.
Sounds good to me. All we need to do is pass a start address into seabios and then seabios can add it to the list of boot options.
One thing to be careful here is that the second payload must be above 1M (so seabios doesn't stomp on it). Also, as Carl-Daniel points out, there is nothing stopping an option rom from stomping on the second payload.
Thats going to be a huge problem. For the same reasons that seabios lives under 1Mb, so do payloads that load other payloads (such as bayou). If this is going to be a issue, then we need to work out an agreement for carving up the space < 1Mb.
Jordan
On 11.07.2008 20:51, Kevin O'Connor 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.
Well, IIRC x86emu does not only emulate x86 instructions, but also calls to 16bit BIOS. I'd like to rip the BIOS emulation code out of x86emu and use SeaBIOS for that.
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.
That would be another alternative.
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.
Actually, I'm not afraid that SeaBIOS will stomp on coreboot, but I'm very afraid the option ROMs will do so.
Regards, Carl-Daniel
Kevin,
Okay - the message "sendmouse: keyboard input buffer full" is a PANIC call - so the bios itself shuts down the machine at that point.
I changed it to a debug call, but it hangs there either way.
I haven't seen this error. There are a couple of things I can think of:
- the ps2 port isn't initialized. On seabios, I've stopped calling
the low level keyboard init when used with coreboot (see keyboard_init() in kbd.c). You could try enabling that.
That panics with a keyboard error.
- there is some kind of a run-away interrupt on your hardware. The
keyboard is on int 1 and the mouse is on int 12. Those aren't normally used by other devices so this seems less likely.
I didn't see the handler that much when I set the debugging to very verbose.
- The mouse code may not be that flexible. You could try disabling
CONFIG_PS2_MOUSE and see if that helps.
It gets farther. It loads drivers off the CD, then blue screens with
STOP: 0x0000007B (0xF78D2524, 0xC0000034, 0x00000000, 0x00000000)
I guess that narrows down where to look next.
Thanks, Myles
Hi Myles,
On Wed, Jul 16, 2008 at 01:49:09PM -0600, Myles Watson wrote:
- The mouse code may not be that flexible. You could try disabling
CONFIG_PS2_MOUSE and see if that helps.
It gets farther. It loads drivers off the CD, then blue screens with
STOP: 0x0000007B (0xF78D2524, 0xC0000034, 0x00000000, 0x00000000)
I guess that narrows down where to look next.
Hrmm. Did seabios find your harddrive? Can you send the full serial log? Was this with a Windows cdrom or a Windows installation on a hard drive?
I did get a little further with winxp last weekend. With Tom Sylla's advice, I installed winxp onto the harddrive using the factory bios and made sure to disable acpi support. I was then able to boot winxp off of the harddrive from seabios - but I didn't have any vga output. (I was able to confirm that winxp booted because I could rdesktop into it.)
It's still a mystery why winxp video halts after the "crawler" screen. I'm also not sure why I can't install from cdrom.
Oh well - it's one step further..
-Kevin
On Wed, Jul 16, 2008 at 8:34 PM, Kevin O'Connor kevin@koconnor.net wrote:
Hi Myles,
On Wed, Jul 16, 2008 at 01:49:09PM -0600, Myles Watson wrote:
- The mouse code may not be that flexible. You could try disabling
CONFIG_PS2_MOUSE and see if that helps.
It gets farther. It loads drivers off the CD, then blue screens with
STOP: 0x0000007B (0xF78D2524, 0xC0000034, 0x00000000, 0x00000000)
I guess that narrows down where to look next.
Hrmm. Did seabios find your harddrive? Can you send the full serial log? Was this with a Windows cdrom or a Windows installation on a hard drive?
I did get a little further with winxp last weekend. With Tom Sylla's advice, I installed winxp onto the harddrive using the factory bios and made sure to disable acpi support. I was then able to boot winxp off of the harddrive from seabios - but I didn't have any vga output. (I was able to confirm that winxp booted because I could rdesktop into it.)
It's still a mystery why winxp video halts after the "crawler" screen. I'm also not sure why I can't install from cdrom.
Oh well - it's one step further..
-Kevin
Here are the two logs for the Windows XP install CD. I'm wondering if we should make SeaBIOS pretend to be an older BIOS and see what happens. It seems like there was some structure that is returned on a BIOS call that tells what version it is.
I used to be able to make it through the install process with ADLO (just rombios.c, not rombios32.c), so maybe something in the PCI code is messing me up.
I don't know what else to try. Hopefully you can spot something in the logs.
I am using a blank hard drive and trying to install from CD. When I used ADLO before, if I had pre-installed XP on the hard drive, the CD wouldn't boot. It would see the windows installation and try to run that instead.
Thanks, Myles
On Thu, Jul 17, 2008 at 12:40 PM, Myles Watson mylesgw@gmail.com wrote:
Here are the two logs for the Windows XP install CD. I'm wondering if we should make SeaBIOS pretend to be an older BIOS and see what happens. It seems like there was some structure that is returned on a BIOS call that tells what version it is.
I used to be able to make it through the install process with ADLO (just rombios.c, not rombios32.c), so maybe something in the PCI code is messing me up.
I don't know what else to try. Hopefully you can spot something in the logs.
Could you try what Kevin did, and install XP on your factory BIOS (ideally with ACPI disabled) and then try and boot that image with SeaBIOS?
From going through a few x86 cpu and chipset turn-ons, I know that in
general, debugging OS boot of a full installation is usually much easier than trying to debug the installation process of an OS. There are less obstacles to booting an already-installed image, and there are much more tools available for debugging the aleady-installed OS. Once you get that working, you can go back to debugging the CD.
It would be interesting to see if your platform has the same sort of success that Kevin got on the epia. Maybe your different graphics controller will work even better.
-----Original Message----- From: Tom Sylla [mailto:tsylla@gmail.com] Sent: Thursday, July 17, 2008 6:04 PM To: Myles Watson Cc: Kevin O'Connor; Coreboot Subject: Re: [coreboot] SeaBIOS debug output
On Thu, Jul 17, 2008 at 12:40 PM, Myles Watson mylesgw@gmail.com wrote:
Here are the two logs for the Windows XP install CD. I'm wondering if we should make SeaBIOS pretend to be an older BIOS and see what happens. It seems like there was some structure that is returned on a BIOS call that tells what version it is.
I used to be able to make it through the install process with ADLO (just rombios.c, not rombios32.c), so maybe something in the PCI code is messing me up.
I don't know what else to try. Hopefully you can spot something in the
logs.
Could you try what Kevin did, and install XP on your factory BIOS (ideally with ACPI disabled) and then try and boot that image with SeaBIOS?
How do you disable ACPI? The only reference I found said to write to a file on the CD and change the option. There must be another way, right?
From going through a few x86 cpu and chipset turn-ons, I know that in general, debugging OS boot of a full installation is usually much easier than trying to debug the installation process of an OS. There are less obstacles to booting an already-installed image, and there are much more tools available for debugging the aleady-installed OS. Once you get that working, you can go back to debugging the CD.
I thought XP was picky about the BIOS, and if you upgraded the BIOS you frequently had to reinstall. That's part of the reason I wanted to try the fresh install.
It would be interesting to see if your platform has the same sort of success that Kevin got on the epia. Maybe your different graphics controller will work even better.
I'll try it. My machine came with LinuxBIOS installed, so I don't have a "factory BIOS." I'm trying to figure out how to get one out of a .wph file now.
Thanks, Myles
On Fri, Jul 18, 2008 at 12:07 PM, Myles Watson mylesgw@gmail.com wrote:
Could you try what Kevin did, and install XP on your factory BIOS (ideally with ACPI disabled) and then try and boot that image with SeaBIOS?
How do you disable ACPI? The only reference I found said to write to a file on the CD and change the option. There must be another way, right?
It is becoming more and more rare, but hopefully your non-coreboot BIOS will have a setup option to disable ACPI. Kevin's Epia had that setup option.
On Fri, Jul 18, 2008 at 10:07:59AM -0600, Myles Watson wrote:
How do you disable ACPI? The only reference I found said to write to a file on the CD and change the option. There must be another way, right?
When you see the screen that says something like "press F6 to load drivers" - you hit F7 and it will (silently) disable ACPI.
-Kevin
Hi Myles,
On Thu, Jul 17, 2008 at 10:40:48AM -0600, Myles Watson wrote:
I used to be able to make it through the install process with ADLO (just rombios.c, not rombios32.c), so maybe something in the PCI code is messing me up.
Okay - that's unexpected. You seem to be having ps2 port issues - and as far as I know that code is the same between seabios and bochs bios.
Can you list the exact versions you're working with:
* seabios version * coreboot version * adlo/bochs bios version / source repo
I'd like to try and compare the ps2 port code between what works for you and what doesn't work for you to try and spot any differences.
Note that when CONFIG_COREBOOT is on, the PCI code really isn't compiled in to seabios.
I don't know what else to try. Hopefully you can spot something in the logs.
I don't see anything obvious. Are you truncating the logs, or do you have disabled the coreboot serial logging?
-Kevin
Kevin,
On Sat, Jul 19, 2008 at 9:51 AM, Kevin O'Connor kevin@koconnor.net wrote:
Hi Myles,
On Thu, Jul 17, 2008 at 10:40:48AM -0600, Myles Watson wrote:
I used to be able to make it through the install process with ADLO (just rombios.c, not rombios32.c), so maybe something in the PCI code is messing me up.
Okay - that's unexpected. You seem to be having ps2 port issues - and as far as I know that code is the same between seabios and bochs bios.
I just tried your latest code, and I'm attaching the logs with and without PS2 support. I get an identical blue screen with both of them. There must be something else that's stopping the boot.
Can you list the exact versions you're working with:
- seabios version
latest from your git repository
- coreboot version
latest with patches to make it find my coprocessor
* adlo/bochs bios version / source repo
1.186 bochs bios and adlo with patches that I posted to the list.
http://www.mail-archive.com/linuxbios@linuxbios.org/msg12748.html http://www.mail-archive.com/linuxbios@linuxbios.org/msg12724.html
I'd like to try and compare the ps2 port code between what works for you and what doesn't work for you to try and spot any differences.
Note that when CONFIG_COREBOOT is on, the PCI code really isn't compiled in to seabios.
I don't know what else to try. Hopefully you can spot something in the
logs.
I don't see anything obvious. Are you truncating the logs, or do you have disabled the coreboot serial logging?
I was truncating the logs because I have a very verbose boot and it didn't look relevant.
I saw your post about F7, and since it is silent I couldn't tell if it worked. I still saw ACPI-related drivers being loaded.
Have you tried this on Bochs? When I was doing this before, Bochs failed in a similar way to the hardware.
Thanks, Myles
Hi Myles,
On Mon, Jul 21, 2008 at 12:44:50PM -0600, Myles Watson wrote:
I just tried your latest code, and I'm attaching the logs with and without PS2 support. I get an identical blue screen with both of them. There must be something else that's stopping the boot.
Thanks.
[...]
Find memory size Attempting to find coreboot table Copying PIR from 0dff0000 to 000ff0b0 Copying MPTABLE from 0dff0400 to 000ff0f0 ram_size=0xf8000000
Can you try disabling mptable support? Either disable it in coreboot, or comment out the call to copy_mptable() in src/coreboot.c of seabios.
The winxp installer will reliably hang under bochs if I have an mptable present.
-Kevin
-----Original Message----- From: Kevin O'Connor [mailto:kevin@koconnor.net] Sent: Thursday, July 24, 2008 8:10 PM To: Myles Watson Cc: Coreboot Subject: Re: [coreboot] SeaBIOS debug output
Hi Myles,
On Mon, Jul 21, 2008 at 12:44:50PM -0600, Myles Watson wrote:
I just tried your latest code, and I'm attaching the logs with and
without
PS2 support. I get an identical blue screen with both of them. There
must
be something else that's stopping the boot.
Thanks.
[...]
Find memory size Attempting to find coreboot table Copying PIR from 0dff0000 to 000ff0b0 Copying MPTABLE from 0dff0400 to 000ff0f0 ram_size=0xf8000000
Can you try disabling mptable support? Either disable it in coreboot, or comment out the call to copy_mptable() in src/coreboot.c of seabios.
Kevin,
I commented out the call. It still blue screens :(
Thanks, Myles
The winxp installer will reliably hang under bochs if I have an mptable present.
-Kevin
On Wed, Jul 16, 2008 at 01:49:09PM -0600, Myles Watson wrote:
- The mouse code may not be that flexible. You could try disabling
CONFIG_PS2_MOUSE and see if that helps.
It gets farther.
I've rewritten the seabios ps2 port handling. It is in the current git.
It's still a bit experimental - I'm having some issues with the keyboard leds on my epia. However, the diagnostic messages should be much better.
-Kevin
-
Carl-Daniel Hailfinger -
ebiederm＠xmission.com -
Jordan Crouse -
Joseph Smith -
Kevin O'Connor -
Myles Watson -
Peter Stuge -
ron minnich -
Stefan Reinauer -
Tom Sylla