[Qemu-devel] Update the id of Vexpress Cortex-A9 from r0p0 to r0p1?

[Qemu-devel] Update the id of Vexpress Cortex-A9 from r0p0 to r0p1?

[Mian Yousaf Kaukab]

Hi,

Default vexpress_defconfig does not boot on qemu vexpress-a9 target. In kernel,
vexpress uart detection for DEBUG_LL is done using Coretex-A9 id. Only r0p1 is
mapped to legacy map. All other variants are mapped to RS1/aseries map.

As qemu vexpress-a9 target reports Cortex-A9 version as r0p0, kernel maps uart0
at address 0x1c090000 instead of 0x10009000. This result in kernel indefinitely
waiting for uart during boot. A kernel patch to fix this was discussed
in the following link
http://comments.gmane.org/gmane.linux.ports.arm.kernel/269657 .
In this discussion Pawel Moll mentioned that V2P-CA9 has Cortex-A9 r0p1 and not
r0p0. If this is correct, to fix this and similar future problems, shouldn't
qemu Cortex-A9 be updated to version r0p1?

So what will it take to update the id of Cortex-A9 in qemu from r0p0 to r0p1?

I started looking at differences between r0p0 and r0p1, which can be found at
the following link
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0388e/CACDGEDG.html

The increase in micro TLB entries should not make a difference as qemu is not
cycle accurate and with a quick search in ARM documentation I couldn't find
any register showing number of micro TLB entries. Note that the change is in
micro TLB and not in unified TLB.

However, I am not sure if the engineering errata implemented in r0p1 will
require any change in qemu. Anyone have more information about this?

Any other IPs that will need to be updated along with the ARM core?

Sincerely,

Yousaf

Re: [Qemu-devel] Update the id of Vexpress Cortex-A9 from r0p0 to r0p1?

[Peter Maydell]

On 6 October 2013 20:12, Mian Yousaf Kaukab <yrehan@gmail.com> wrote:
> Default vexpress_defconfig does not boot on qemu vexpress-a9 target. In kernel,
> vexpress uart detection for DEBUG_LL is done using Coretex-A9 id. Only r0p1 is
> mapped to legacy map. All other variants are mapped to RS1/aseries map.

Detecting the board model based on the CPU revision-and-patchlevel is a
horrible hack and I wish the kernel guys would drop it.

Really the kernel should provide a way to specify (in the device tree
or otherwise)
where the UART is, in a way that the early kernel code can easily get at to use
for its earlyprint uart.

> As qemu vexpress-a9 target reports Cortex-A9 version as r0p0, kernel maps uart0
> at address 0x1c090000 instead of 0x10009000. This result in kernel indefinitely
> waiting for uart during boot. A kernel patch to fix this was discussed
> in the following link
> http://comments.gmane.org/gmane.linux.ports.arm.kernel/269657 .
> In this discussion Pawel Moll mentioned that V2P-CA9 has Cortex-A9 r0p1 and not
> r0p0. If this is correct, to fix this and similar future problems, shouldn't
> qemu Cortex-A9 be updated to version r0p1?

The trouble is that QEMU models CPUs and boards separately and
doesn't model every single variant/patchlevel of each CPU, because
that would be a fairly large amount of extra effort.

> So what will it take to update the id of Cortex-A9 in qemu from r0p0 to r0p1?

If we're updating, why would we update only to r0p1 and not to the most
recent rev/patchlevel?

The major thing we need is a mechanism for allowing at least the
board, and possibly also the user, to specify properties of the cpu
like "which rev/patchlevel is it" (being able to specify "do we have an
fpu/neon/etc" is a similar thing).

If we had that it would not be too hard to then have the vexpress-a9
board specify which rev/patchlevel to use. But we don't have the
mechanism currently.

-- PMM

Re: [Qemu-devel] Update the id of Vexpress Cortex-A9 from r0p0 to r0p1?

[Andreas Färber]

Am 06.10.2013 14:10, schrieb Peter Maydell:
> The major thing we need is a mechanism for allowing at least the
> board, and possibly also the user, to specify properties of the cpu
> like "which rev/patchlevel is it"

I believe I posted patches for that long ago, to clean up the PXA mess a
little... probably need to be rebased by now.

Andreas

> (being able to specify "do we have an
> fpu/neon/etc" is a similar thing).
> 
> If we had that it would not be too hard to then have the vexpress-a9
> board specify which rev/patchlevel to use. But we don't have the
> mechanism currently.


-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] Update the id of Vexpress Cortex-A9 from r0p0 to r0p1?

[Peter Maydell]

On 7 October 2013 02:26, Andreas Färber <afaerber@suse.de> wrote:
> Am 06.10.2013 14:10, schrieb Peter Maydell:
>> The major thing we need is a mechanism for allowing at least the
>> board, and possibly also the user, to specify properties of the cpu
>> like "which rev/patchlevel is it"
>
> I believe I posted patches for that long ago, to clean up the PXA mess a
> little... probably need to be rebased by now.

Ideally rev/patch ought to be properties on the cortex-a9
container object -- there's at least one programmer-visible
change to an SCU register layout between r0 and r2.

-- PMM

Re: [Qemu-devel] Update the id of Vexpress Cortex-A9 from r0p0 to r0p1?

[Mian Yousaf Kaukab]

Hi,

On Sun, Oct 6, 2013 at 2:10 PM, Peter Maydell <peter.maydell@linaro.org> wrote:
>> So what will it take to update the id of Cortex-A9 in qemu from r0p0 to r0p1?
>
> If we're updating, why would we update only to r0p1 and not to the most
> recent rev/patchlevel?

Does ARM provide physical vexpress platform with newer revisions of
A9? If yes, then I
agree we should update to the most recent revision delivered by ARM on
physical vexpress.
If I understand correctly, physical vexpress with A9 r0p0 does not
exist and hence we
have this problem.

BR,
Yousaf

Re: [Qemu-devel] Update the id of Vexpress Cortex-A9 from r0p0 to r0p1?

[Peter Maydell]

On 8 October 2013 05:17, Mian Yousaf Kaukab <yrehan@gmail.com> wrote:
> On Sun, Oct 6, 2013 at 2:10 PM, Peter Maydell <peter.maydell@linaro.org> wrote:
>> If we're updating, why would we update only to r0p1 and not to the most
>> recent rev/patchlevel?
>
> Does ARM provide physical vexpress platform with newer revisions of
> A9? If yes, then I
> agree we should update to the most recent revision delivered by ARM on
> physical vexpress.
> If I understand correctly, physical vexpress with A9 r0p0 does not
> exist and hence we
> have this problem.

vexpress is not the only Cortex-A9 board we support -- we can't base
our decisions about how to model the CPU purely on what is best
for that board.

-- PMM