From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sergei Shtylyov Date: Sat, 02 Dec 2006 17:36:05 +0300 Subject: [U-Boot-Users] U-Boot allocating PCI I/O space from 0 (Was: pata_sl82c105 can not reserve IO region) In-Reply-To: <1165011583.22108.17.camel@localhost.localdomain> References: <20061130165202.GA23205@aepfle.de> <20061130171049.7b80a40c@localhost.localdomain> <20061130184748.GA24071@aepfle.de> <20061201183355.GA9701@aepfle.de> <45707CF8.3090106@ru.mvista.com> <1165010029.22108.10.camel@localhost.localdomain> <20061201221525.7a741062@localhost.localdomain> <1165011583.22108.17.camel@localhost.localdomain> Message-ID: <45718F55.4080903@ru.mvista.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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