Unshare these, as we can not use them when buggy PCI expansion ROMS are active and are hiding ROM.
attached.
ron
ron minnich wrote:
Unshare these, as we can not use them when buggy PCI expansion ROMS are active and are hiding ROM.
Acked-by: Marc Jones marc.jones@amd.com
On Mon, Oct 20, 2008 at 4:42 PM, Marc Jones Marc.Jones@amd.com wrote:
ron minnich wrote:
Unshare these, as we can not use them when buggy PCI expansion ROMS are active and are hiding ROM.
Acked-by: Marc Jones marc.jones@amd.com
Revision 940.
Now we have to unshare the console functions; a bit trickier as they may also call string functions. I figure we will leave LAR shared.
ron
On 21.10.2008 01:50, ron minnich wrote:
On Mon, Oct 20, 2008 at 4:42 PM, Marc Jones Marc.Jones@amd.com wrote:
ron minnich wrote:
Unshare these, as we can not use them when buggy PCI expansion ROMS are active and are hiding ROM.
Acked-by: Marc Jones marc.jones@amd.com
Revision 940.
Now we have to unshare the console functions; a bit trickier as they may also call string functions. I figure we will leave LAR shared.
What about mapping the bootblock to the ROM window below 1M as was discussed some time ago? I know it does not exactly look like fun, but AFAIK all recent and ancient chipsets mirror the top 64k there.
Regards, Carl-Daniel
P.S. I'd just say that calling console functions from during the ROM mapping is illegal. It's our code, we get to specify what is run.
Regards, Carl-Daniel
On Mon, Oct 20, 2008 at 11:28 PM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
What about mapping the bootblock to the ROM window below 1M as was discussed some time ago? I know it does not exactly look like fun, but AFAIK all recent and ancient chipsets mirror the top 64k there.
stefan and I will be working on that next week.
Thanks
ron
-----Original Message----- From: coreboot-bounces@coreboot.org [mailto:coreboot-bounces@coreboot.org] On Behalf Of Carl-Daniel Hailfinger Sent: Tuesday, October 21, 2008 12:28 AM To: ron minnich Cc: Marc Jones; Coreboot Subject: Re: [coreboot] patch: unshare pci operations
On 21.10.2008 01:50, ron minnich wrote:
On Mon, Oct 20, 2008 at 4:42 PM, Marc Jones Marc.Jones@amd.com wrote:
ron minnich wrote:
Unshare these, as we can not use them when buggy PCI expansion ROMS are active and are hiding ROM.
Acked-by: Marc Jones marc.jones@amd.com
Revision 940.
Now we have to unshare the console functions; a bit trickier as they may also call string functions. I figure we will leave LAR shared.
What about mapping the bootblock to the ROM window below 1M as was discussed some time ago? I know it does not exactly look like fun, but AFAIK all recent and ancient chipsets mirror the top 64k there.
Regards, Carl-Daniel
P.S. I'd just say that calling console functions from during the ROM mapping is illegal. It's our code, we get to specify what is run.
That's the way I'm running now. The problem would be if someone in the future wanted to debug why their option ROM was failing, and added a few printks.
Thanks, Myles
On Tue, Oct 21, 2008 at 6:32 AM, Myles Watson mylesgw@gmail.com wrote:
P.S. I'd just say that calling console functions from during the ROM mapping is illegal. It's our code, we get to specify what is run.
That's the way I'm running now. The problem would be if someone in the future wanted to debug why their option ROM was failing, and added a few printks.
I think it would be a mistake to make coreboot capabilities conditionally available. Somebody, somewhere, some day will hate us if we do that.
ron
On 21.10.2008 15:59, ron minnich wrote:
On Tue, Oct 21, 2008 at 6:32 AM, Myles Watson mylesgw@gmail.com wrote:
P.S. I'd just say that calling console functions from during the ROM mapping is illegal. It's our code, we get to specify what is run.
That's the way I'm running now. The problem would be if someone in the future wanted to debug why their option ROM was failing, and added a few printks.
I think it would be a mistake to make coreboot capabilities conditionally available. Somebody, somewhere, some day will hate us if we do that.
Yes, that's why I hope the bootblock below 1M idea works out. Otherwise I'm going to implement a command filter which takes care of the issue once and for all.
Regards, Carl-Daniel
On Tue, Oct 21, 2008 at 7:04 AM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
Yes, that's why I hope the bootblock below 1M idea works out.
it will.
Otherwise I'm going to implement a command filter which takes care of the issue once and for all.
Relax :-)
Just keep those good VIA patches coming!
ron
On 21.10.2008 16:07, ron minnich wrote:
On Tue, Oct 21, 2008 at 7:04 AM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
Yes, that's why I hope the bootblock below 1M idea works out.
it will.
Great. I totally trust you there.
Otherwise I'm going to implement a command filter which takes care of the issue once and for all.
Relax :-)
Just keep those good VIA patches coming!
Currently tidying up the v3 VIA CAR disable, I hope to send it to the list in the next few minutes.
Regards, Carl-Daniel
Carl-Daniel Hailfinger wrote:
On 21.10.2008 16:07, ron minnich wrote:
On Tue, Oct 21, 2008 at 7:04 AM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
Yes, that's why I hope the bootblock below 1M idea works out.
it will.
Great. I totally trust you there.
Don't put your valuable live to such a risk.
I don't think it makes sense to take the efforts to even try keep the sharing alive.
It was a nice idea back when I came up with it, but since then things have changed.
1) If we want to share from below 1M we can't just put the code into the bootblock and assume it pops up in the FSEG.
Because quite early we have to put some part of BIOS emulation (be it seabios or the stuff we use for option roms right now) in the FSEG at the critical addresses that our bootblock would use, too.
We can't get around using that part of the FSEG for something else.
We _could_ put the shared code at another fixed address in the image. This would basically defeat LAR.
So, in order to share, we could only share between stage 2 and later stages. That makes the whole idea quite useless.
Or we could drop either LAR or BIOS emulation. Both is not an option.
All the best,
Stefan
Here's the memory map of the low meg on one of my boxes running coreboot:
* 0x00000000 - 0x000003ff Real Mode IVT * 0x00000020 - 0x0000019c MP Table (XXX conflict?) * 0x00000400 - 0x000004ff BDA (somewhat unused) * 0x00000500 - 0x0000052f Moved GDT * 0x00000530 - 0x00000b64 coreboot table * 0x00000c00 - 0x00000c9f SMI communication * 0x0007c000 - 0x0007dfff OS boot sector (unused?) * 0x0007e000 - 0x0007ffff free to use * 0x00080000 - 0x0009fbff usable ram * 0x0009fc00 - 0x0009ffff EBDA (unused at the moment?) * 0x000a0000 - 0x000bffff VGA memory * 0x000c0000 - 0x000cffff VGA option rom * 0x000d0000 - 0x000dffff free for other option roms? * 0x000e0000 - 0x000fffff SeaBIOS? (XXX conflict?) * 0x000f0000 - 0x000f03ff PIRQ table * 0x000f0400 - 0x000f66?? ACPI tables * 0x000f66?? - 0x000f???? DMI tables
Stefan Reinauer wrote:
Here's the memory map of the low meg on one of my boxes running coreboot:
* 0x00000000 - 0x000003ff Real Mode IVT * 0x00000020 - 0x0000019c MP Table (XXX conflict?) * 0x00000400 - 0x000004ff BDA (somewhat unused) * 0x00000500 - 0x0000052f Moved GDT * 0x00000530 - 0x00000b64 coreboot table * 0x00000c00 - 0x00000c9f SMI communication * 0x0007c000 - 0x0007dfff OS boot sector (unused?) * 0x0007e000 - 0x0007ffff free to use * 0x00080000 - 0x0009fbff usable ram * 0x0009fc00 - 0x0009ffff EBDA (unused at the moment?) * 0x000a0000 - 0x000bffff VGA memory * 0x000c0000 - 0x000cffff VGA option rom * 0x000d0000 - 0x000dffff free for other option roms? * 0x000e0000 - 0x000fffff SeaBIOS? (XXX conflict?) * 0x000f0000 - 0x000f03ff PIRQ table * 0x000f0400 - 0x000f66?? ACPI tables * 0x000f66?? - 0x000f???? DMI tables
Seabios in E0000 is good. Mapping out where everything lives in F0000 is really good. The PIRQ table, DMI table, and the first part of the ACPI tables needs to be in F0000. A large part of the ACPI tables can be in the top of memory. We would need to add that region to E820 via the coreboot table. Maybe the coreboot table should be in F0000 too.
We should still have space left over to use for shared functions. Printk and lar functions might be the best candidates.
Marc
On Thu, Oct 23, 2008 at 12:11:17PM -0600, Marc Jones wrote:
Stefan Reinauer wrote:
Here's the memory map of the low meg on one of my boxes running coreboot:
* 0x00000000 - 0x000003ff Real Mode IVT * 0x00000020 - 0x0000019c MP Table (XXX conflict?) * 0x00000400 - 0x000004ff BDA (somewhat unused) * 0x00000500 - 0x0000052f Moved GDT * 0x00000530 - 0x00000b64 coreboot table * 0x00000c00 - 0x00000c9f SMI communication * 0x0007c000 - 0x0007dfff OS boot sector (unused?) * 0x0007e000 - 0x0007ffff free to use * 0x00080000 - 0x0009fbff usable ram * 0x0009fc00 - 0x0009ffff EBDA (unused at the moment?) * 0x000a0000 - 0x000bffff VGA memory * 0x000c0000 - 0x000cffff VGA option rom * 0x000d0000 - 0x000dffff free for other option roms? * 0x000e0000 - 0x000fffff SeaBIOS? (XXX conflict?) * 0x000f0000 - 0x000f03ff PIRQ table * 0x000f0400 - 0x000f66?? ACPI tables * 0x000f66?? - 0x000f???? DMI tablesSeabios in E0000 is good. Mapping out where everything lives in F0000 is really good.
SeaBIOS must live between 0xf0000 and 0x100000. SeaBIOS does not currently use 0xe0000 - 0xf0000.
The PIRQ table, DMI table, and the first part of the ACPI tables needs to be in F0000. A large part of the ACPI tables can be in the top of memory. We would need to add that region to E820 via the coreboot table. Maybe the coreboot table should be in F0000 too.
What I currently do with coreboot+seabios is have coreboot deploy PIRQ and ACPI to top of ram. I then have SeaBIOS scan for the tables and copy the handful that must exist in 0xf0000. This seems to work well.
-Kevin
On Tue, Oct 21, 2008 at 08:28:09AM +0200, Carl-Daniel Hailfinger wrote:
On 21.10.2008 01:50, ron minnich wrote:
Now we have to unshare the console functions; a bit trickier as they may also call string functions. I figure we will leave LAR shared.
What about mapping the bootblock to the ROM window below 1M as was discussed some time ago? I know it does not exactly look like fun, but AFAIK all recent and ancient chipsets mirror the top 64k there.
If I understand correctly, the window mirroring is chipset specific. Why not copy the area instead of remapping it? This way one can avoid the chipset specific logic.
Long term though, I think we're better off deploying something like SeaBIOS and using it to run the option roms. After all, the option rom support is going to need to implement bios calls at some point..
-Kevin
On Tue, Oct 21, 2008 at 8:47 AM, Kevin O'Connor kevin@koconnor.net wrote:
Long term though, I think we're better off deploying something like SeaBIOS and using it to run the option roms. After all, the option rom support is going to need to implement bios calls at some point..
it may well come to that. One issue is that not all environments need to run option roms.
One rule may be simple: take option ROM support out of coreboot and leave it in seabios. I am fine with that. It removes a point of unreliabilty from coreboot and gives it to something else. Seabios has shown it is very good at this sort of thing.
ron
-
Carl-Daniel Hailfinger -
Kevin O'Connor -
Marc Jones -
Marc Jones
-
Myles Watson -
ron minnich -
Stefan Reinauer