Re: [Qemu-arm] [Qemu-devel] [PATCH] BCM2837 and machine raspi3

[bzt bzt]

Hi Andrew!

On Tue, Oct 24, 2017 at 6:44 PM, Andrew Baumann <address@hidden> 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