Hello,
It seems that the resource allocation for option rom is not implemented in LinuxBIOS, is it ? Is there one have any idea how to add this ?
Ollie
Li-Ta Lo ollie@lanl.gov writes:
Hello,
It seems that the resource allocation for option rom is not implemented in LinuxBIOS, is it ? Is there one have any idea how to add this ?
We could probably reserve a hole for this purpose, which is a good idea except for bridges.
Be very careful here. The PCI spec allows the option rom BAR to be mutually exclusive with the other BARS so in general they both can not be enabled.
Eric
* Eric W. Biederman ebiederman@lnxi.com [040527 22:16]:
We could probably reserve a hole for this purpose, which is a good idea except for bridges.
Also, the graphics card option roms are usually hardcoded to 0xc0000
Be very careful here. The PCI spec allows the option rom BAR to be mutually exclusive with the other BARS so in general they both can not be enabled.
The only safe way to go is probably to probe one after the other while leaving the rest untouched, i.e
1) probe option rom, if it doesn't exist go to 6. 2) enable option rom 3) evtl. copy rom code to ram (in case it installs an int13 handler or such) 4) execute option rom code. 5) disable option rom 6) repeat this for all pci devices.
This procedure should be a part of "testbios" rather than LinuxBIOS' PCI code, but reserving some space for it early might be the way to go indeed.
Stefan
On Thu, 2004-05-27 at 14:16, Eric W. Biederman wrote:
We could probably reserve a hole for this purpose, which is a good idea except for bridges.
Can we just treat it as MEM resource and reuse the MEM resource allocation code ?
Be very careful here. The PCI spec allows the option rom BAR to be mutually exclusive with the other BARS so in general they both can not be enabled.
Where is this stated in the spec ?
Ollie
On Thu, 2004-05-27 at 14:30, Stefan Reinauer wrote:
- Eric W. Biederman ebiederman@lnxi.com [040527 22:16]:
We could probably reserve a hole for this purpose, which is a good idea except for bridges.
Also, the graphics card option roms are usually hardcoded to 0xc0000
Do you mean the expansion rom BAR is hard coded to 0xc0000 ? The how does the bios copy the bios in ROM at 0xc0000 to memory in DRAM at 0xc0000 as stated in PCI spec 6.3.3.1.1 ?
Be very careful here. The PCI spec allows the option rom BAR to be mutually exclusive with the other BARS so in general they both can not be enabled.
The only safe way to go is probably to probe one after the other while leaving the rest untouched, i.e
- probe option rom, if it doesn't exist go to 6.
- enable option rom
- evtl. copy rom code to ram (in case it installs an int13 handler or such)
- execute option rom code.
- disable option rom
- repeat this for all pci devices.
If I am right you should disable option rom BEFORE execute the code in DRAM. The spec says it is possible that the other BAR shares the same address decoder with ROM BAR.
Ollie
This procedure should be a part of "testbios" rather than LinuxBIOS' PCI code, but reserving some space for it early might be the way to go indeed.
Stefan
* Li-Ta Lo ollie@lanl.gov [040527 22:49]:
Also, the graphics card option roms are usually hardcoded to 0xc0000
Do you mean the expansion rom BAR is hard coded to 0xc0000 ? The how does the bios copy the bios in ROM at 0xc0000 to memory in DRAM at 0xc0000 as stated in PCI spec 6.3.3.1.1 ?
I know some intel chipsets did this by forwarding reads from 0xc0000 to rom and writes to 0xc0000 to ram, then reading and rewriting the whole area to the same address. I'd assume that this is still handled similar but on AMD64 rather using the MEM maps?
- probe option rom, if it doesn't exist go to 6.
- enable option rom
- evtl. copy rom code to ram (in case it installs an int13 handler or such)
- execute option rom code.
- disable option rom
- repeat this for all pci devices.
If I am right you should disable option rom BEFORE execute the code in DRAM. The spec says it is possible that the other BAR shares the same address decoder with ROM BAR.
D'uh, of course! First 5 then 4, i mixed it up. Otherwise you risk running into exactly the mutual exclusive BAR problem that Eric described.
Stefan
On Thu, 27 May 2004, Li-Ta Lo wrote:
It seems that the resource allocation for option rom is not implemented in LinuxBIOS, is it ? Is there one have any idea how to add this ?
When I borrowed that code originally from linux I believe it always disabled option roms. You should be able to extend the code to 1- allocate a chunk of physical address space (using the pci allocate code) 2- set the special option rom BAR to that space
I don't think it should be too hard.
ron
On 27 May 2004, Eric W. Biederman wrote:
Be very careful here. The PCI spec allows the option rom BAR to be mutually exclusive with the other BARS so in general they both can not be enabled.
should not matter if you are running an emulator.
ron
On Thu, 27 May 2004, Stefan Reinauer wrote:
This procedure should be a part of "testbios" rather than LinuxBIOS' PCI code, but reserving some space for it early might be the way to go indeed.
just remember you're in an emulator. If you can get option rom contents copied out then the emulator will put it somewhere internally and pretend it's at the option rom address.
ron
On Thu, 27 May 2004, Li-Ta Lo wrote:
Do you mean the expansion rom BAR is hard coded to 0xc0000 ?
it's not. It can be anywhere. For dumping vgabios I would actually set it by setpci to an unused place, mmap /dev/mem, and dump it out. It can go anywhere.
ron
On Thu, 27 May 2004, Stefan Reinauer wrote:
- Li-Ta Lo ollie@lanl.gov [040527 22:49]:
Also, the graphics card option roms are usually hardcoded to 0xc0000
Do you mean the expansion rom BAR is hard coded to 0xc0000 ? The how does the bios copy the bios in ROM at 0xc0000 to memory in DRAM at 0xc0000 as stated in PCI spec 6.3.3.1.1 ?
I know some intel chipsets did this by forwarding reads from 0xc0000 to rom and writes to 0xc0000 to ram, then reading and rewriting the whole area to the same address. I'd assume that this is still handled similar but on AMD64 rather using the MEM maps?
again, you do not need to map option roms at 0c0000 in the emulator!
Map it anywhere, tell the emulator the location, and the emulator can satisfy memory "fetches" for c0000 by fetching from that location.
Emulators are good.
ron
* ron minnich rminnich@lanl.gov [040527 23:21]:
again, you do not need to map option roms at 0c0000 in the emulator!
Map it anywhere, tell the emulator the location, and the emulator can satisfy memory "fetches" for c0000 by fetching from that location.
indeed true. But for x86 hardware, putting all of the x86 emulator in rom is less elegant than vm86 stuff, even though I have no clue about the later.
Stefan
Li-Ta Lo ollie@lanl.gov writes:
On Thu, 2004-05-27 at 14:16, Eric W. Biederman wrote:
We could probably reserve a hole for this purpose, which is a good idea except for bridges.
Can we just treat it as MEM resource and reuse the MEM resource allocation code ?
Yes that would be the easy way to reserver an area for the rom to be enabled. If the BAR is not large this should not be a problem.
Be very careful here. The PCI spec allows the option rom BAR to be mutually exclusive with the other BARS so in general they both can not be enabled.
Where is this stated in the spec ?
I saw it once long ago. And the kernel avoids it. But enabling just that BAR copying the data out, and then reenabling the rest should not be a problem.
Eric
On Thu, 27 May 2004, Stefan Reinauer wrote:
indeed true. But for x86 hardware, putting all of the x86 emulator in rom is less elegant than vm86 stuff, even though I have no clue about the later.
yes but recall that the emulator lets you support systems like power pc.
ron
Stefan Reinauer stepan@openbios.org writes:
- ron minnich rminnich@lanl.gov [040527 23:21]:
again, you do not need to map option roms at 0c0000 in the emulator!
Map it anywhere, tell the emulator the location, and the emulator can satisfy memory "fetches" for c0000 by fetching from that location.
indeed true. But for x86 hardware, putting all of the x86 emulator in rom is less elegant than vm86 stuff, even though I have no clue about the later.
Last I heard some Option Roms switch to 32bit mode. You can't do that in vm86 mode. In general using vm86 is a way to put your fate in someone else's hands.
We could possibly call the option roms directly but unless the space cost is high an open source emulator is a good choice.
Eric
* Eric W. Biederman ebiederman@lnxi.com [040529 05:29]:
Stefan Reinauer stepan@openbios.org writes:
indeed true. But for x86 hardware, putting all of the x86 emulator in rom is less elegant than vm86 stuff, even though I have no clue about the later.
Last I heard some Option Roms switch to 32bit mode. You can't do that in vm86 mode. In general using vm86 is a way to put your fate in someone else's hands.
Uh, this was the kind of thing I was scared would be the case. what happens in such a case? Is there any way to trap this and at least safely state that the device can't be supported?
We could possibly call the option roms directly but unless the space cost is high an open source emulator is a good choice.
So the goal should rather be to reduce the size of the emulator than to introduce different code paths for different platforms it seems.
Stefan
Hello,
I got something something i cant get rid of. In the src/lib directory, it holds memory allocations and relatives progs. Why are they redefined ? I mean couldn't we use standard's definitions ? I've seen there are debug dumps mechanisms but surely as in standard's def.?
Could you enlighten me on this point ?
Thanks mathieu
Mathieu Deschamps mdeschamps@mangrove-systems.com writes:
Hello,
I got something something i cant get rid of. In the src/lib directory, it holds memory allocations and relatives progs. Why are they redefined ? I mean couldn't we use standard's definitions ? I've seen there are debug dumps mechanisms but surely as in standard's def.?
Could you enlighten me on this point ?
Consider what it means to be a stand-alone program on the hardware. Consider why every kernel does the same thing.
Eric
Stefan Reinauer stepan@openbios.org writes:
- Eric W. Biederman ebiederman@lnxi.com [040529 05:29]:
Stefan Reinauer stepan@openbios.org writes:
indeed true. But for x86 hardware, putting all of the x86 emulator in rom is less elegant than vm86 stuff, even though I have no clue about the later.
Last I heard some Option Roms switch to 32bit mode. You can't do that in vm86 mode. In general using vm86 is a way to put your fate in someone else's hands.
Uh, this was the kind of thing I was scared would be the case. what happens in such a case? Is there any way to trap this and at least safely state that the device can't be supported?
Yes. What happens with a vm86 based implementation is you need an emulator for all of the slow path cases. At which point a pure emulator is likely simpler. Plus vm86 is currently deprecated.
We could possibly call the option roms directly but unless the space cost is high an open source emulator is a good choice.
So the goal should rather be to reduce the size of the emulator than to introduce different code paths for different platforms it seems.
Stefan you should not need different code paths for different platforms. And code size is secondary to correctness, but it is and will remain an important consideration.
Eric
Eric W. Biederman wrote:
Li-Ta Lo ollie@lanl.gov writes:
On Thu, 2004-05-27 at 14:16, Eric W. Biederman wrote:
We could probably reserve a hole for this purpose, which is a good idea except for bridges.
Can we just treat it as MEM resource and reuse the MEM resource allocation code ?
Yes that would be the easy way to reserver an area for the rom to be enabled. If the BAR is not large this should not be a problem.
Did this happen? I'm trying to get a plug in PCI video card up with ADLO and I need the option rom to be enabled. I can do it direcly in my mainboard code for a hack but If there was anything to test I though I would try.
On Wed, 2004-06-23 at 10:24, Richard Smith wrote:
Eric W. Biederman wrote:
Li-Ta Lo ollie@lanl.gov writes:
On Thu, 2004-05-27 at 14:16, Eric W. Biederman wrote:
We could probably reserve a hole for this purpose, which is a good idea except for bridges.
Can we just treat it as MEM resource and reuse the MEM resource allocation code ?
Yes that would be the easy way to reserver an area for the rom to be enabled. If the BAR is not large this should not be a problem.
Did this happen? I'm trying to get a plug in PCI video card up with ADLO and I need the option rom to be enabled. I can do it direcly in my mainboard code for a hack but If there was anything to test I though I would try.
How is testbios doing on your side ?
Ollie
Li-Ta Lo wrote:
Did this happen? I'm trying to get a plug in PCI video card up with ADLO and I need the option rom to be enabled. I can do it direcly in my mainboard code for a hack but If there was anything to test I though I would try.
How is testbios doing on your side ?
It's proving very useful.
I have tested it on another pc with my M1 eval PCI card and on that machine I can boot with the Vbios removed, run testbios and I get a signon message. Yay.
So my other test pc must have some problem with not setting up access to a0000-bffff properly when you boot a card with out a bios. Just like you suspected.
So now that I have a golden path with the emulator I have been doing log comparisons between the eval card in the pc vs in our target board.
Comparing IO accesses I don't find any meaningfull differences. So I upped the logging to include memory reads/writes as well. Looks like when the vbios trys to do a memory test on a0000 it fails.
I've also managed to make our COTS bios from the previous rev of this board boot as well. It does option ROM scans and booting that bios with the PCI eval card stuck in does exactly the same thing as my linuxbios setup + emulator does. The COTS bios also has a vid mem test and if I enable that it will fail as well.
So now I've got failure under both linux bios and a COTS bios using a PCI eval card that is known to work.
So its pretty much got to be some sort of hardware problem with access to the legacy VGA range. Something fscked with the northbridge perhaps. I'm hacking up the vbios source to do the a0000 test over and over and tomorow we are going to see where those accesses are really going if at all.
As far as testbios is concerned the only mod it would need to work with my stock ATI bios is the timer IO access trapping and reporting back a consistant value.
Its not really an issue for me since the ATI vbios works fine under testbios with the problematic ATI delay hacked to just return rather than delay. The delay provided by the emulator appears to be enough. Thats what I've been using for all my testing so far.
-
ebiederman＠lnxi.com -
Li-Ta Lo -
Mathieu Deschamps -
Richard Smith -
ron minnich -
Stefan Reinauer