Hi, Kevin,
I am experimenting with v3 and better integration of SeaBIOS and coreboot. For that, I am copying a SeaBIOS image to the FSEG during coreboot's VGA init code. In addition I added another 32bit entry point to SeaBIOS at 0xffc0 (Thus, living at 0xfffc0)
int copy_systembios(void) { struct mem_file archive, result; int ret; init_archive(&archive); ret = find_file(&archive, "bios.bin", &result); if (ret) { printk(BIOS_WARNING, "No legacy bios found.\n"); return -1; } process_file(&result, (void *)0xf0000); return 0; }
void run_bios(struct device *dev, unsigned long addr) { int i; void (*init_systembios)(void) = (void *)0xfffc0; copy_systembios(); init_systembios(); real_mode_switch_call_vga((dev->bus->secondary << 8) | dev->path.pci.devfn); }
Now, the entry point looks like this: diff -ur -x .git seabios2/src/romlayout.S seabios/src/romlayout.S --- seabios2/src/romlayout.S 2008-11-06 15:46:44.000000000 +0100 +++ seabios/src/romlayout.S 2008-11-01 11:38:06.000000000 +0100 @@ -544,6 +544,18 @@ ORG 0xff54 IRQ_ENTRY_ARG 05
+.code32 + ORG 0xffc0 // coreboot Entry Point + mov $0x3f8, %dx + mov $0x44, %al + outb %al, %dx // print + call _code32__init + mov $0x3f8, %dx + mov $0x45, %al + outb %al, %dx + ret +.code16gcc + ORG 0xfff0 // Power-up Entry Point ljmpw $SEG_BIOS, $post16
And _init looks like this (simplified):
void VISIBLE32 _init() { outb('@', 0x3f8); }
Unfortunately, this does not seem to work. The machine jumps somewhere else and will triple fault eventually.
The outb to serial console in the assembler entry point work fine. If I comment out the call to _code32__init, the function also returns nicely. (printing "DE" on the way. But as soon as I leave the call in, seabios crashes after printing "D" It does not even print the @.
Any hints?
Also, find attached a patch to allow cross compilation of SeaBIOS and make it work with systems where /bin/echo does not know the option -e
Stefan
On Thu, Nov 06, 2008 at 04:00:21PM +0100, Stefan Reinauer wrote:
I am experimenting with v3 and better integration of SeaBIOS and coreboot. For that, I am copying a SeaBIOS image to the FSEG during coreboot's VGA init code. In addition I added another 32bit entry point to SeaBIOS at 0xffc0 (Thus, living at 0xfffc0)
[...]
Unfortunately, this does not seem to work. The machine jumps somewhere else and will triple fault eventually.
Hrrm. Nothing looks immediately wrong. Are you running this under qemu? If so, one can attach gdb to qemu and set breakpoints in the guest. I've used this in the past with success.
http://bellard.org/qemu/qemu-doc.html#TOC46
BTW, in previous emails I highlighted some disadvantages with a tighter integration of seabios and coreboot. Could you elaborate on the reasons why you think this is the best option?
Also, find attached a patch to allow cross compilation of SeaBIOS and make it work with systems where /bin/echo does not know the option -e
Thanks.
-Kevin
Kevin O'Connor wrote:
Unfortunately, this does not seem to work. The machine jumps somewhere else and will triple fault eventually.
Hrrm. Nothing looks immediately wrong. Are you running this under qemu? If so, one can attach gdb to qemu and set breakpoints in the guest. I've used this in the past with success.
Ok, gotta try that. Thanks for the hint and pointer.
BTW, in previous emails I highlighted some disadvantages with a tighter integration of seabios and coreboot. Could you elaborate on the reasons why you think this is the best option?
Simple:
a) I don't want to maintain my own bios emulation in coreboot v3 b) I still want graphics initialized (and possibly more) c) I don't want to use int19 booting / I don't want to use seabios as a payload. * because I might be running in an emulator or not * because I am running other payloads and I want to spend as little time in seabios as possible * because I think this is the only possible way to do a soft transition of the code that is in coreboot these days and what we might see some day in the future.
That said, I must have missed the mail you are talking about.
Stefan
On Fri, Nov 07, 2008 at 01:17:46AM +0100, Stefan Reinauer wrote:
BTW, in previous emails I highlighted some disadvantages with a tighter integration of seabios and coreboot. Could you elaborate on the reasons why you think this is the best option?
Simple:
a) I don't want to maintain my own bios emulation in coreboot v3 b) I still want graphics initialized (and possibly more) c) I don't want to use int19 booting / I don't want to use seabios as a payload.
- because I might be running in an emulator or not
- because I am running other payloads and I want to spend as little
time in seabios as possible
- because I think this is the only possible way to do a soft
transition of the code that is in coreboot these days and what we might see some day in the future.
That said, I must have missed the mail you are talking about.
I was thinking of the chain of emails at:
http://www.coreboot.org/pipermail/coreboot/2008-July/036545.html
My (new) thinking is that we could:
* Continue to have seabios be a coreboot payload
* Have seabios find, copy, and run options roms on pci cards. Have it scan the lar for pci devices with option roms embedded in flash.
* Teach seabios to be able to launch a payload from flash in addition to floppy, hd, cdrom, etc..
The main gain to the above is is that we can keep all the legacy x86 real mode crud (including option roms) in one place (seabios), and we can avoid having to return from seabios to coreboot and thus not have to worry abou them "stomping" on each other.
-Kevin
Kevin O'Connor wrote:
On Fri, Nov 07, 2008 at 01:17:46AM +0100, Stefan Reinauer wrote:
BTW, in previous emails I highlighted some disadvantages with a tighter integration of seabios and coreboot. Could you elaborate on the reasons why you think this is the best option?
Simple:
a) I don't want to maintain my own bios emulation in coreboot v3 b) I still want graphics initialized (and possibly more) c) I don't want to use int19 booting / I don't want to use seabios as a payload.
- because I might be running in an emulator or not
- because I am running other payloads and I want to spend as little
time in seabios as possible
- because I think this is the only possible way to do a soft
transition of the code that is in coreboot these days and what we might see some day in the future.
That said, I must have missed the mail you are talking about.
I was thinking of the chain of emails at:
http://www.coreboot.org/pipermail/coreboot/2008-July/036545.html
My (new) thinking is that we could:
- Continue to have seabios be a coreboot payload
Sure, many want that. But some don't. I'm looking into how to make everyone happy;
- Have seabios find, copy, and run options roms on pci cards. Have it scan the lar for pci devices with option roms embedded in flash.
For example, I'd really very much prefer if coreboot stays the active instance for option rom execution for my application case.
Because otherwise I'd have to re-implement a lot of stuff in SeaBIOS that already is in coreboot. As you suggest, too.
My approach is to drop code from coreboot instead, because SeaBIOS does a good job there.
- Teach seabios to be able to launch a payload from flash in addition to floppy, hd, cdrom, etc..
That's pretty much re-inventing the wheel, or growing three legs just to cut one off. Why would one go such a complicated way instead of just returning from seabios after init?
SeaBIOS really does a lot of stuff betweeen setting up interrupts and running the OS that don't belong in a "we just want VGA on" scenario.
Also, I think, SeaBIOS does not need to know about LAR.
Let's try to make both projects simple, not both projects complicated.
The main gain to the above is is that we can keep all the legacy x86 real mode crud (including option roms) in one place (seabios).
Oh, but that works nicely with my approach, too. I reduced real-mode code in coreboot by 90% during my experiments.
and we can avoid having to return from seabios to coreboot and thus not have to worry abou them "stomping" on each other.
We do have to worry about that in all scenarios though.
Just assuming it's ok for SeaBIOS to overwrite memory that coreboot filled is not good enough.
On Fri, Nov 07, 2008 at 02:18:34AM +0100, Stefan Reinauer wrote:
Kevin O'Connor wrote:
On Fri, Nov 07, 2008 at 01:17:46AM +0100, Stefan Reinauer wrote:
BTW, in previous emails I highlighted some disadvantages with a tighter integration of seabios and coreboot. Could you elaborate on the reasons why you think this is the best option?
Simple:
[...]
Thanks Stefan. I appreciate your feedback.
One random comment:
and we can avoid having to return from seabios to coreboot and thus not have to worry abou them "stomping" on each other.
We do have to worry about that in all scenarios though.
Just assuming it's ok for SeaBIOS to overwrite memory that coreboot filled is not good enough.
I'm more worried about the option roms corrupting memory that coreboot uses.
-Kevin
On 07.11.2008 04:18, Kevin O'Connor wrote:
On Fri, Nov 07, 2008 at 02:18:34AM +0100, Stefan Reinauer wrote:
Kevin O'Connor wrote:
On Fri, Nov 07, 2008 at 01:17:46AM +0100, Stefan Reinauer wrote:
BTW, in previous emails I highlighted some disadvantages with a tighter integration of seabios and coreboot. Could you elaborate on the reasons why you think this is the best option?
Simple:
[...]
Thanks Stefan. I appreciate your feedback.
One random comment:
and we can avoid having to return from seabios to coreboot and thus not have to worry abou them "stomping" on each other.
We do have to worry about that in all scenarios though.
Just assuming it's ok for SeaBIOS to overwrite memory that coreboot filled is not good enough.
I'm more worried about the option roms corrupting memory that coreboot uses.
Checksums of coreboot memory before and after option rom execution could help.
Regards, Carl-Daniel
Kevin O'Connor wrote:
On Fri, Nov 07, 2008 at 01:17:46AM +0100, Stefan Reinauer wrote:
BTW, in previous emails I highlighted some disadvantages with a tighter integration of seabios and coreboot. Could you elaborate on the reasons why you think this is the best option?
Simple:
a) I don't want to maintain my own bios emulation in coreboot v3 b) I still want graphics initialized (and possibly more) c) I don't want to use int19 booting / I don't want to use seabios as a payload.
- because I might be running in an emulator or not
- because I am running other payloads and I want to spend as little
time in seabios as possible
- because I think this is the only possible way to do a soft
transition of the code that is in coreboot these days and what we might see some day in the future.
That said, I must have missed the mail you are talking about.
I was thinking of the chain of emails at:
http://www.coreboot.org/pipermail/coreboot/2008-July/036545.html
My (new) thinking is that we could:
Continue to have seabios be a coreboot payload
Have seabios find, copy, and run options roms on pci cards. Have it scan the lar for pci devices with option roms embedded in flash.
Teach seabios to be able to launch a payload from flash in addition to floppy, hd, cdrom, etc..
The main gain to the above is is that we can keep all the legacy x86 real mode crud (including option roms) in one place (seabios), and we can avoid having to return from seabios to coreboot and thus not have to worry abou them "stomping" on each other.
My main concern is that if seabios becomes a defacto mandatory payload for coreboot, then having two separate projects to put together will be an undue burden on the builders. My thinking has always been that at the time when something becomes essential to the operation of coreboot, it should be merged into coreboot.
Jordan
Jordan Crouse wrote:
My main concern is that if seabios becomes a defacto mandatory
I will protest very loudly against mandatory. It must be an option.
payload for coreboot, then having two separate projects to put together will be an undue burden on the builders.
We already have this situation for coreboot+payload, and I think buildrom solves that nicely.
My thinking has always been that at the time when something becomes essential to the operation of coreboot, it should be merged into coreboot.
I don't think that is neccessary when "it" is being phased out.
//Peter
Peter Stuge wrote:
Jordan Crouse wrote:
My main concern is that if seabios becomes a defacto mandatory
I will protest very loudly against mandatory. It must be an option.
Its getting harder and harder to make it an option. We are going to have to deal with optionROMs - regardless what any of us think about legacy software callbacks, we are not going to get very far unless we can handle legacy ROMs easily and cleanly and make them available to the payloads. Thats a fact of life. SeaBIOS is the best solution to this problem that we have so far. In my mind, that makes it mandatory.
payload for coreboot, then having two separate projects to put together will be an undue burden on the builders.
We already have this situation for coreboot+payload, and I think buildrom solves that nicely.
From the start, we have said that buildrom is not going to be required to build coreboot, and I stand by that. If our code is getting so complex that it *requires* a build system to put it together, then we need to step back and evaluate what we are doing.
My thinking has always been that at the time when something becomes essential to the operation of coreboot, it should be merged into coreboot.
I don't think that is neccessary when "it" is being phased out.
What is being phased out? SeaBIOS? Not from where I am standing.
Jordan
On Fri, Nov 7, 2008 at 7:38 AM, Jordan Crouse jordan@cosmicpenguin.net wrote:
Its getting harder and harder to make it an option. We are going to have to deal with optionROMs - regardless what any of us think about legacy software callbacks, we are not going to get very far unless we can handle legacy ROMs easily and cleanly and make them available to the payloads. Thats a fact of life. SeaBIOS is the best solution to this problem that we have so far. In my mind, that makes it mandatory.
Not every application of coreboot has to worry about legacy hardware or option ROMs.
To be clear, I don't object to seeing SeaBIOS in the coreboot source tree, but there must be an option to ignore it at compile time.
--Ed
Ed Swierk wrote:
On Fri, Nov 7, 2008 at 7:38 AM, Jordan Crouse jordan@cosmicpenguin.net wrote:
Its getting harder and harder to make it an option. We are going to have to deal with optionROMs - regardless what any of us think about legacy software callbacks, we are not going to get very far unless we can handle legacy ROMs easily and cleanly and make them available to the payloads. Thats a fact of life. SeaBIOS is the best solution to this problem that we have so far. In my mind, that makes it mandatory.
Not every application of coreboot has to worry about legacy hardware or option ROMs.
Don't misunderstand the use of the word mandatory here. As an example, consider that optionROMs may need to be managed on any mainboard that has PCI or PCIe slots or onboard video, NICs or RAID controllers. As developers, if we cannot rule out the possibility of using an optionROM then we would need to enable that functionality. Look through the list of mainboards, and tell me how many of them fall out of this dataset? As the United States just got finished with an election, the comparison is apt - the majority will need optionROM support, and I consider that as mandatory, at least as far as any random mainboard is concerned.
To be clear, I don't object to seeing SeaBIOS in the coreboot source tree, but there must be an option to ignore it at compile time.
Absolutely, configuration options are cheap and easy - we should use them as much as possible. But I don't think anybody disagrees with this - the larger debate is if SeaBIOS should stop being an independent entity - I think the majority of mainboards says yes.
Or, look at it from the builder point of view. I don't mind having a configuration file for each mainboard - text is cheap. But if I have to build the same package for every single mainboard, at some point I start asking questions. Thats what I'm doing here.
Jordan
It's interesting to see the variations in thinking on this based on variations in experience. Ed's company builds a system that has no need of option ROMs- they control the platform. I have no need of option ROMs either -- I don't control the platform, but HPC systems don't need them in most cases. We've fielded thousands and thousands of cluster nodes that never need an option ROM, BIOS callback, or even SMI.
Others, coming from an environment rich in option ROMs, see the need.
I agree with Ed. seabios must be optional.
I agree with Stefan. It must be possible to build seabios in easily.
I agree with Jordan. Option roms, and BIOS callbacks, are not going away (IMHO, for at last 5 years). Why? Because vendors are not yet ready to open up those details, now if ever.
So, seabios must 1. be easily available via a make Kconfig option 2. be optional. 3. return from an init call 4. assume responsibility (take over from coreboot) for option ROMs
I think this is what Stefan is saying. I agree.
Sorry, Kevin, you did a great job with seabios, and now lots of people want it :-)
ron
ron minnich wrote:
It's interesting to see the variations in thinking on this based on variations in experience. Ed's company builds a system that has no need of option ROMs- they control the platform. I have no need of option ROMs either -- I don't control the platform, but HPC systems don't need them in most cases. We've fielded thousands and thousands of cluster nodes that never need an option ROM, BIOS callback, or even SMI.
Others, coming from an environment rich in option ROMs, see the need.
I agree with Ed. seabios must be optional.
I agree with Stefan. It must be possible to build seabios in easily.
I agree with Jordan. Option roms, and BIOS callbacks, are not going away (IMHO, for at last 5 years). Why? Because vendors are not yet ready to open up those details, now if ever.
So, seabios must
- be easily available via a make Kconfig option
- be optional.
- return from an init call
- assume responsibility (take over from coreboot) for option ROMs
I think this is what Stefan is saying. I agree.
I agree with all of this.
Jordan
Jordan Crouse wrote:
From the start, we have said that buildrom is not going to be required to build coreboot, and I stand by that. If our code is getting so complex that it *requires* a build system to put it together, then we need to step back and evaluate what we are doing.
And I think we should do this. Not w.r.t. putting seabios in there by default or not, but maybe w.r.t our build system.
We still have both abuild and buildrom, and yes, both serve different goals.
I still think we need a single solution but I don't know how, yet.
On Fri, Nov 7, 2008 at 7:23 AM, Peter Stuge peter@stuge.se wrote:
Jordan Crouse wrote:
My main concern is that if seabios becomes a defacto mandatory
I will protest very loudly against mandatory. It must be an option.
+1
Modularity is one of the key technical advantages of coreboot. Let's not follow the lead of commercial BIOSes that throw in everything but the kitchen sink.
--Ed
Ed Swierk wrote:
On Fri, Nov 7, 2008 at 7:23 AM, Peter Stuge peter@stuge.se wrote:
Jordan Crouse wrote:
My main concern is that if seabios becomes a defacto mandatory
I will protest very loudly against mandatory. It must be an option.
+1
Modularity is one of the key technical advantages of coreboot. Let's not follow the lead of commercial BIOSes that throw in everything but the kitchen sink.
Modularity can very well mean a module is mandatory. In v2 there was no initram module. But it's still mandatory in v3, even though it's modular.
I think we all agree that a feature requirement (option rom execution) may mean a module requirement (seabios).
There really is not much to discuss about, except if we start flipping words around when we hear the word bios.
Peter Stuge wrote:
Jordan Crouse wrote:
My main concern is that if seabios becomes a defacto mandatory
I will protest very loudly against mandatory. It must be an option.
It will be as optional as VGA init through an option rom. Want the one, get both. Obviously when you have something that calls bios calls, you need one implementation of those bios calls. And they better not be one of our many implementations in v2 and v3, imho.
Stefan
On Fri, Nov 7, 2008 at 10:47 AM, Stefan Reinauer stepan@coresystems.dewrote:
Peter Stuge wrote:
Jordan Crouse wrote:
My main concern is that if seabios becomes a defacto mandatory
I will protest very loudly against mandatory. It must be an option.
It will be as optional as VGA init through an option rom. Want the one, get both. Obviously when you have something that calls bios calls, you need one implementation of those bios calls. And they better not be one of our many implementations in v2 and v3, imho.
I'm trying to catch up on this discussion. Are we talking about doing away with x86emu and vm86 in favor of SeaBIOS, or adding SeaBIOS to the list of options?
Thanks, Corey
On Fri, Nov 7, 2008 at 1:47 PM, Corey Osgood corey.osgood@gmail.com wrote:
I'm trying to catch up on this discussion. Are we talking about doing away with x86emu and vm86 in favor of SeaBIOS, or adding SeaBIOS to the list of options?
we're talking about removing option ROM support from coreboot, because we can never do the job in as general a way as people need, unless we become a full bios. Seabios can. So if you want option rom support, you will load seabios in to the F segment and let it run the option roms. Part of the problem is that option roms will want to call bios services, and coreboot doesn't do those services; but seabios does.
ron
ron minnich wrote:
On Fri, Nov 7, 2008 at 1:47 PM, Corey Osgood corey.osgood@gmail.com wrote:
I'm trying to catch up on this discussion. Are we talking about doing away with x86emu and vm86 in favor of SeaBIOS, or adding SeaBIOS to the list of options?
we're talking about removing option ROM support from coreboot, because we can never do the job in as general a way as people need, unless we become a full bios. Seabios can. So if you want option rom support, you will load seabios in to the F segment and let it run the option roms. Part of the problem is that option roms will want to call bios services, and coreboot doesn't do those services; but seabios does.
Also - for optionROMs like VGA, we may want to use the services from within a payload, so we need to make sure that the support infrastructure survives. Running the optionROM initialization within one of the emulators works fine and dandy, but the ISV disappears when the emulator returns.
Jordan
Jordan Crouse wrote:
The main gain to the above is is that we can keep all the legacy x86 real mode crud (including option roms) in one place (seabios), and we can avoid having to return from seabios to coreboot and thus not have to worry abou them "stomping" on each other.
My main concern is that if seabios becomes a defacto mandatory payload for coreboot, then having two separate projects to put together will be an undue burden on the builders. My thinking has always been that at the time when something becomes essential to the operation of coreboot, it should be merged into coreboot.
I absolutely agree to the point you're making.
But I'd prefer to have a local copy (regularly synced) of seabios in the coreboot tree over having a second and third implementation of the same thing in our tree that people will be using instead of seabios.
It does not help seabios, and it does not help us. We included x86emu in a similar way, or flashrom via svn:external.
Right now it's a "Seabios: all or nothing" decision. That's bad. And as long as that's the case, I believe people will go nothing rather than all except in rare cases.
On Thu, Nov 06, 2008 at 04:00:21PM +0100, Stefan Reinauer wrote:
I am experimenting with v3 and better integration of SeaBIOS and coreboot. For that, I am copying a SeaBIOS image to the FSEG during coreboot's VGA init code. In addition I added another 32bit entry point to SeaBIOS at 0xffc0 (Thus, living at 0xfffc0)
BTW, instead of adding a new 32bit entry point to SeaBIOS, why don't you teach the existing entry point to return? (When a suitable SeaBIOS config option is set.)
void run_bios(struct device *dev, unsigned long addr) { int i; void (*init_systembios)(void) = (void *)0xfffc0; copy_systembios(); init_systembios();
Change above two lines to:
init_archive(&archive); execute_in_place(archive, "bios.bin.elf");
real_mode_switch_call_vga((dev->bus->secondary << 8) |dev->path.pci.devfn); }
-Kevin
On Fri, Nov 07, 2008 at 08:55:53PM -0500, Kevin O'Connor wrote:
execute_in_place(archive, "bios.bin.elf");
I meant: run_address(load_file_segments(archive, "bios.bin.elf"));
-Kevin
Kevin O'Connor wrote:
On Thu, Nov 06, 2008 at 04:00:21PM +0100, Stefan Reinauer wrote:
I am experimenting with v3 and better integration of SeaBIOS and coreboot. For that, I am copying a SeaBIOS image to the FSEG during coreboot's VGA init code. In addition I added another 32bit entry point to SeaBIOS at 0xffc0 (Thus, living at 0xfffc0)
BTW, instead of adding a new 32bit entry point to SeaBIOS, why don't you teach the existing entry point to return? (When a suitable SeaBIOS config option is set.)
My intention was to be as little intrusive to your code as possible. Some caller might assume that jumping to 0xffff0 does what your code does now. If I can't solve the problem differently, I will go that route. Thanks for the hint.
Stefan
Stefan Reinauer wrote:
Hi, Kevin,
I am experimenting with v3 and better integration of SeaBIOS and coreboot. For that, I am copying a SeaBIOS image to the FSEG during coreboot's VGA init code. In addition I added another 32bit entry point to SeaBIOS at 0xffc0 (Thus, living at 0xfffc0)
int copy_systembios(void) { struct mem_file archive, result; int ret; init_archive(&archive); ret = find_file(&archive, "bios.bin", &result); if (ret) { printk(BIOS_WARNING, "No legacy bios found.\n"); return -1; } process_file(&result, (void *)0xf0000); return 0; }
void run_bios(struct device *dev, unsigned long addr) { int i; void (*init_systembios)(void) = (void *)0xfffc0; copy_systembios(); init_systembios(); real_mode_switch_call_vga((dev->bus->secondary << 8) | dev->path.pci.devfn); }
Now, the entry point looks like this: diff -ur -x .git seabios2/src/romlayout.S seabios/src/romlayout.S --- seabios2/src/romlayout.S 2008-11-06 15:46:44.000000000 +0100 +++ seabios/src/romlayout.S 2008-11-01 11:38:06.000000000 +0100 @@ -544,6 +544,18 @@ ORG 0xff54 IRQ_ENTRY_ARG 05
+.code32
ORG 0xffc0 // coreboot Entry Pointmov $0x3f8, %dxmov $0x44, %aloutb %al, %dx // printcall _code32__initmov $0x3f8, %dxmov $0x45, %aloutb %al, %dxret+.code16gcc
Ok, thanks for your hint with the gdb debugging in qemu. This is quite nice.
(gdb) disas 0xfffc0 0xfffd4 Dump of assembler code from 0xfffc0 to 0xfffd4: 0x000fffc0: mov $0x3f8,%dx 0x000fffc4: mov $0x44,%al 0x000fffc6: out %al,(%dx) 0x000fffc7: call 0x1e2617 0x000fffcc: mov $0x3f8,%dx 0x000fffd0: mov $0x45,%al 0x000fffd2: out %al,(%dx) 0x000fffd3: ret
The call is actually interpreted as a call to 0x1e2617 instead of a call to 0xf2617. Not sure where the 0x1e instead of the 0xf comes from.
out stepan$ i386-elf-nm rom.o |grep _init 000f2617 A _code32__init 000f2617 T _init
ndisasm translates the same assembler code from above as follows:
0000FFC0 66BAF803 mov dx,0x3f8 0000FFC4 B044 mov al,0x44 0000FFC6 EE out dx,al 0000FFC7 E84B260E00 call 0xf2617 0000FFCC 66BAF803 mov dx,0x3f8 0000FFD0 B045 mov al,0x45 0000FFD2 EE out dx,al 0000FFD3 C3 ret
so it looks like ndisasm and I made the same mistake, while qemu interprets the code sequence differently.
Any hints?
On Sat, Nov 08, 2008 at 09:50:34PM +0100, Stefan Reinauer wrote:
(gdb) disas 0xfffc0 0xfffd4 Dump of assembler code from 0xfffc0 to 0xfffd4: 0x000fffc0: mov $0x3f8,%dx 0x000fffc4: mov $0x44,%al 0x000fffc6: out %al,(%dx) 0x000fffc7: call 0x1e2617
Okay - you're running into linker madness resulting from mixing 32bit and 16bit code. The romlayout.S code thinks it is running at offset 0x0000 (which is correct for 16bit code because CS adds in 0xf0000). You've asked it to do a relative call to 0xf2617, but when you're actually running in 32bit mode the code is running at offset 0xf0000, and the relative call to 0xf2617 looks like a jump to 0xf0000+0xf2617=0x1e2617.
A simple fix is to write the call as:
calll (_code32__init - BUILD_BIOS_ADDR)
BTW, I think you're going to need to setup SeaBIOS' gdt/idt - see the code at "post32" in romlayout.S.
I keep these commands handy for diagnosing these things:
objdump -m i386 -M suffix -ld out/rom.o | less # 32bit disassemble
objdump -m i386 -M i8086 -M suffix -ld out/rom.o | less # 16bit
-Kevin
On Sat, Nov 08, 2008 at 06:01:10PM -0500, Kevin O'Connor wrote:
I keep these commands handy for diagnosing these things:
objdump -m i386 -M suffix -ld out/rom.o | less # 32bit disassemble
objdump -m i386 -M i8086 -M suffix -ld out/rom.o | less # 16bit
Additional useful commands are:
objdump -m i386 -M suffix -ld out/rom32.o | less
objdump -m i386 -M i8086 -M suffix -ld out/rom16.o | less
these variants are like the above, but they only show the 32bit and 16bit code respectively.
Also, when you run gdb with qemu, you can pull in rom.o, rom16.o, and/or rom32.o (eg, "gdb out/rom.o") and then gdb should have the symbols.
-Kevin
Kevin O'Connor wrote:
On Sat, Nov 08, 2008 at 09:50:34PM +0100, Stefan Reinauer wrote:
(gdb) disas 0xfffc0 0xfffd4 Dump of assembler code from 0xfffc0 to 0xfffd4: 0x000fffc0: mov $0x3f8,%dx 0x000fffc4: mov $0x44,%al 0x000fffc6: out %al,(%dx) 0x000fffc7: call 0x1e2617
Okay - you're running into linker madness resulting from mixing 32bit and 16bit code. The romlayout.S code thinks it is running at offset 0x0000 (which is correct for 16bit code because CS adds in 0xf0000). You've asked it to do a relative call to 0xf2617, but when you're actually running in 32bit mode the code is running at offset 0xf0000, and the relative call to 0xf2617 looks like a jump to 0xf0000+0xf2617=0x1e2617.
A simple fix is to write the call as:
calll (_code32__init - BUILD_BIOS_ADDR)BTW, I think you're going to need to setup SeaBIOS' gdt/idt - see the code at "post32" in romlayout.S.
Ok, this got me a whole lot further! For an initial test I let SeaBIOS scan and execute the VGA option ROM in Qemu. Unfortunately, it hangs while doing so:
Copied system BIOS, now jumping into it. Start bios clearing .bss section init bda init pic init timer init keyboard Missing ack (got 0000003b not 000000fa) keyboard command 000000f4 failed (ret=-1) init lpt init serial init mouse math cp init bios_table_addr: 0x000ff0a5 end=0x000ff841 Find memory size Attempting to find coreboot table Unable to find coreboot table! ram_size=0x01000000 Scan for VGA option rom Running option rom at 000c0003 fail handle_15XX:308(00000086): NULL done KBD: int09h_handler(): scancode & asciicode are zero?
On Sun, Nov 09, 2008 at 08:47:44PM +0100, Stefan Reinauer wrote:
Kevin O'Connor wrote:
[...]
BTW, I think you're going to need to setup SeaBIOS' gdt/idt - see the code at "post32" in romlayout.S.
Ok, this got me a whole lot further! For an initial test I let SeaBIOS scan and execute the VGA option ROM in Qemu. Unfortunately, it hangs while doing so:
[...]
Did you setup SeaBIOS' idt/gdt? If not, you won't be able to use call16() which would break calling option roms from SeaBIOS. (It also prevents usleep() from working which would prevent certain devices from initializing.)
Otherwise, can you post the entry code that you are using?
-Kevin
Kevin O'Connor wrote:
Did you setup SeaBIOS' idt/gdt? If not, you won't be able to use call16() which would break calling option roms from SeaBIOS. (It also prevents usleep() from working which would prevent certain devices from initializing.)
Otherwise, can you post the entry code that you are using?
I worked on unifying the GDTs used in coreboot-v3, coreboot-v3 real-mode and SeaBIOS, so I don't load a GDT in SeaBIOS, but I do load the SeaBIOS IDT. See both attached patches.
Signed-off-by: Stefan Reinauer stepan@coresystems.de
On 10.11.2008 01:07, Stefan Reinauer wrote:
Kevin O'Connor wrote:
Did you setup SeaBIOS' idt/gdt? If not, you won't be able to use call16() which would break calling option roms from SeaBIOS. (It also prevents usleep() from working which would prevent certain devices from initializing.)
Otherwise, can you post the entry code that you are using?
I worked on unifying the GDTs used in coreboot-v3, coreboot-v3 real-mode and SeaBIOS, so I don't load a GDT in SeaBIOS, but I do load the SeaBIOS IDT. See both attached patches.
Signed-off-by: Stefan Reinauer stepan@coresystems.de
Are you sure the Geode VSM still works after that patch?
Regards, Carl-Daniel
Carl-Daniel Hailfinger wrote:
On 10.11.2008 01:07, Stefan Reinauer wrote:
Kevin O'Connor wrote:
Did you setup SeaBIOS' idt/gdt? If not, you won't be able to use call16() which would break calling option roms from SeaBIOS. (It also prevents usleep() from working which would prevent certain devices from initializing.)
Otherwise, can you post the entry code that you are using?
I worked on unifying the GDTs used in coreboot-v3, coreboot-v3 real-mode and SeaBIOS, so I don't load a GDT in SeaBIOS, but I do load the SeaBIOS IDT. See both attached patches.
Signed-off-by: Stefan Reinauer stepan@coresystems.de
Are you sure the Geode VSM still works after that patch?
No. I'm pretty sure it won't.
On Mon, Nov 10, 2008 at 01:07:27AM +0100, Stefan Reinauer wrote:
Kevin O'Connor wrote:
Did you setup SeaBIOS' idt/gdt? If not, you won't be able to use call16() which would break calling option roms from SeaBIOS. (It also prevents usleep() from working which would prevent certain devices from initializing.)
Otherwise, can you post the entry code that you are using?
I worked on unifying the GDTs used in coreboot-v3, coreboot-v3 real-mode and SeaBIOS, so I don't load a GDT in SeaBIOS, but I do load the SeaBIOS IDT. See both attached patches.
Hrmm. Where is the stack actually located when using coreboot? The call16() code assumes it can use the same stack for 16bit and 32bit code. If your actual stack is not in the first 64K then that assumption wont work.
Also, on a closer look, the SeaBIOS IDT doesn't actually do anything, so no real need to mess with that one.
BTW, there are sgdtl and sidtl insns, so it is theoretically possible to save and restore the coreboot context.
-Kevin
On Sun, Nov 09, 2008 at 07:50:50PM -0500, Kevin O'Connor wrote:
On Mon, Nov 10, 2008 at 01:07:27AM +0100, Stefan Reinauer wrote:
I worked on unifying the GDTs used in coreboot-v3, coreboot-v3 real-mode and SeaBIOS, so I don't load a GDT in SeaBIOS, but I do load the SeaBIOS IDT. See both attached patches.
Hrmm. Where is the stack actually located when using coreboot?
Maybe something like this would work (totally untested):
cli cld lidtl (BUILD_BIOS_ADDR + pmode_IDT_info) lgdtl (BUILD_BIOS_ADDR + rombios32_gdt_48) ljmpl $PROTECTED_MODE_CS, $1f 1: pushl %ebp movl %esp, %ebp movl $BUILD_STACK_ADDR, %esp calll (_code32__init - BUILD_BIOS_ADDR) movl %ebp, %esp popl %ebp retl
Of course, this would return to coreboot using the SeaBIOS gdt/idt, but coreboot could probably restore it's gdt/idt fairly easily (if it cared at all).
-Kevin
-
Carl-Daniel Hailfinger -
Corey Osgood -
Ed Swierk -
Jordan Crouse -
Kevin O'Connor -
Peter Stuge -
ron minnich -
Stefan Reinauer