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
>
