Re: [Qemu-devel] RFC: raspberry pi / pi2 / Windows-on-ARM support

[Andrew Baumann]

Hi Peter (et al),

I am working on refactoring the Pi support code as you suggested. I have split 
the Pi SOCs into separate objects (bcm2835 and bcm2836) which both instantiate 
a third common bcm2835_peripherals device that in turn contains all the common 
devices. I have also switched the code to use object properties rather than 
global variables to communicate state where devices interact with each other.

Before I go further, I wanted to ask a couple of high-level questions about the 
desired code style for new devices.

1. Must every new device have a header file that declares its private state 
struct, or is it ok to keep those in the C file for leaf devices and refer to 
them through opaque pointers?
2. What's the status of the sysbus API? It is obviously a fairly thin layer 
over qdev/qom, but it's not clear whether the APIs are deprecated. Can new code 
instantiate children of TYPE_SYS_BUS_DEVICE and use the irq/mmio export 
features it provides, or should we be sticking only to lower-level (qdev?) 
APIs? If so, what's the right way to export interrupts and mmio space from a 
device?
3. Similarly, is using SysBusDeviceClass.init ok, or should we be using 
DeviceClass.realize? In general, what's the guidance on what belongs in object 
init vs. the realize method?
4. I have some property values (e.g. video ram size) that are set in the 
top-level machine definition code (raspi.c), and need to pass down through 
several layers of abstraction (e.g. raspi.c declares the machine class which 
instantiates a bcm2836 object which in turn instantiates bcm2835_peripherals, 
which in turn instantiates bcm2835_fb). Defining properties at each level just 
to pass these along is painful/fragile. Is there a programmatic way to have 
properties that are defined globally and passed through, roughly equivalent to 
-global on the command line? Is it acceptable to use that?

Forgive me if there is documentation/guidance on this stuff already -- I didn't 
manage to find very much.

If anyone wants to take a look, my working tree is at:
https://github.com/0xabu/qemu/tree/raspi

The relevant files are:
 hw/arm/bcm2835.c                     |   92 +++
 hw/arm/bcm2835_peripherals.c         |  368 ++++++++++++
 hw/arm/bcm2836.c                     |  149 +++++
 hw/arm/raspi.c                       |  228 ++++++++
 hw/char/bcm2835_aux.c                |  250 ++++++++
 hw/display/bcm2835_fb.c              |  427 ++++++++++++++
 hw/dma/bcm2835_dma.c                 |  366 ++++++++++++
 hw/intc/bcm2835_ic.c                 |  248 ++++++++
 hw/intc/bcm2836_control.c            |  373 ++++++++++++
 hw/misc/bcm2835_mphi.c               |  176 ++++++
 hw/misc/bcm2835_power.c              |  113 ++++
 hw/misc/bcm2835_property.c           |  417 +++++++++++++
 hw/misc/bcm2835_sbm.c                |  310 ++++++++++
 hw/misc/bcm2835_vchiq.c              |  114 ++++
 hw/sd/bcm2835_emmc.c                 |  844 +++++++++++++++++++++++++++
 hw/timer/arm_timer.c                 |   39 ++
 hw/timer/bcm2835_st.c                |  201 +++++++
 hw/timer/bcm2835_timer.c             |  242 ++++++++
 hw/usb/bcm2835_usb.c                 |  655 +++++++++++++++++++++
 hw/usb/bcm2835_usb_regs.h            | 1061 ++++++++++++++++++++++++++++++++++
 include/hw/arm/bcm2835.h             |   31 +
 include/hw/arm/bcm2835_arm_control.h |  481 +++++++++++++++
 include/hw/arm/bcm2835_mbox.h        |   14 +
 include/hw/arm/bcm2835_peripherals.h |   35 ++
 include/hw/arm/bcm2836.h             |   34 ++
 include/hw/arm/raspi_platform.h      |  160 +++++
 include/hw/display/bcm2835_fb.h      |   29 +

Thanks,
Andrew