qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 8/9] hw/arm/bcm2836: Hardcode correct CPU type


From: Philippe Mathieu-Daudé
Subject: Re: [Qemu-devel] [PATCH 8/9] hw/arm/bcm2836: Hardcode correct CPU type
Date: Wed, 14 Mar 2018 00:16:39 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0

On 03/13/2018 06:09 PM, Peter Maydell wrote:
> On 13 March 2018 at 16:55, Andrew Baumann <address@hidden> wrote:
>>> From: Qemu-devel <qemu-devel-
>>> address@hidden> On Behalf Of Peter
>>> Maydell
>>> Sent: Tuesday, 13 March 2018 08:35
>>>
>>> Now we have separate types for BCM2386 and BCM2387, we might as well
>>> just hard-code the CPU type they use rather than having it passed
>>> through as an object property. This then lets us put the initialization
>>> of the CPU object in init rather than realize.
>>>
>>> Signed-off-by: Peter Maydell <address@hidden>
> 
>>>  static const BCM283XInfo bcm283x_socs[] = {
>>>      {
>>>          .name = TYPE_BCM2836,
>>> +        .cpu_type = ARM_CPU_TYPE_NAME("cortex-a15"),
>>
>> At some point I remember seeing a patch to change this to cortex-a7. Is 
>> there a reason we didn't make that change?
>>
>> (Background: the real Pi2 has an A7. When I first implemented the machine 
>> model there was no A7 emulation in QEMU, so I used the A15 which was the 
>> closest equivalent.)
> 
> Yeah, we should do that. I'd forgotten about that, I think
> things just got lost in the shuffle of having several
> patchsets that tried to change the same things at once.
> 
> I guess the simplest thing is to add a patch at the end of
> the series that fixes the cpu type for bcm2836.

Peter, here is the patch Andrew remembered (maybe can be applied at the
end):
http://lists.nongnu.org/archive/html/qemu-devel/2018-02/msg04286.html

> 
> 
>>> --- a/hw/arm/raspi.c
>>> +++ b/hw/arm/raspi.c
>>> @@ -150,8 +150,6 @@ static void raspi_init(MachineState *machine, int
>>> version)
>>>      /* Setup the SOC */
>>>      object_property_add_const_link(OBJECT(&s->soc), "ram", OBJECT(&s->ram),
>>>                                     &error_abort);
>>> -    object_property_set_str(OBJECT(&s->soc), machine->cpu_type, "cpu-type",
>>> -                            &error_abort);
>>>      object_property_set_int(OBJECT(&s->soc), smp_cpus, "enabled-cpus",
>>>                              &error_abort);
>>>      int board_rev = version == 3 ? 0xa02082 : 0xa21041;
>>
>> What about the default_cpu_type field of MachineClass set in
>> raspi[23]_machine_init? That seems irrelevant now...
> 
> Mmm. It doesn't hurt anything, though.
> 
>> Also, if anyone cares (I don't), we also just lost the ability
>> to override the CPU type of a raspi model.
> 
> Yeah, that's deliberate -- I think that letting the user randomly
> plug nonexistent combinations together just confuses people when
> they don't work. I guess I should call it out in the commit message
> though.
> 
> thanks
> -- PMM
> 



reply via email to

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