Re: [Qemu-devel] [PATCH v4 3/4] hw/arm: add sunxi machine type

[Li Guang]

Andreas Färber wrote:
> Am 29.11.2013 09:06, schrieb Li Guang:
>    
> > Andreas Färber wrote:
> >      
> > > Am 29.11.2013 01:46, schrieb Li Guang:
> > >
> > >        
> > > > Andreas Färber wrote:
> > > >
> > > >          
> > > > > Am 27.11.2013 10:22, schrieb Andreas Färber:
> > > > >
> > > > >            
> > > > > > [...] To my understanding, "sunxi" is the name of a
> > > > > > community effort [1] to clean up and upstream the BSP kernels from
> > > > > > Allwinner, so it sounds as if this was an attempt to write an
> > > > > > emulation
> > > > > > for that kernel family while naming everything "sunxi" when in fact
> > > > > > the
> > > > > > SoCs are called Axx [2] (with A1x = sun4i, A2x = sun5i, A3x = sun6i
> > > > > > but
> > > > > >
> > > > > >
> > > > > >              
> > > > > My interpolation was incorrect: A10 = sun4i, A13 = sun5i, A3x = sun6i,
> > > > > A20 = sun7i
> > > > >
> > > > >            
> > > > > > no literal "sunxi" AFAIK) and boards include Cubieboard, Cubieboard2,
> > > > > > Cubieboard3/Cubietruck [3] and whatever tablets etc. are out there.
> > > > > > (CC'ing Bamvor)
> > > > > >
> > > > > > That's a lesson we learned from the old "prep" machine: Please name
> > > > > > things after real hardware, only then can it later be verified whether
> > > > > > the modeling is actually correct or which changes need to be
> > > > > > performed.
> > > > > >
> > > > > >
> > > > > >
> > > > > >              
> > > > well, sunxi maybe be representation of Axx series,
> > > > but, what's wrong?
> > > >
> > > >          
> > > You're modeling too general IMO and thereby you're creating a
> > > virtual-only machine (despite parallel efforts by Linaro to introduce
> > > mach-virt for that purpose). Please model an actual piece of hardware -
> > > SoC and board - and not something random that happens to run with the
> > > "sunxi" kernel flavor but will leave us puzzled in the future. Should be
> > > pretty easy to avoid.
> > >
> > > My example was qemu-system-ppc -M prep. Today no one knows what hardware
> > > that was supposed to match (possibly none) because there are a number of
> > > different PReP based machines from IBM and Motorola out there; switching
> > > from OpenHack'Ware to OpenBIOS became difficult because among other
> > > things we don't have a device tree dump from a physical machine to
> > > compare to, and Hervé thus set out to create new machines such as 40P
> > > where we actually know which components the hardware contains rather
> > > than which drivers are available in the kernel and happened to have
> > > matching QEMU device implementations at the time.
> > > A slightly similar problem occurred with -M pc, where we now have an
> > > i440fx based one and the new q35 based one. It's easier to abstract
> > > commonalities and share code between different devices/machines than
> > > turning a generic machine/device into a less generic one, in particular
> > > for backwards compatibility for guests, command line and QMP.
> > >
> > > When the difference between two devices is just a value or an offset,
> > > then you can use static properties to set them and have the realize
> > > function take them into account. If the composition tree differs
> > > significantly or if you want to facilitate reuse, then different types
> > > will be needed. Multiple machines can call a shared helper function with
> > > some parameter; examples include PC, Versatile Express and DIGIC.
> > >
> > >
> > >        
> > > > we can't track Axx hardware changes? why?
> > > >
> > > >          
> > > Sorry, I don't get that? The Sunxi, Allwinner and Wikipedia pages all
> > > document some key differences, in particular Cortex-A8 in A10/A13 vs.
> > > Cortex-A7 in A20/A31. Cortex-A7 has MPCore, which drags along some key
> > > differences that cannot easily fit in a single SunxiState SoC device.
> > >
> > >        
> > right, A10/20... seem have similar devices except CPU
> >
> >      
> > > At least from my understanding of Cortex-A9 and Cortex-A15 being much
> > > closer than Cortex-A8, that is. For example, you have your own PIC for
> > > the Cortex-A8 in this series whereas Cortex-A7 will use ARM's GIC and
> > > may be able to reuse the "a15mpcore_priv" composite device.
> > > http://en.wikipedia.org/wiki/List_of_ARM_microprocessor_cores#Designed_by_ARM
> > >
> > >
> > >
> > >        
> > > > and also, this patch-set is also community effort just like
> > > > sunxi in linux kernel.
> > > >
> > > >          
> > > My whole point is, try to design the model forward from hardware and
> > > less backwards from kernel. Whether it's sun4i or A10 is less relevant.
> > > Kernels may contain bugs. Hardware doesn't change except for new revs,
> > > but definitely not depending on who writes a kernel to run on it. :)
> > >
> > >
> > >        
> > of course, I am aiming to emulate the real hardware,
> > so name is not the problem, right?
> >      
> It is. The x in sunxi appears to be a wildcard.
>
> Quoting http://linux-sunxi.org/Main_Page:
> "sunxi represents the family of ARM SoC [...] made by Allwinner Tech."
>
> The Boxship F20 is named as "sun3i", so it's even ARM9, Cortex-A8 and
> Cortex-A7 all within that family. That goes beyond what we can model by
> some revision property on a "sunxi" device or with -cpu, and we cannot
> today create some deep detail device such as MPCore and wire that up to
> containing devices. You can only instantiate devices from the command
> line that sit on a bus that supports automatic wiring-up based on device
> properties and knowledge of peers on the bus. In particular you cannot
> initialize IRQs or map MMIO MemoryRegions from -device for
> SysBusDevices, that's a repeating topic really, and we already had one
> KVM conference call on that topic with no solution emerging. Otherwise
> you could use -M none. I'm not writing lengthy replies here for fun!
>
> Please replace "sunxi" with a concrete board name on machine level
> (e.g., "gooseberry", "cubieboard") and with a concrete SoC name on SoC
> level, whether "sun4i", "sun4i-a10", "allwinner-a13" or anything unique,
> so that your series can later be extended with additional SoC family
> members and/or boards with more than just the SoC on it.
>
>    

