[OpenBIOS] [PATCH] pci: fix BAR setup

Tarl Neustaedter 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 mailing list