Re: [Qemu-devel] Better Cortex-M support?

[Peter Maydell]

On 28 October 2014 16:38, Liviu Ionescu <address@hidden> wrote:
> I'm not sure what the QEMU definition of '-machine' stands for, a device
> or a board, but I think that the ARM definitions are good candidates for
> QEMU emulation names.

-machine specifies a board name. We don't care how you build the binary
for the board or what library you choose to use for hardware abstraction.

> once the core Cortex-M emulation is fully functional, it should be
> easier to add support for specific devices, by configuring some of
> the parameters (flash/ram, add some peripherals, etc).

QEMU doesn't conveniently support runtime flexible specification
of what is present in an emulated board (beyond very basic things
like "how much RAM"). What the .c file in the QEMU sources defines
is what you get.

> going with the analyse even further, from the development point of
> view it would be useful to define some virtual hardware, similar to
> the devices defined in virtual machines, like VMware, for example
> virtual Ethernet devices, virtual USB, virtual USART, etc

You could maybe do this with virtio-mmio. I'm reluctant to define
a virtual board for M profile though -- we're having enough trouble
managing the configuration for the "virt" board we added for A
profile KVM use. Modelling real hardware is much more manageable
because there is a defined thing you're trying to match.

> similarly, if adding a board is mandatory, I would add definitions
> to refer to devices like ARMCM3, instead of specific boards with
> specific devices.

I had a quick look at the CMSIS headers for ARMCM3 and they
look to me like they're defining information for a specific
board (probably an fpga or dev board from ARM for the Cortex-M3):
there's information about UARTs, external interrupts, FPGA
devices, and so on.

thanks
-- PMM