OK, let me change and re-post.
Thanks!

> > > > > > A practical aspect of modeling SoCs correctly is that they can more
> > > > > > easily be reused across boards or modules, and you don't need to mess
> > > > > > with machine-level cpu_model if you have a fixed SoC-CPU mapping.
> > > > > >
> > > > > >
> > > > > >              
> > > > modeling SoC is good, but
> > > > sorry, I can't assure that fixed mapping.
> > > >
> > > >          
> > > See above. A10 / sun4i =>   Cortex-A8, that's fixed, and then you can
> > > properly embed the ARMCPU in an A10State/Sun4iState without pointer and
> > > using object_initialize().
> > >
> > > It is your approach of a single "sunxi" machine and SunxiState that's
> > > interfering with a fixed mapping AFAICT. Otherwise you'll need to
> > > explain more verbose why the mapping is not assured, please.
> > >
> > >        
> > I mean, e.g. A10 and A13 are different only on HDMI-transmitter and
> > SATA-controller,
> > but we have to have Sun4iState, and Sun5iState, I think.
> >      
> Without knowing the hardware details, that sounds okay to me.
>
> Alternatively name it after the one that's used on the board (A10) and
> when someone actually needs the A13 then they can just derive a new type
> with no functional changes. If they have, e.g., different MIDR values
> then different types would be good for lack of property to set it. But
> type name and struct name obviously don't need to match; you could even
> use multi-level inheritance to model such a tree with an abstract
> "sun4i" device and non-abstract A10 and A13 devices.
>
>    
> > what I design is:
> > we have a sunxi series as a machine, then
> > for sunx4i, we specify -M sunxi -cpu cortex-a8 -device x1 ...
> > for sunx5i, we specify -M sunxi -cpu cortex-a8 -device x2 ...
> > for sunx7i, we specify -M sunxi -cpu cortex-a7 -devcie x3 ...
> > for cubieboard, we specify -M sunxi -cpu -cortex-a8 -device x1 -device
> > p1 ...
> >      
> And that is exactly what I am objecting to. For the Midway board we
> asked the same change (there "Highbank" is a codename but it is unique
> in referring to ECX-1000 model with Cortex-A9, with "Midway" being
> ECX-2000 with Cortex-A15 [*] and thus -cpu cortex-a15 not working well,
> cf. list archives).
> Your prescribed use of -cpu argument interferes with my QOM/CPU
> refactorings, with board vs. SoC layering and makes it more difficult
> for the user. Your modeling seems centered on testing flavors of the
> sunxi kernel that you possibly work on, whereas I am asking you to model
> a board and then test that the intended kernel flavor runs on it.
>
> The cpu_model string determines the type of the object to be
> instantiated, plus possibly optional properties if we manage to go with
> some form of generalization as proposed by Alexey. You cannot easily
> pass all that through from machine to device level. Therefore the
> recommendation is to have a SoC device where the CPU does not change
> except for setting properties to enable/disable features or set reset
> values etc. and to ignore -cpu on the command line. If we need to
> instantiate the CPU during realization due to a typename property, then
> the user will have no chance to inspect or tweak the CPU cores via QMP.
>
> If someone wants to volunteer to summarize or link this on the
> QOMConventions Wiki page that would be appreciated BTW. :)
>
> [*] http://www.calxeda.com/products/
>
>    
> > > QOM uses a strict composition model. If you choose the physical board
> > > you have, say a Gooseberry board, then modeling should be so that we use
> > > qemu-system-arm -M gooseberry (without -cpu cortex-a8)
> > > and /machine has-a child<allwinner-a10>   "a10"
> > >                      which in turn has-a child<cortex-a8-arm-cpu>   "cpu".
> > > -M cubieboard and -M marsboard can then all reuse the allwinner-a10 SoC
> > > device, and in the future you can then tweak CPU properties via QMP
> > > after TypeInfo::instance_init and before DeviceClass::realize.
> > > -M cubieboard2 /machine by contrast has-a child<allwinner-a20>   "a20"
> > >                           which has-a child<cortex-a7-arm-cpu>   "cpu[0]",
> > >                                 has-a child<cortex-a7-arm-cpu>   "cpu[1]".
> > >
> > > Like I said below, Peter Maydell should be able to guide you in more
> > > detail for the exact naming and composition.
> > >        
> Regards,
> Andreas
>
>