qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 3/9] arm: add missing v7 cp15 registers


From: Mark Langsdorf
Subject: Re: [Qemu-devel] [PATCH 3/9] arm: add missing v7 cp15 registers
Date: Wed, 21 Dec 2011 10:37:59 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0

On 12/20/2011 01:48 PM, Peter Maydell wrote:
> On 20 December 2011 19:10, Mark Langsdorf <address@hidden> wrote:
>> diff --git a/target-arm/helper.c b/target-arm/helper.c
>> index 816c4c4..37110bc 100644
>> --- a/target-arm/helper.c
>> +++ b/target-arm/helper.c
>> @@ -2197,6 +2197,13 @@ uint32_t HELPER(get_cp15)(CPUState *env, uint32_t
>> insn)
>>              * 0x200 << ($rn & 0xfff), when MMU is off.  */
>>             goto bad_reg;
>>         }
>> +        if (ARM_CPUID(env) == ARM_CPUID_CORTEXA9) {
>> +            switch (crm) {
>> +            case 0:
>> +                return env->cp15.c15_scubase;
>> +            }
>> +            goto bad_reg;
>> +        }
> 
> This is underdecoded: the A9 has two registers in c15,c0:
> CRn     Op1     CRm     Op2     Name
> 15      0       c0      0       Power Control Register
> 15      4       c0      0       Configuration Base Address
> 
> I'm guessing you're after the Configuration Base Address register.
> (please call the struct name something vaguely relating to the
> official register name, incidentally.)

Apparently it's called scubase in the Linux code, but I'll
fix the name for qemu.

>>         return 0;
>>     }
>>  bad_reg:
> 
> This commit leaves the register with a reset value of 0, which
> isn't right (we only implement A9MP, not A9UP, so the reset value
> should be settable by the board at init time somehow depending
> where the a9mpcore_priv device is mapped. Not sure what the
> cleanest way to do that is.)

I can add a DEFINE_PROP_UINT32 to a9mpcore_priv, which would give
anyone who wants to set the property an easy way to do so. I'm
not sure how to hook the a9mpcore_priv to the CPUARMState, though.
They don't appear to reference each other.

--Mark Langsdorf
Calxeda, Inc.



reply via email to

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