I did not realize we had gone private. see below.
Basically, vga bios tries to size a 16 meg register and at an intermediate point the vga hardware ends up decoding the top 16 mb of memory.
I welcome a fix. It's just not obvious to me.
ron
---------- Forwarded message ---------- From: ron minnich rminnich@gmail.com Date: Thu, Oct 16, 2008 at 12:15 PM Subject: Re: [coreboot] SimNOW VGA int 1a To: Marc Jones marc.jones@amd.com Cc: Myles Watson mylesgw@gmail.com, Jordan Crouse jordan.crouse@amd.com
On Thu, Oct 16, 2008 at 12:08 PM, Marc Jones marc.jones@amd.com wrote:
ron minnich wrote:
well, hang on.
I write ffffffff to BAR 10. Then what is left in BAR 10 is ff000000. That decodes to the top 16 MB of address space. At that point, all the memory goes bye bye. So do we really want the device enabled?
Is this maybe a bug in the vga bios? This won't be an issue for code not running in the top 16 MB
Yes it goes away but nothing should access it then. Put the BAR back and it should be fine.
but the EIP is accessing it then. We're running code at ffffxxxx.
Here is the sequence:
we're running at ffffxxxx. We write ffffffff at request of vgabios to the BAR 10. At that point vga is decoding ffxxxxxx.
We can no longer fetch code from ffffxxxx. We go bye bye.
Fix is to NOT compile the pcibios into stage0, or to also decode it into stage2.
ron
On Thu, Oct 16, 2008 at 1:56 PM, ron minnich rminnich@gmail.com wrote:
I did not realize we had gone private. see below.
Basically, vga bios tries to size a 16 meg register and at an intermediate point the vga hardware ends up decoding the top 16 mb of memory.
I welcome a fix. It's just not obvious to me.
But we could just say that VGA ROM init is a black hole, only call functions defined there and hope it works. :)
Myles
ron
---------- Forwarded message ---------- From: ron minnich rminnich@gmail.com Date: Thu, Oct 16, 2008 at 12:15 PM Subject: Re: [coreboot] SimNOW VGA int 1a To: Marc Jones marc.jones@amd.com Cc: Myles Watson mylesgw@gmail.com, Jordan Crouse <jordan.crouse@amd.com
On Thu, Oct 16, 2008 at 12:08 PM, Marc Jones marc.jones@amd.com wrote:
ron minnich wrote:
well, hang on.
I write ffffffff to BAR 10. Then what is left in BAR 10 is ff000000. That decodes to the top 16 MB of address space. At that point, all the memory goes bye bye. So do we really want the device enabled?
Is this maybe a bug in the vga bios? This won't be an issue for code not running in the top 16 MB
Yes it goes away but nothing should access it then. Put the BAR back and
it
should be fine.
but the EIP is accessing it then. We're running code at ffffxxxx.
Here is the sequence:
we're running at ffffxxxx. We write ffffffff at request of vgabios to the BAR 10. At that point vga is decoding ffxxxxxx.
We can no longer fetch code from ffffxxxx. We go bye bye.
Fix is to NOT compile the pcibios into stage0, or to also decode it into stage2.
ron
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Myles Watson wrote:
On Thu, Oct 16, 2008 at 1:56 PM, ron minnich <rminnich@gmail.com mailto:rminnich@gmail.com> wrote:
I did not realize we had gone private. see below. Basically, vga bios tries to size a 16 meg register and at an intermediate point the vga hardware ends up decoding the top 16 mb of memory. I welcome a fix. It's just not obvious to me.But we could just say that VGA ROM init is a black hole, only call functions defined there and hope it works. :)
Myles
True but this ether means we duplicate code in the emulator or don't get any information out.
Marc
On 16.10.2008 21:56, ron minnich wrote:
I did not realize we had gone private. see below.
Basically, vga bios tries to size a 16 meg register and at an intermediate point the vga hardware ends up decoding the top 16 mb of memory.
I welcome a fix. It's just not obvious to me.
Please help me understand this better. Is this a bug of real hardware, a bug of an emulator or an intended design feature?
Depending on what it is, we could employ various ways to fix it.
Regards, Carl-Daniel
---------- Forwarded message ---------- From: ron minnich rminnich@gmail.com Date: Thu, Oct 16, 2008 at 12:15 PM Subject: Re: [coreboot] SimNOW VGA int 1a To: Marc Jones marc.jones@amd.com Cc: Myles Watson mylesgw@gmail.com, Jordan Crouse jordan.crouse@amd.com
On Thu, Oct 16, 2008 at 12:08 PM, Marc Jones marc.jones@amd.com wrote:
ron minnich wrote:
well, hang on.
I write ffffffff to BAR 10. Then what is left in BAR 10 is ff000000. That decodes to the top 16 MB of address space. At that point, all the memory goes bye bye. So do we really want the device enabled?
Is this maybe a bug in the vga bios? This won't be an issue for code not running in the top 16 MB
Yes it goes away but nothing should access it then. Put the BAR back and it should be fine.
but the EIP is accessing it then. We're running code at ffffxxxx.
Here is the sequence:
we're running at ffffxxxx. We write ffffffff at request of vgabios to the BAR 10. At that point vga is decoding ffxxxxxx.
We can no longer fetch code from ffffxxxx. We go bye bye.
Fix is to NOT compile the pcibios into stage0, or to also decode it into stage2.
ron
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
On Thu, Oct 16, 2008 at 2:35 PM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
Please help me understand this better. Is this a bug of real hardware, a bug of an emulator or an intended design feature?
Depending on what it is, we could employ various ways to fix it.
it's one of the few bugs in the pci design.
You write ffffffff to a register. it reads back as the moving bits + non moving bits. But at that point, until you change it, that's also the address it will decode.
In this case, sadly, we set a bar to ffffffff, to set its size, and it reads back ff000000, which gives us moving and non moving. Oh but ... it also decodes that address, top 16m of addrss space, -> no more ROM.
hardware does this? yeah, probably.
ron
On 16.10.2008 23:44, ron minnich wrote:
On Thu, Oct 16, 2008 at 2:35 PM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
Please help me understand this better. Is this a bug of real hardware, a bug of an emulator or an intended design feature?
Depending on what it is, we could employ various ways to fix it.
it's one of the few bugs in the pci design.
You write ffffffff to a register. it reads back as the moving bits + non moving bits. But at that point, until you change it, that's also the address it will decode.
In this case, sadly, we set a bar to ffffffff, to set its size, and it reads back ff000000, which gives us moving and non moving. Oh but ... it also decodes that address, top 16m of addrss space, -> no more ROM.
hardware does this? yeah, probably.
If that's it, the solution is absolutely simple. And I mean totally simple. 1. Backup old content 2. Write ffffffff 3. Read back and save in a variable 4. Restore old content. Make sure no code blacked out by the decode is executed between 1 and 4 and you're safe. If you're feeling paranoid, do it as inline asm. Make sure that short sequence is never ever run as XIP code in ROM (I can do that checking right now).
What am I missing?
Regards, Carl-Daniel
On Thu, Oct 16, 2008 at 2:52 PM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
If that's it, the solution is absolutely simple. And I mean totally simple.
- Backup old content
- Write ffffffff
at this point it is game over. The code that does this is in rom.
- Read back and save in a variable
- Restore old content.
Make sure no code blacked out by the decode is executed between 1 and 4 and you're safe. If you're feeling paranoid, do it as inline asm. Make sure that short sequence is never ever run as XIP code in ROM (I can do that checking right now).
What am I missing?
the big thing is that the problem code is a binary vga bios over which we have zero control. :-(
ron
On 16.10.2008 23:54, ron minnich wrote:
On Thu, Oct 16, 2008 at 2:52 PM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
If that's it, the solution is absolutely simple. And I mean totally simple.
- Backup old content
- Write ffffffff
at this point it is game over. The code that does this is in rom.
Hm. Unshare only this function, maybe with another name?
- Read back and save in a variable
- Restore old content.
Make sure no code blacked out by the decode is executed between 1 and 4 and you're safe. If you're feeling paranoid, do it as inline asm. Make sure that short sequence is never ever run as XIP code in ROM (I can do that checking right now).
What am I missing?
the big thing is that the problem code is a binary vga bios over which we have zero control. :-(
Hmmm. Is it running in vm86? If yes, we can trap I/O port writes and reads, so this is solvable. Same should apply to x86emu.
Regards, Carl-Daniel
On Thu, Oct 16, 2008 at 3:07 PM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
On 16.10.2008 23:54, ron minnich wrote:
On Thu, Oct 16, 2008 at 2:52 PM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
If that's it, the solution is absolutely simple. And I mean totally simple.
- Backup old content
- Write ffffffff
at this point it is game over. The code that does this is in rom.
Hm. Unshare only this function, maybe with another name?
printk?
- Read back and save in a variable
- Restore old content.
Make sure no code blacked out by the decode is executed between 1 and 4 and you're safe. If you're feeling paranoid, do it as inline asm. Make sure that short sequence is never ever run as XIP code in ROM (I can do that checking right now).
What am I missing?
the big thing is that the problem code is a binary vga bios over which we have zero control. :-(
Hmmm. Is it running in vm86? If yes, we can trap I/O port writes and reads, so this is solvable. Same should apply to x86emu.
this is getting kind of hideously complex. Let's think on it some more.
ron
On 17.10.2008 00:09, ron minnich wrote:
On Thu, Oct 16, 2008 at 3:07 PM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
On 16.10.2008 23:54, ron minnich wrote:
On Thu, Oct 16, 2008 at 2:52 PM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
If that's it, the solution is absolutely simple. And I mean totally simple.
- Backup old content
- Write ffffffff
at this point it is game over. The code that does this is in rom.
Hm. Unshare only this function, maybe with another name?
printk?
Think of point 1-4 as one "atomic" operation. pci_conf1_read_config32 does not call any other function, so simply unshare that and be happy.
- Read back and save in a variable
- Restore old content.
Make sure no code blacked out by the decode is executed between 1 and 4 and you're safe. If you're feeling paranoid, do it as inline asm. Make sure that short sequence is never ever run as XIP code in ROM (I can do that checking right now).
What am I missing?
the big thing is that the problem code is a binary vga bios over which we have zero control. :-(
Hmmm. Is it running in vm86? If yes, we can trap I/O port writes and reads, so this is solvable. Same should apply to x86emu.
this is getting kind of hideously complex. Let's think on it some more.
I'm not completely getting this. Do we run the binary blob from inside coreboot or does SeaBIOS perform that task? If coreboot does it, we have some trapping code for BIOS emulation anyway. If SeaBIOS does it, the problem is moot since SeaBIOS is independent and completely in RAM.
Regards, Carl-Daniel
On Thu, Oct 16, 2008 at 3:28 PM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
Think of point 1-4 as one "atomic" operation. pci_conf1_read_config32 does not call any other function, so simply unshare that and be happy.
it's worse than that. We found when doing this years ago that some nvidia vga bios'en don't call pcibios. They just set config space. But they might do INT10 for other reasons. The general case is that a vga bios might do something in config space that maps out ROM, since they "know" that there is no issue, and then do an INT 10, and if that happens, no code can be in rom -- including printk.
After the things I've seen, up to and including self-modifying code, I am not willing to trust a VGA bios not to do something really foolish.
So here's another option. We've always run out of high memory. But v3 has this nice 32-bit address space, and the ability to call rom, but most of it runs out of ram now. coreboot ROM segment is now 20K or less.
Why not just run the ROM section of coreboot in the F segment? What would that harm?
If we do this, the problem goes away.
I'm not completely getting this. Do we run the binary blob from inside coreboot or does SeaBIOS perform that task?
coreboot. vm86.
If coreboot does it, we have some trapping code for BIOS emulation anyway.
which is where the problem is.
ron
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Basically, vga bios tries to size a 16 meg register and at an intermediate point the vga hardware ends up decoding the top 16 mb of memory.
Hi all,
I think one _must_ disable the decoders first by disabling space in PCI_COMMAND register. Check u-boot how it does: http://git.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=blob;f=drivers/pci/pci_...
It first disable the cmdstat = (cmdstat & ~(PCI_COMMAND_IO | PCI_COMMAND_MEMORY)) | PCI_COMMAND_MASTER;
And then goes to decode. VIA bridge has also _default_ enable decode, so it blows up very badly when probing without decode enabled. Check K8M890 k8t890_bridge.c
Rudolf
On Sat, Oct 18, 2008 at 2:48 PM, Rudolf Marek r.marek@assembler.cz wrote:
Hi all,
I think one _must_ disable the decoders first by disabling space in PCI_COMMAND register. Check u-boot how it does: http://git.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=blob;f=drivers/pci/pci_...
It first disable the cmdstat = (cmdstat & ~(PCI_COMMAND_IO | PCI_COMMAND_MEMORY)) | PCI_COMMAND_MASTER;
What you are saying is true. The issue in this case is that the VGA BIOS is doing the wrong thing, and coreboot has to accommodate the VGA BIOS incorrect behaviour.
It is not something we can fix. coreboot has to tolerate the improper behaviour of PCI expansion ROMs and VGA BIOS.
ron
Hi Ron,
Oke thanks for the clarification, I was just looking very quickly into this. But anyway, we should disable the decoders in our PCI probing routines.
Thanks Rudolf
On Sun, Oct 19, 2008 at 7:06 AM, Rudolf Marek r.marek@assembler.cz wrote:
Hi Ron,
Oke thanks for the clarification, I was just looking very quickly into this. But anyway, we should disable the decoders in our PCI probing routines.
I thought we did already.
ron
-
Carl-Daniel Hailfinger -
Marc Jones -
Myles Watson -
ron minnich -
Rudolf Marek