Re: [Qemu-devel] [PATCH for-1.5 0/3] hw/pci-host/versatile: Fix issues with newer kernels

[Arnd Bergmann <arnd@arndb.de>]

On Wednesday 15 May 2013, Linus Walleij wrote:
> On Tue, May 14, 2013 at 5:33 PM, Peter Maydell <peter.maydell@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.walleij@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