qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v3 00/10] arm: add ast2500 support


From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH v3 00/10] arm: add ast2500 support
Date: Fri, 12 Aug 2016 10:22:28 +0100

On 12 August 2016 at 09:38, Cédric Le Goater <address@hidden> wrote:
> On 08/11/2016 12:47 PM, Peter Maydell wrote:
>> On 2 August 2016 at 18:15, Cédric Le Goater <address@hidden> wrote:
>>>     On the AST2500, I am still having a little issue under uboot which
>>>     sets the vbar doing :
>>>
>>>         mcr     p15, 0, r0, c12, c0, 0  /* Set VBAR */
>>>
>>>     and this is trapped as an undefined instruction by qemu.
>>>
>>>     Looking at hw/arm/helper.c, the VBAR register seems to be defined
>>>     only for feature ARM_FEATURE_V7 (v7_cp_reginfo). The AST2500 SoC
>>>     uses a arm1176 which defines ARM_FEATURE_EL3 which gives us a
>>>     VBAR_EL3.  According to th specs, the arm1176jzf-s has a Vector
>>>     Base Address Register. So am I missing something in the board
>>>     definition or is uboot being too optimistic on the cpu features ?
>>>     This is confusing for me, some direction would be welcomed :)
>>
>> This looks like a bug in helper.c -- we originally added the VBAR
>> definition as a bit of a hack since it's only supposed to exist
>> in CPUs with the security extensions and at the time we didn't
>> implement those at all. It should definitely exist in the 1176
>> too, so we should move the definition around somewhere so it does.
>> (The 1176 is the only non-v7 CPU with security extensions support,
>> which is why it got missed I suspect.)
>
> OK. I will give it a try in a standalone patch. Is there a scenario
> I could use to catch possible regression on other cpus ?

I don't have any test cases to hand that I know use VBAR, no.

thanks
-- PMM



reply via email to

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