qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v2 7/9] i.MX: Add i.MX6 SOC implementation.


From: Jean-Christophe DUBOIS
Subject: Re: [Qemu-devel] [PATCH v2 7/9] i.MX: Add i.MX6 SOC implementation.
Date: Fri, 19 Feb 2016 07:32:39 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1

Le 18/02/2016 22:46, Peter Maydell a écrit :
On 18 February 2016 at 20:51, Jean-Christophe DUBOIS
<address@hidden> wrote:
Le 16/02/2016 22:57, Peter Maydell a écrit :

On 16 February 2016 at 21:47, Jean-Christophe DUBOIS
<address@hidden> wrote:

In QEMU, other Cortex A9 (Versatilepb.c, Exynos, Zynq ...) are also setting
has_el3 to false ...

So these generally are the "legacy" platforms which were
added before we ever had EL3 support in QEMU. For them it's hard
to turn the EL3 support on for the board even if in theory
it ought to be on, because we don't know what users are
running on it that we might break. With a new to QEMU board
we have an opportunity to get it right from the start.


OK, so is the "highbank" the only Qemu Cortex A9 board supporting
el3 yet?
Yep. We don't have many A9 boards and most of those we do have
are in the 'legacy' bucket.

-kernel I would expect to work, though, at least if the
only issue is the interrupt controller setup. It seems
worth investigating why it goes wrong.


Well, I can boot uniprocessor (-smp 1) without trouble but if I turn logs on
(guest_errors,unimp) I am getting a lot of

gic_dist_writeb: Bad offset 38x (a few at startup)
Ignoring attempt to switch CPSR_A flag from non-secure world with
SCR.AW bit clear (a lot)
Ignoring attempt to switch CPSR_F flag from non-secure world with
SCR.FW bit clear (a few)
This would only be a problem if your kernel needed to use FIQ,
I think.

It is a standard linux (4.5-rc1) so it should not use FIQ I guess.

Now why is the linux code trying to do things it is not allowed to do in its security level ?

Or would Linux expect the secure world to set these bits before running it?


I am not sure if this is a problem. Do you have some opinion on this?

When I turn SMP (-smp 2 or more), I am unable to complete the boot. As soon
as my secondary cpu is started QEMU will continue to boot "very slowly" but
doesn't get to the linux user prompt overnight.
Does SMP work with EL3 not enabled, or is this a different bug?

If I set has_el3 to false, I can boot the 4 cores without problem. With has_el3 set to true (default value) I am getting the above behavior (boot OK in uniprocessor mode, and misbehaving if -smp >= 2).

JC


thanks
-- PMM





reply via email to

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