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

[Li Guang <lig.fnst@cn.fujitsu.com>]

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
>
>