[OpenBIOS] [PATCH] pci: fix BAR setup
tarl-b2 at tarl.net
Thu Apr 19 23:13:23 CEST 2012
On 2012-Apr-19 16:29 , Artyom Tarasenko wrote:
>> > On an Ultra-5 this should be
>> > 00000000.00000000.00000000.000001fe.01000000.00000000.01000000.
>> > 01000000.00000000.00000000.000001fe.02000000.00000000.01000000.
>> > 02000000.00000000.00000000.000001ff.00000000.00000001.00000000.
>> > 03000000.00000000.00000000.000001ff.00000000.00000001.00000000
>> > http://git.kernel.org/?p=linux/kernel/git/davem/prtconfs.git;a=blob;f=ultra5;h=e0300cecd79cdb4ef435272a4bc2c7f758fa4dbd;hb=HEAD#l164
>> > I guess the problem is that the properties are added by finding the
>> > host bridge in the PCI bus (which btw isn't so nice), so we use the
>> > pci_mem_base. Using pci_mem_base = 0 would probably fix the BAR, but
>> > then VGA would get in the way. Probably something more complex is
>> > needed.
> Hmm. Complicated. What is actually the meaning of this property? Don't
> we need the values ourselves?
> If these are just BARs, can't we pass the configuration from qemu?
It's the usable address ranges on PCI - 00 is Config space, 01 is IO
space, 02 is 32-bit memory and 03 is 64-bit memory.
Two gotchas I know of around the memory properties. First, in Openboot,
we had to hard-code never allocating address zero for memory. Too many
cards out there treat a zero address in the bar as meaning "off".
The other is that in the above 32-bit and 64-bit memory spaces overlap.
If you try to implement this "correctly" (with a separate allocator for
each), you'll end up stepping on yourself as you allocate the same
address twice. But Ultra-5 doesn't support real 64-bit, so you end up
pointing both 32-bit and 64-bit allocators to the same database.
More information about the OpenBIOS