Hi Andrew! [...]
> > In that case, IIRC my high-level suggestion was to either parameterise > bcm2836 to take a CPU model string, or else move the CPU creation out of > bcm2836.c into the board file. From what I've understood thus far about > pi3, it does not seem necessary to have a separate bcm2837 implementation. > I suspect at that point the patch would be small enough that it didn't > require further splitting. > Yes, I agree. I've provided a parameterised version on Oct 24, which does not have a separate bcm2837 implementation. Is that patch ok? Or should I wait for Alistair's patch ( https://lists.gnu.org/archive/html/qemu-devel/2017-10/msg04153.html)? I would prefer the latter, if I may, and I'm willing to rewrite raspi3 support using the CPU model string in mc->default_cpu_type introduced by that patch. (Although I have a question. I'm not sure what's the preferred way to get MachineClass* object in bcm2836. Use a MachineState* cast on it's Object* argument with MACHINE_GET_CLASS() or should I use the parameterless qdev_get_machine() instead?) > > PS: if you send a new patch, send it as a new top level > > thread -- if you send it as a reply/followup to the > > first patch it's liable to not be noticed. > > Please also CC me on the new patch as I am not very reliable at monitoring > qemu-devel. > Noted :-) Thank you for your help! I'm sure qemu users appreciate it very much! bzt > > Thanks! > Andrew >