[U-Boot] [PATCH v2 5/6] PPC 85xx: Find PCI host controllers on ppce500 from device tree
Scott Wood
scottwood at freescale.com
Fri Feb 7 19:43:59 CET 2014
On Fri, 2014-02-07 at 13:25 +0100, Alexander Graf wrote:
> On 06.02.2014, at 23:52, Scott Wood <scottwood at freescale.com> wrote:
>
> > On Thu, 2014-02-06 at 14:26 +0100, Alexander Graf wrote:
> >> On 04.02.2014, at 03:47, Scott Wood <scottwood at freescale.com> wrote:
> >>
> >>> On Fri, 2014-01-31 at 12:16 +0100, Alexander Graf wrote:
> >>>> The definition of our ppce500 PV machine is that every address is dynamically
> >>>> determined through device tree bindings.
> >>>>
> >>>> So don't hardcode where PCI devices are in our physical memory layout but instead
> >>>> read them dynamically from the device tree we get passed on boot.
> >>>
> >>> Would it be difficult to make the QEMU emulation properly implement
> >>> access windows?
> >>
> >> What are access windows? You mean BAR region offsets? Not too hard I
> >> suppose, but it adds complexity which we were trying to avoid, no?
> >
> > It would remove U-Boot complexity (unlike the LAW stuff where we just
> > skip it) because we wouldn't need to care about QEMU's default settings.
> > It should be easier to do than LAW support, and more useful (e.g. Linux
> > currently programs this as well, we just get lucky that it misuses the
> > device tree as configuration information).
>
> What complexity would it remove?
Getting the PCI translation window addresses from the device tree.
> We would still need to find the configuration space for the access
> windows,
That's easier -- just a standard reg lookup.
> configure them
That code's already there.
> and then even go as far as modifying the original device tree so we
> expose the new windows.
It would be nice if we did this regardless of QEMU. As is, IIRC we have
some device trees that don't match what U-Boot does, which works (at
least in Linux) because Linux reprograms it to match the device tree.
-Scott
More information about the U-Boot
mailing list