Dear Andrew,
A month passed, and the maintainers didn't gave a damn about raspi3 support
in qemu. Any ideas?
On Wed, Oct 25, 2017 at 10:52 AM, bzt bzt <bztem...@gmail.com> wrote:
> Hi Andrew!
>
> On Tue, Oct 24, 2017 at 6:44 PM, Andrew Baumann <
> andrew.baum...@microsoft.com> wrote:
> [...]
>
>> I see. The address space size sounds like it would affect the SoC
>> (although is there really 40 bits of usable physical address space beyond
>> the core?). If it's like pi2, however, the wifi and BT are both behind USB,
>> so that would be handled more naturally in the board model (raspi.c) than
>> the SoC.
>>
> [...]
>
>>
>> Right, but as I wrote above if those devices are behind USB that's not
>> part of the SoC model, and belongs in the board logic. If "more registers"
>> just refers to the CPU, then that's irrelevant. If there are really more
>> devices / device registers on the system bus, then that calls for a deeper
>> change in the SoC model and perhaps a new implementation.
>>
>
> True, but even if it's behind USB, somehow the USB system should know
> which one to emulate. Originally for clear code I was thinking along the
> line of
> if( TYPE(soc) == TYPE_BCM2836 ) {
> ...
> }
> if( TYPE(soc) == TYPE_BCM2837 ) {
> ...
> }
> when the two are not separated and shares common code. But we are not
> there yet, let's focus on one step at a time :-)
>
> [...]
>
>> I'm more open to the need for evolution in the machine init logic
>> (raspi.c), so splitting there makes more sense to me than in bcm2836/7.
>>
>> I see you just posted another patch. FWIW, this isn't quite what I was
>> proposing -- rather than have bcm2736.c take a version number that is 2 or
>> 3, I would just pass it the CPU model to instantiate. But at this point I
>> think it's best waiting for one of the Qemu maintainers to chime in and see
>> what they prefer.
>>
>
> Again you are right. But I saw Alistair's patch
> https://lists.gnu.org/archive/html/qemu-devel/2017-10/msg04153.html When
> it makes through, the bcm2836.c could simply use mc->default_cpu_type and
> would be no need for anything else in BCM2836State, neither a version nor a
> CPU model.
>
> Okay, for now let's see what the maintainers prefer!
>
> Cheers,
> bzt
>
>
>> Andrew
>>
>
>
