[U-Boot-Users] U-Boot allocating PCI I/O space from 0 (Was: pata_sl82c105 can not reserve IO region)

[U-Boot-Users] U-Boot allocating PCI I/O space from 0 (Was: pata_sl82c105 can not reserve IO region)

[Sergei Shtylyov]

Hello.

Benjamin Herrenschmidt wrote:

>>I don't think that is the problem. pci_request_regions() handles all
>>this internally. It is incorrect for me to not request BAR 5
>>if present as nobody else should use that resource with my driver loaded.

>>The underlying problem appears to be that PPC64 isn't setting up the
>>resources properly (at least as viewed by the pci core code). If a
>>resource is not set up then pci_request_resource() correctly handles
>>it .. except on PPC64. You have a resource at zero with a length and
>>type. PPC64 is not reporting to the upper layers that the resource was
>>not allocated. It is reporting that the resource *was* allocated, and at a
>>bogus address of zero.

>>If you trust the firmware that is fine, but you need to report the truth,
>>at which point pci_request_resources() will work correctly.

> We don't have a choice but to trust the firmware on those machines. We
> can't assign things ourselves on most of them for various reasons (in
> many cases, the hypervisor won't let us).

> So you suggest that I clear resource->flags in that case ?

> I think part of the problem is a firmware bug in that the firmware data
> actually decodes to BAR 5 is assigned to address 0 ... I suppose we can
> consider that address 0 is never valid on those machines and consider
> that as unassigned but it's a bit dodgy.. Or maybe a PCI quirk in the
> pSeries code would be best.

    Well, I'm having a very related issue with the U-Boot on MPC85xx: recently 
I've noticed that it started allocating PCI I/O space from 0 (while the older 
versions started from 0x1000). The IDE core can't tolerate this, giving me 
such messages on bootup:

PDC20269: inconsistent baseregs (BIOS) for port 0, skipping

when I have Promise Ultra133TX2 card inserted into PCI alone. I've looked thru 
the U-Boot sources and commit history but failed to locate the change that led 
to this...

WBR, Sergei

[U-Boot-Users] U-Boot allocating PCI I/O space from 0 (Was: pata_sl82c105 can not reserve IO region)

[Sergei Shtylyov]

Hello.

Sergei Shtylyov wrote:

>     Well, I'm having a very related issue with the U-Boot on MPC85xx: recently 
> I've noticed that it started allocating PCI I/O space from 0 (while the older 
> versions started from 0x1000). The IDE core can't tolerate this, giving me 
> such messages on bootup:

> PDC20269: inconsistent baseregs (BIOS) for port 0, skipping

> when I have Promise Ultra133TX2 card inserted into PCI alone. I've looked thru 
> the U-Boot sources and commit history but failed to locate the change that led 
> to this...

    It's actually much worse than just that. When I also plug in some other 
PCI card so Ultra133TX2 doesn't get the zero addresses anymore, I'm getting this:

eepro100.c: $Revision: 1.36 $ 2000/11/17 Modified by Andrey V. Savochkin
<saw@saw.sw.com.sg> and others
eth3: Invalid EEPROM checksum 0xfffe, check settings before activating this
device!
eth3: OEM i82557/i82558 10/100 Ethernet, 00:00:00:00:FF:FF, IRQ 52.
[...]
PDC20269: 100% native mode on irq 51
     ide2: BM-DMA at 0x0060-0x0067, BIOS settings: hde:pio, hdf:pio
PDC20269: simplex device: DMA disabled
ide3: PDC20269 Bus-Master DMA disabled (BIOS)

    I've just verified that both these cards are working OK in x86 box
As for the simplex message, I've encountered this some months ago and it was 
caused by invalid programming of the MPC85xx bridge PCI/X outbound translation 
address register for the I/O space or at least by the non-zero value of the 
bus I/O address in the "ranges" property of the bridge device node in the 
device tree... I'm somewhat confused now since I know that the relevant U-Boot 
code has been fixed but it looks like that made it only worse -- I was using 
the custom patched version of U-Boot before which missed that fix:

http://www.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=commitdiff;h=97074ed9655309b64231bc2cee69fe85399f8055

WBR, Sergei

[U-Boot-Users] U-Boot allocating PCI I/O space from 0 (Was: pata_sl82c105 can not reserve IO region)

[Sergei Shtylyov]

Hello, I wrote:

>>    Well, I'm having a very related issue with the U-Boot on MPC85xx: recently 
>>I've noticed that it started allocating PCI I/O space from 0 (while the older 
>>versions started from 0x1000). The IDE core can't tolerate this, giving me 
>>such messages on bootup:

>>PDC20269: inconsistent baseregs (BIOS) for port 0, skipping

    This is due to U-Boot assigning the PCI resources fram address 0 (which is 
BTW illegal according to PCI 2.1).  I have a patch for drivers/pci_auto.c 
which I'm going to post tomorrow...

>>when I have Promise Ultra133TX2 card inserted into PCI alone. I've looked thru 
>>the U-Boot sources and commit history but failed to locate the change that led 
>>to this...

>     It's actually much worse than just that. When I also plug in some other 
> PCI card so Ultra133TX2 doesn't get the zero addresses anymore, I'm getting this:

> eepro100.c: $Revision: 1.36 $ 2000/11/17 Modified by Andrey V. Savochkin
> <saw@saw.sw.com.sg> and others
> eth3: Invalid EEPROM checksum 0xfffe, check settings before activating this
> device!
> eth3: OEM i82557/i82558 10/100 Ethernet, 00:00:00:00:FF:FF, IRQ 52.
> [...]
> PDC20269: 100% native mode on irq 51
>      ide2: BM-DMA at 0x0060-0x0067, BIOS settings: hde:pio, hdf:pio
> PDC20269: simplex device: DMA disabled
> ide3: PDC20269 Bus-Master DMA disabled (BIOS)

>     I've just verified that both these cards are working OK in x86 box
> As for the simplex message, I've encountered this some months ago and it was 
> caused by invalid programming of the MPC85xx bridge PCI/X outbound translation 
> address register for the I/O space

    No, the programming was valid. I've finally found the ultimate reason of 
breakage -- it lies in board/*/init.S files.  The patch tomorrow...

> or at least by the non-zero value of the 
> bus I/O address in the "ranges" property of the bridge device node in the 
> device tree...

    It was the real reason -- the arch/powerpc/ kernel just ignores ranges 
with non-zero I/O port address.

> I'm somewhat confused now since I know that the relevant U-Boot
> code has been fixed but it looks like that made it only worse -- I was using 
> the custom patched version of U-Boot before which missed that fix:

> http://www.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=commitdiff;h=97074ed9655309b64231bc2cee69fe85399f8055

    It was actually the following patch that broke PCI:

http://www.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=commit;h=52c7a68b8d587ebcf5a6b051b58b3d3ffa377ddc

    There were other places relying on CFG_PCI1_IO_BASE and those weren't 
changed... sigh. :-/

WBR, Sergei