On Wednesday 15 May 2013, Linus Walleij wrote:
> On Tue, May 14, 2013 at 5:33 PM, Peter Maydell <peter.mayd...@linaro.org>
> wrote:
>
> > The reworking of the versatile PCI controller model so that it actually
> > behaved like hardware included an attempt to autodetect whether the
> > guest Linux kernel was assuming the old broken behaviour. Unfortunately
> > it turns out that there are several different variant broken kernels
> > which behave slightly differently (though none of them will work on
> > real hardware). The first two patches in this series improve the
> > autodetection so that we will work out of the box on more kernels.
> > The third patch adds a property for forcing the behaviour, so that
> > if there are further cases we didn't know about, at least users have
> > a command line workaround they can enable.
>
> This looks like a viable approach to me. So FWIW:
> Acked-by: Linus Walleij <linus.wall...@linaro.org>
FWIW, I plan to really get this done in the kernel for 3.11 properly
and rework the entire versatile and realview code base to work without
any platform specific code in arch/arm. The plan is to use the new
infrastructure for PCI and put that code into drivers/pci/host,
and have it scan the hardware using DT only. We can have a backwards
compatibility setup for versatile-pb without DT, but in the long
run, I would prefer to kill off that boot option.
If this works out, any Linux kernel built for any platform should
be able to boot the versatilepb, versatileab, integratorcp, realview-eb,
realview-eb-mpcore, realview-pb-a8, realview-pbx-a9, vexpress-a9
and vexpress-a15 models, as long as you pass a -cpu option matching
a CPU enabled in the kernel, and all the drivers are enabled.
I remember there was a way to autogenerate the dtb blob in qemu at
some point, based on the devices enabled in the model. Did that ever
make it in?
Arnd
