qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] QEMU+Linux ARMv7A current state


From: Peter Maydell
Subject: Re: [Qemu-devel] QEMU+Linux ARMv7A current state
Date: Sun, 4 Oct 2015 11:42:54 +0100

On 3 October 2015 at 23:14, Peter Crosthwaite
<address@hidden> wrote:
> On Sat, Oct 3, 2015 at 2:51 PM, Peter Maydell <address@hidden> wrote:
>> Did you build your kernel with LPAE or not? I think an LPAE
>> config ought to avoid the PCI highmem bug (and it's definitely
>> what you want for anything that's Cortex-A15 based).
>>
>
> No. Although any missing configs I consider to be our problem, or a
> bug in the multi_v7_defconfig in upstream Linux. That defconfig really
> should work for us.

IIRC you can't build a kernel for both LPAE and non-LPAE at
once -- the two are mutually exclusive.

>> For real hardware I expect people will be using USB disks.
>> We don't currently model the USB controller in QEMU, though.
>
> Looks like a custom job too. Not much chance here unless this is a
> rebadging of one of the existing HCIs?

It's a Philips ISP1761. I think it's EHCI + USB OTG + probably
some minor registers. It could be modelled in theory...

>> "realview" is not really a very helpful term to use here, because
>> it's a generic label applied to a whole slew of ARM devboards.
>> What QEMU models is:
>>  "realview-eb" -- the RealView Emulation Baseboard with an ARM926
>>  "realview-eb-mpcore" -- the RealView Emulation Baseboard with an 11MPCore
>>  "realview-pb-a8" -- the RealView Platform Baseboard for Cortex A8
>>  "realview-pbx-a9" -- the RealView Platform Baseboard Explore for Cortex A9
>>
>> The DT in the kernel tree is for the Realview Platform Baseboard
>>   for 1176, ie PB1176. That's a different board from EB1176, as
>> you've found. This is why "realview" on its own (or with a CPU
>> name) is not sufficient to identify a board and why we have those
>> -eb- and -pb(x)- infixes in our board names :-)
>>
>
> So does this mean that the EB memory maps are consistent but perhaps
> not the PB? Can we reliably gen all combinations with EB vs PB with
> just two memory maps, then add 1176 both ways?

I think the PB1176 looks more like the PB926 (which we model as
"versatilepb") than the PBA8 or PBXA9 -- for instance the latter
two have a completely different PCI controller. You'd need to
cross-check all the board manuals to be sure.

Regardless, rather than implementing a model of yet another
old ARM devboard nobody really cares about, it seems to me
that the effort would be better spent in converting the kernel
support for the boards we already model to use device tree...

thanks
-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]