[OpenBIOS] [PATCH] pci: fix BAR setup

Jakub Jermar jakub at jermar.eu
Thu May 10 23:48:09 CEST 2012


Hi Artyom, all,

On 04/19/2012 10:29 PM, Artyom Tarasenko wrote:
> On Thu, Apr 19, 2012 at 10:04 PM, Blue Swirl <blauwirbel at gmail.com> wrote:
>> On Thu, Apr 19, 2012 at 19:06, Artyom Tarasenko <atar4qemu at gmail.com> wrote:
>>> On Sun, Mar 11, 2012 at 11:59 AM, Blue Swirl <blauwirbel at gmail.com> wrote:
>>>> A change in QEMU on how PCI bridges are setup revealed
>>>> a bug in OpenBIOS PCI setup. On Sparc64, the BARs just
>>>> happened to get somewhat correct values by accident before
>>>> the commit but not after the change.
>>>>
>>>> Don't use arch->io_base for PCI I/O port BARs.
>>>>
>>>> Fix Sparc64 PCI memory base.
>>>
>>> Could it be that the ranges property needs to be adjusted to look as
>>> it did before the patch?
>>>
>>> This patch breaks HelenOS-0.4.3/sparc boot. But if I modify the ranges
>>> property to the old value, HelenOS boots.
>>>
>>> 0 > cd /pci at 1fe,0  ok
>>> 0 > .properties
>>> [...]
>>> ranges                    -- 54 : 00 00 00 00 00 00 00 00 00 00 00 00
>>> 00 00 01 fe 01 00 00 00 00 00 00 00 02 00 00 00 01 00 00 00 00 00 00
>>> 00 00 00 00 00 00 00 01 fe 02 00 00 00 00 00 00 00 00 01 00 00 02 00
>>> 00 00 00 00 00 00 00 10 00 00 00 00 01 ff 00 00 00 00 00 00 00 00 10
>>> 00 00 00
>>>
>>> Not sure about the best formatting. If I reformat it like this:
>>>
>>> 00000000 00000000 00000000 000001fe 01000000 00000000 02000000
>>> 01000000 00000000 00000000 000001fe 02000000 00000000 00010000
>>> 02000000 00000000 00100000 000001ff 00000000 00000000 10000000
>>>                               ^^^^ this one (the third) used to be 0
>>>
>>
>> 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?

I am now looking into this from the HelenOS point of view. The problem
is that HelenOS miscomputes the framebuffer physical address.

I think I found the culprit in the ranges property of the PCI node. The
mechanism of the bug seems to be as follows.

HelenOS reads the parent-relative address of the VGA node from the reg
property. The address is 0x008000000. It then wants to apply it on the
parent node's (PCI) ranges property. Using a packed C structure, a range
is defined as follows:

typedef struct {
        uint32_t space;
        uint64_t child_base;
        uint64_t parent_base;
        uint64_t size;
};

Note that in our case, the matching range is:

02000000 00000000 00100000 000001ff 00000000 00000000 10000000

child_base is 0x00100000
parent_base is 0x1ff00000000
reg_addr is 0x00800000

HelenOS then computes the resulting physical address using this formula:

pa = parent_base + (reg_addr - child_base);

The result is thus 0x1ff00700000 instead of the correct value 0x1ff00800000.

So it looks like either the child base should be 0, or reg_addr must be
0x00900000, or parent_base must be 0x1ff00100000. From the way this
works e.g. on Sun E6500, the last option seems to be the correct one.

What do you think of it?

Jakub



More information about the OpenBIOS mailing list