qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH arm-devs v2 5/8] arm/highbank: Fix CBAR intialis


From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH arm-devs v2 5/8] arm/highbank: Fix CBAR intialisation
Date: Fri, 29 Nov 2013 08:16:47 +0000

On 28 November 2013 23:55, Peter Crosthwaite
<address@hidden> wrote:
> On Fri, Nov 29, 2013 at 5:34 AM, Peter Maydell <address@hidden> wrote:
>> More significantly, this will break midway, because
>> cortex-a15 doesn't have this property. Fortunately, the
>> actual A15 does have a CBAR register so you can just
>> add a patch to set the feature bit for it.
>>
>
> Ok will fix - thanks. Should I just feature CBAR for all the CPU
> families you listed in v1 discussion?

I'm pretty sure the only two cores with CBAR that we
implement are A15 and A9. NB that the permissions on
the two registers are not the same, though -- check the
TRMs. (A15's is always r/o).

>> Caution, this means our semantics for reset-cbar
>> are "actual reset value of register", which is not
>> the same as "base address of peripherals",
>
> That was the intended semantic.
>
>> because
>> for A15 the register has
>>  [31:15] bits 31:15 of base-addr
>>  [14:8] reserved, zero
>>  [7:0] bits 39:32 of base-addr
>>
>
> Yes, so I i'm still of the opinion that this stuff is the
> responsibility of MPCore not ARM_CPU. Ideally, we move the ARM cpus
> into MPCore. Then boards set periphbase of mpcores and mpcores set
> CBARs. Keeps CPUs unaware of periphbase mangling complications like
> this. And keeps boards unaware of CBARs.

I'm in favour of eventually moving the cores
themselves into the *mpcore containers, though
I'm not entirely sure that the CBAR setting and
periphbase locations are a single setting on real
hardware config (as opposed to two different
settings that are supposed to be the same).

-- PMM



reply via email to

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