qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v5 3/7] arm: add dummy v7 cp15 config_base_regis


From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH v5 3/7] arm: add dummy v7 cp15 config_base_register
Date: Wed, 4 Jan 2012 16:47:21 +0000

On 4 January 2012 16:32, Mark Langsdorf <address@hidden> wrote:
> On 01/04/2012 08:32 AM, Peter Maydell wrote:
>> On 29 December 2011 16:19, Mark Langsdorf <address@hidden> wrote:
>>> Add a cp15 config_base_register that currently defaults to 0.
>>> After the QOM CPU support is added, the value will be properly
>>> set to the periphal base value.
>>>
>>> Signed-off-by: Mark Langsdorf <address@hidden>
>>> Reviewed-by: Peter Maydell <address@hidden>
>>
>> I need to revoke this Reviewed-by: because...
>>
>>> @@ -2111,6 +2111,20 @@ 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:
>>> +                /* The config_base_address should hold the value of
>>> +                 * the peripheral base. ARM should get this from a CPU
>>> +                 * object property, but that support isn't available in
>>> +                 * December 2011. Default to 0 for now and board models
>>> +                 * that care can set it by a private hook */
>>> +                if ((op1 == 4) && (op2 == 0)) {
>>> +                    return env->cp15.c15_config_base_address;
>>> +                }
>>> +            }
>>> +            goto bad_reg;
>>> +        }
>>>         return 0;
>>
>> this breaks booting on vexpress, which complains
>> qemu: fatal: Unimplemented cp15 register read (c15, c0, {0, 1})
>> because we're now barfing on all the other c15 registers which we
>> used to read as zero.
>
> Fair enough. Can I just resubmit this one patch or do you want
> the entire series?

Just resubmit this one as a single patch -- it has to go through my target-arm
tree rather than arm-devs anyway so if you resent the series I'd just have
to break it apart. (As you may have noticed I've put some of the other
patches into an arm-devs pullreq.)

-- PMM



reply via email to

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