On Fri, 2014-02-07 at 13:25 +0100, Alexander Graf wrote: > On 06.02.2014, at 23:52, Scott Wood <scottw...@freescale.com> wrote: > > > On Thu, 2014-02-06 at 14:26 +0100, Alexander Graf wrote: > >> On 04.02.2014, at 03:47, Scott Wood <scottw...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot