[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] RFC: raspberry pi / pi2 / Windows-on-ARM support
From: |
Andrew Baumann |
Subject: |
Re: [Qemu-devel] RFC: raspberry pi / pi2 / Windows-on-ARM support |
Date: |
Wed, 25 Nov 2015 00:00:01 +0000 |
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
- [Qemu-devel] RFC: raspberry pi / pi2 / Windows-on-ARM support, Andrew Baumann, 2015/11/17
- Re: [Qemu-devel] RFC: raspberry pi / pi2 / Windows-on-ARM support, Stefan Weil, 2015/11/17
- Re: [Qemu-devel] RFC: raspberry pi / pi2 / Windows-on-ARM support, Peter Crosthwaite, 2015/11/18
- Re: [Qemu-devel] RFC: raspberry pi / pi2 / Windows-on-ARM support, Andrew Baumann, 2015/11/18
- Re: [Qemu-devel] RFC: raspberry pi / pi2 / Windows-on-ARM support, Peter Crosthwaite, 2015/11/18
- Re: [Qemu-devel] RFC: raspberry pi / pi2 / Windows-on-ARM support,
Andrew Baumann <=
- Re: [Qemu-devel] RFC: raspberry pi / pi2 / Windows-on-ARM support, Peter Crosthwaite, 2015/11/25
- Re: [Qemu-devel] RFC: raspberry pi / pi2 / Windows-on-ARM support, Peter Maydell, 2015/11/25
- Re: [Qemu-devel] RFC: raspberry pi / pi2 / Windows-on-ARM support, Andrew Baumann, 2015/11/25
- Re: [Qemu-devel] RFC: raspberry pi / pi2 / Windows-on-ARM support, Paolo Bonzini, 2015/11/29
- Re: [Qemu-devel] RFC: raspberry pi / pi2 / Windows-on-ARM support, Andrew Baumann, 2015/11/25
- Re: [Qemu-devel] RFC: raspberry pi / pi2 / Windows-on-ARM support, Peter Crosthwaite, 2015/11/26
- Re: [Qemu-devel] RFC: raspberry pi / pi2 / Windows-on-ARM support, Andrew Baumann, 2015/11/26