Modified: coreboot-v3/util/x86emu/vm86.c Log: This patch makes the vm86 call succeed. It
- moves the run_bios function down so it can call setup_realmode_idt
- adds the __attribute__((regnum(0))) to biosint because it is called from
assembly
Anybody who wants to test this in SimNOW either needs to unshare pci and printk, or remove calls into the ROM while the VGA ROM is running. Otherwise when the ROM gets sized, your code disappears.
Signed-off-by: Myles Watson mylesgw@gmail.com
Thanks, Myles
On 29/10/08 15:00 -0600, Myles Watson wrote:
Modified: coreboot-v3/util/x86emu/vm86.c Log: This patch makes the vm86 call succeed. It
- moves the run_bios function down so it can call setup_realmode_idt
- adds the __attribute__((regnum(0))) to biosint because it is called from
assembly
Anybody who wants to test this in SimNOW either needs to unshare pci and printk, or remove calls into the ROM while the VGA ROM is running. Otherwise when the ROM gets sized, your code disappears.
Signed-off-by: Myles Watson mylesgw@gmail.com
We already have Simnow ifdefs in the code - would those help to make the code work out of the box?
Jordan
Thanks,l Myles
Index: util/x86emu/vm86.c
--- util/x86emu/vm86.c (revision 964) +++ util/x86emu/vm86.c (working copy) @@ -29,6 +29,8 @@ #include <string.h> #include <io.h>
+#define CONFIG_CMD(bdf, where) (0x80000000 | (bdf) | ((where & 0xff) & ~3) | ((where & 0xf00)<<16) )
/* The address arguments to this function are PHYSICAL ADDRESSES */ static void real_mode_switch_call_vga(unsigned long devfn) { @@ -418,28 +420,15 @@ cs = cs_ip >> 16; flags = stackflags;
- printk(BIOS_DEBUG, "biosint: INT# 0x%lx\n", intnumber);
- printk(BIOS_DEBUG, "biosint: eax 0x%lx ebx 0x%lx ecx 0x%lx edx 0x%lx\n",
eax, ebx, ecx, edx);- printk(BIOS_DEBUG, "biosint: ebp 0x%lx esp 0x%lx edi 0x%lx esi 0x%lx\n",
ebp, esp, edi, esi);- printk(BIOS_DEBUG, "biosint: ip 0x%lx cs 0x%lx flags 0x%lx\n",
ip, cs, flags);- // cases in a good compiler are just as good as your own tables. switch (intnumber) { case 0 ... 15: // These are not BIOS service, but the CPU-generated exceptions
printk(BIOS_INFO, "biosint: Oops, exception %lu\n", intnumber);printk(BIOS_DEBUG, "Stack contents: "); while (esp < 0x1000) {printk(BIOS_DEBUG, "0x%04x ", *(unsigned short *) esp); esp += 2; }printk(BIOS_DEBUG, "\n");printk(BIOS_DEBUG, "biosint: Bailing out\n");@@ -458,8 +447,6 @@ &ebx, &edx, &ecx, &eax, &flags); break; default:
printk(BIOS_INFO, "BIOSINT: Unsupport int #0x%lx\n",intnumber);@@ -598,7 +585,6 @@ // devfn is an int, so we mask it off. busdevfn = (dev->bus->secondary << 8) | (dev->path.pci.devfn & 0xff);
printk(BIOS_DEBUG, "0x%x: return 0x%x\n", func, busdevfn); *pebx = busdevfn; retval = 0;@@ -618,54 +604,74 @@ unsigned short word; unsigned char byte; unsigned char reg;
struct bus *pbus;devfn = *pebx & 0xff; bus = *pebx >> 8; reg = *pedi; dev = dev_find_slot(bus, devfn); if (! dev) {
printk(BIOS_DEBUG, "0x%x: BAD DEVICE bus %d devfn 0x%x\n", func, bus, devfn); // idiots. the pcibios guys assumed you'd never pass a bad bus/devfn! *peax = PCIBIOS_BADREG; retval = -1;
pbus = dev->bus;while (pbus && pbus->dev && !ops_pci_bus(pbus)) {pbus = pbus->dev->bus;}
byte = pci_read_config8(dev, reg);
outl(CONFIG_CMD(PCI_BDEVFN(dev->bus->secondary,dev->path.pci.devfn),reg),0xCF8);byte = inb(0xCFC + (reg & 3)); *pecx = byte; break;
word = pci_read_config16(dev, reg);
outl(CONFIG_CMD(PCI_BDEVFN(dev->bus->secondary,dev->path.pci.devfn), reg),0xCF8);word = inw(0xCFC + (reg & 2)); *pecx = word; break;
dword = pci_read_config32(dev, reg);
outl(CONFIG_CMD(PCI_BDEVFN(dev->bus->secondary,dev->path.pci.devfn), reg),0xCF8);dword = inl(0xCFC); *pecx = dword; break;
pci_write_config8(dev, reg, byte);
outl(CONFIG_CMD(PCI_BDEVFN(dev->bus->secondary,dev->path.pci.devfn), reg),0xCF8);outb(byte, 0xCFC + (reg & 3)); break;
pci_write_config16(dev, reg, word);
outl(CONFIG_CMD(PCI_BDEVFN(dev->bus->secondary,dev->path.pci.devfn), reg),0xCF8);outw(word, 0xCFC + (reg & 2)); break;
pci_write_config32(dev, reg, dword);
outl(CONFIG_CMD(PCI_BDEVFN(dev->bus->secondary,dev->path.pci.devfn), reg),0xCF8);outl(dword, 0xCFC); break;}
if (retval) retval = PCIBIOS_BADREG;
printk(BIOS_DEBUG, "0x%x: bus %d devfn 0x%x reg 0x%x val 0x%lx\n",func, bus, devfn, reg, *pecx);printk(BIOS_ERR, "UNSUPPORTED PCIBIOS FUNCTION 0x%x\n", func);
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
On Wed, Oct 29, 2008 at 3:11 PM, Jordan Crouse jordan.crouse@amd.comwrote:
On 29/10/08 15:00 -0600, Myles Watson wrote:
Modified: coreboot-v3/util/x86emu/vm86.c Log: This patch makes the vm86 call succeed. It
- moves the run_bios function down so it can call setup_realmode_idt
- adds the __attribute__((regnum(0))) to biosint because it is called
from
assembly
Anybody who wants to test this in SimNOW either needs to unshare pci and printk, or remove calls into the ROM while the VGA ROM is running. Otherwise when the ROM gets sized, your code disappears.
Signed-off-by: Myles Watson mylesgw@gmail.com
We already have Simnow ifdefs in the code - would those help to make the code work out of the box?
I think we decided that the "right" thing to do was to unshare the code, mirror the ROM, or something else that makes the solution more general. Since you can't trust ROMs in general, it's not specific to SimNOW. I just wanted others to be able to test it.
Thanks, Myles
Myles Watson wrote:
On Wed, Oct 29, 2008 at 3:11 PM, Jordan Crouse <jordan.crouse@amd.com mailto:jordan.crouse@amd.com> wrote:
On 29/10/08 15:00 -0600, Myles Watson wrote: > > Modified: > > coreboot-v3/util/x86emu/vm86.c > > Log: > > This patch makes the vm86 call succeed. It > > 1. moves the run_bios function down so it can call setup_realmode_idt > > 2. adds the __attribute__((regnum(0))) to biosint because it is called from > > assembly > > > > > Anybody who wants to test this in SimNOW either needs to unshare pci and > printk, or remove calls into the ROM while the VGA ROM is running. > Otherwise when the ROM gets sized, your code disappears. > > Signed-off-by: Myles Watson <mylesgw@gmail.com <mailto:mylesgw@gmail.com>> We already have Simnow ifdefs in the code - would those help to make the code work out of the box?I think we decided that the "right" thing to do was to unshare the code, mirror the ROM, or something else that makes the solution more general. Since you can't trust ROMs in general, it's not specific to SimNOW. I just wanted others to be able to test it.
Yes, we just need to fix it. This will break real hardware too. Marc
Just unshare. I am happy with patches that eliminate shared code entirely.
Thanks
ron
On 29.10.2008 23:36, ron minnich wrote:
Just unshare. I am happy with patches that eliminate shared code entirely.
Unsharing just postpones the problem for another 6 months or so. After that, the new code will fail as well. Besides that, wasting the whole boot block is not exactly my idea of efficiency.
Anyone thinking of this should be aware that unsharing will be LOTS of fun, especially considering global variables, avoiding garbage on serial and so on. We will need to compile code with different #ifdef sections based on where it lives and previously shared parts of the code will look more and more like old ROMCC code.
Regards, Carl-Daniel
Carl-Daniel Hailfinger wrote:
On 29.10.2008 23:36, ron minnich wrote:
Just unshare. I am happy with patches that eliminate shared code entirely.
Unsharing just postpones the problem for another 6 months or so. After that, the new code will fail as well. Besides that, wasting the whole boot block is not exactly my idea of efficiency.
No, unsharing nicely solves the problem.
Anyone thinking of this should be aware that unsharing will be LOTS of fun, especially considering global variables, avoiding garbage on serial and so on.
We don't share in v2, and we have no garbage there.
We will need to compile code with different #ifdef sections based on where it lives and previously shared parts of the code will look more and more like old ROMCC code.
There be dragons.
On 30.10.2008 01:14, Stefan Reinauer wrote:
Carl-Daniel Hailfinger wrote:
On 29.10.2008 23:36, ron minnich wrote:
Just unshare. I am happy with patches that eliminate shared code entirely.
Unsharing just postpones the problem for another 6 months or so. After that, the new code will fail as well. Besides that, wasting the whole boot block is not exactly my idea of efficiency.
No, unsharing nicely solves the problem.
We already have graphics cards with 2 GB RAM, so anything above 2 GB is unreachable during sizing. For a graphics card with 4 GB RAM, every single freaking 32bit location will be inaccessible. That means it it totally irrelevant whether you unshare or not, the machine will simply fail.
Anyone thinking of this should be aware that unsharing will be LOTS of fun, especially considering global variables, avoiding garbage on serial and so on.
We don't share in v2, and we have no garbage there.
Well, do we use printk in v2 before setting up serial? AFAICS we don't, so the problem doesn't apply to v2. Of course that problem can be fixed in v3 by removing lots of early printk calls, but I prefer to avoid that.
We will need to compile code with different #ifdef sections based on where it lives and previously shared parts of the code will look more and more like old ROMCC code.
There be dragons.
Indeed.
Regards, Carl-Daniel
So, just come up with a better solution for the problem that does not involve using FSEG because that's gone already.
Carl-Daniel Hailfinger wrote:
On 30.10.2008 01:14, Stefan Reinauer wrote:
Carl-Daniel Hailfinger wrote:
On 29.10.2008 23:36, ron minnich wrote:
Just unshare. I am happy with patches that eliminate shared code entirely.
Unsharing just postpones the problem for another 6 months or so. After that, the new code will fail as well. Besides that, wasting the whole boot block is not exactly my idea of efficiency.
No, unsharing nicely solves the problem.
We already have graphics cards with 2 GB RAM, so anything above 2 GB is unreachable during sizing. For a graphics card with 4 GB RAM, every single freaking 32bit location will be inaccessible. That means it it totally irrelevant whether you unshare or not, the machine will simply fail.
Anyone thinking of this should be aware that unsharing will be LOTS of fun, especially considering global variables, avoiding garbage on serial and so on.
We don't share in v2, and we have no garbage there.
Well, do we use printk in v2 before setting up serial? AFAICS we don't, so the problem doesn't apply to v2. Of course that problem can be fixed in v3 by removing lots of early printk calls, but I prefer to avoid that.
The problem is pci config space access as much as printk. So not doing printk is not solving the problem
We will need to compile code with different #ifdef sections based on where it lives and previously shared parts of the code will look more and more like old ROMCC code.
There be dragons.
Indeed.
Regards, Carl-Daniel
On 30.10.2008 01:26, Stefan Reinauer wrote:
So, just come up with a better solution for the problem that does not involve using FSEG because that's gone already.
What about: - Keep the shared part of the ROM cached (or even locked in cache) or anything that will allow the processor to continue fetching/executing code while sizing the BARs. - Trap on each option ROM write to a BAR, check if it is sizing related, then give back the expected info and leave the BAR untouched. vm86 can be trapped easily. For x86emu, we don't even have to trap. That leaves our own BAR sizing as a possible problem. As long as we get that one right, we win.
I believe Ron earlier suggested key ingredients of the recipe above, so I don't want to take credit for it.
Regards, Carl-Daniel
Carl-Daniel Hailfinger wrote:
On 30.10.2008 01:26, Stefan Reinauer wrote:
So, just come up with a better solution for the problem that does not involve using FSEG because that's gone already.
What about:
- Keep the shared part of the ROM cached (or even locked in cache) or
anything that will allow the processor to continue fetching/executing code while sizing the BARs.
- Trap on each option ROM write to a BAR, check if it is sizing related,
then give back the expected info and leave the BAR untouched. vm86 can be trapped easily. For x86emu, we don't even have to trap. That leaves our own BAR sizing as a possible problem. As long as we get that one right, we win.
I believe Ron earlier suggested key ingredients of the recipe above, so I don't want to take credit for it.
I was just thinking: Since we want to leave option rom init to seabios living in FSEF after all: We're not calling anything from below 4G anymore as we're in a different scope. So we wouldn't have to give up on sharing, and would still get the issue out of the way while removing lots and lots of code in coreboot.
Stefan
-----Original Message----- From: Stefan Reinauer [mailto:stepan@coresystems.de] Sent: Wednesday, October 29, 2008 8:06 PM To: Carl-Daniel Hailfinger Cc: ron minnich; Jordan Crouse; Marc Jones; Myles Watson; coreboot@coreboot.org Subject: Re: [coreboot] r964 - coreboot-v3/util/x86emu
Carl-Daniel Hailfinger wrote:
On 30.10.2008 01:26, Stefan Reinauer wrote:
So, just come up with a better solution for the problem that does not involve using FSEG because that's gone already.
What about:
- Keep the shared part of the ROM cached (or even locked in cache) or
anything that will allow the processor to continue fetching/executing code while sizing the BARs.
- Trap on each option ROM write to a BAR, check if it is sizing related,
then give back the expected info and leave the BAR untouched. vm86 can be trapped easily. For x86emu, we don't even have to trap. That leaves our own BAR sizing as a possible problem. As long as we get that one right, we win.
I believe Ron earlier suggested key ingredients of the recipe above, so I don't want to take credit for it.
I was just thinking: Since we want to leave option rom init to seabios living in FSEF after all: We're not calling anything from below 4G anymore as we're in a different scope. So we wouldn't have to give up on sharing, and would still get the issue out of the way while removing lots and lots of code in coreboot.
In that case we could commit the patch I submitted and worry about it later.
Thanks, Myles
On 30.10.2008 03:06, Stefan Reinauer wrote:
Carl-Daniel Hailfinger wrote:
On 30.10.2008 01:26, Stefan Reinauer wrote:
So, just come up with a better solution for the problem that does not involve using FSEG because that's gone already.
What about:
- Keep the shared part of the ROM cached (or even locked in cache) or
anything that will allow the processor to continue fetching/executing code while sizing the BARs.
- Trap on each option ROM write to a BAR, check if it is sizing related,
then give back the expected info and leave the BAR untouched. vm86 can be trapped easily. For x86emu, we don't even have to trap. That leaves our own BAR sizing as a possible problem. As long as we get that one right, we win.
I believe Ron earlier suggested key ingredients of the recipe above, so I don't want to take credit for it.
I was just thinking: Since we want to leave option rom init to seabios living in FSEF after all: We're not calling anything from below 4G anymore as we're in a different scope. So we wouldn't have to give up on sharing, and would still get the issue out of the way while removing lots and lots of code in coreboot.
Sounds nice to me.
Regards, Carl-Daniel
Carl-Daniel Hailfinger wrote:
We already have graphics cards with 2 GB RAM, so anything above 2 GB is unreachable during sizing. For a graphics card with 4 GB RAM, every single freaking 32bit location will be inaccessible. That means it it totally irrelevant whether you unshare or not, the machine will simply fail.
The framebuffer size or location doesn't matter. The vbios is running in real mode so it can't access that memory either. The issue is that the framebuffer sizing by the vbios causes the subtractive decode path to be rerouted and the code can no longer be fetched.
Marc
-----Original Message-----
No, unsharing nicely solves the problem.
We already have graphics cards with 2 GB RAM, so anything above 2 GB is unreachable during sizing. For a graphics card with 4 GB RAM, every single freaking 32bit location will be inaccessible. That means it it totally irrelevant whether you unshare or not, the machine will simply fail.
This is a good reminder that 64-bit BARs need to work. Sizing with 64-bit BARs doesn't take away the lower 4GB.
Myles
On Wed, Oct 29, 2008 at 5:14 PM, Stefan Reinauer stepan@coresystems.de wrote:
Carl-Daniel Hailfinger wrote:
Unsharing just postpones the problem for another 6 months or so. After that, the new code will fail as well. Besides that, wasting the whole boot block is not exactly my idea of efficiency.
No, unsharing nicely solves the problem.
from what I can see, unsharing has solved the problem in one case. So, QED, it can help.
Do we unshare everything? No, since we want to share data between stages I believe.
It has been pointed out to me by hardware folks familiiar with future systems that sharing *code* will likely bite us, as there will likely always be a penalty for calling to ROM, even when the ROM is cached.
I have no complaint with sharing *data* between stages. Sharing code is proving to be a problem and, again, vendors are somewhat surprised that we are doing the code sharing. I can take a hint :-)
Also, please remember: unsharing now does not rule out re-sharing later. That is the beauty of the current sharing framework: it is really incredibly flexible, and lets us share and unshare at will.
thanks
ron
let's all calm down and get a good night's sleep, followed by a relaxing breakfast and coffee :-)
This is going to get solved in the next week, and I think we'll all be happy with how it's done. Hang in there.
Thanks
ron
-
Carl-Daniel Hailfinger -
Jordan Crouse -
Marc Jones -
Marc Jones
-
Myles Watson -
ron minnich -
Stefan Reinauer