Re: [Qemu-devel] ARM MCU Target Structure Question

[Peter Maydell]

On 15 August 2016 at 05:22, Carl Allendorph
<address@hidden> wrote:
> I'm working on a new microcontroller target (Atmel ATSAM4E) for the
> qemu-system-arm executable. I've successfully setup a machine and created
> some peripherals. I have some questions about how to structure the files
> for contributing this target to the qemu project.
>
> In the current "hw" directory, there seems to be a mashup of MCU/board
> machines, peripherals for these machines, and devices that would
> communicate with these peripherals like I2C or SPI slave devices. There are
> also general definitions for buses like I2C and SPI. There seem to be
> peripherals for certain machines spread over several different directories.
>
> For example, the omap*.c files are defined in the "arm" sub directory, and
> then several of the peripherals are defined in the ssi/i2c/gpio/etc
> directories. This seems inefficient from a development perspective because
> the omap i2c/ssi/gpio peripherals are unlikely to be reused by other MCUs
> or targets (except by derivatives in the OMAP family perhaps).
>
> My preferred way to contribute to the project would be to create a new set
> of directories in "hw/arm" that would have the following hierarchy:
>
>   hw/arm/atmel/
>     - utils/
>     - atsam4/
>       - common/    <-- Common Peripherals in family
>       - atsam4e/   <-- Machine and Peripheral Definitions
>       - atsam4n/
>         ...
>     - atsam3/        <-- Other families in the future?

This is not, as you have noticed, how we choose to structure
our source code. The underlying problem here is that for instance
an OMAP UART device is both (1) a UART and (2) an OMAP SoC
device. We can't put it both in hw/omap and hw/uart, we have to
make a choice. The choice we've picked is that we sort devices
by what they are, so all our UARTs are in hw/char, and so on.
Bus controllers (like I2C controllers or PCI controllers) live
in the directory for that bus type (hw/i2c, hw/pci). Devices
which are slaves which sit on that bus but have some other
function live in the relevant directory for their function
(so a PCI ethernet device lives in hw/net, the lm832x I2C
keyboard device lives in hw/input, and so on).
Top level board models and SoC container models are in hw/arm
(or other architecture subdirectory).

This broadly matches the directory arrangement principles used
by the Linux kernel sources, which is where we've borrowed it from.

PS: OMAP is a very old QEMU board model and does things in a
variety of now-obsolete ways. Looking at a model that's been
contributed more recently (for instance a Xilinx model or one
of the imx boards).

thanks
-- PMM