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

[Liviu Ionescu]

On 28 Oct 2014, at 17:38, Peter Maydell <address@hidden> wrote:

> It is simply not possible to avoid being specific here. QEMU
> insists that you say which machine model you want to run on,
> and the Cortex-M3 CPU itself does not define all the properties
> of a machine.
> 
> If your test code really restricts itself to just the functionality
> in the core CPU then it should work fine on one of our
> existing M3 models. I don't think it makes sense to try
> to have a "generic M3" board in QEMU.

from the point of view of QEMU, you are probably right.

from the point of view of the build/debug processes, things are a bit different.

when you create a new project, you usually assign a device to this project, and 
this device definition auto-magically configures many other build configuration 
details, for example defines the CMSIS headers to be used, defines the memory 
map, the hardware initialisations and so on.

similarly, when you create a debug configuration, the same device name is 
passed to the (J-Link) debugger, and the debugger knows how to connect via 
jtag/swd and how to write the flash.

(the above apply to GNU ARM Eclipse plug-ins, but should be similar to most 
development environments).


assuming the cortex-m emulation is complete, ideally the same configuration 
used to create a physical (J-Link) debug configuration should be used to create 
an emulated (qemu) debug configuration.

however this is not that easy, since some/most peripherals are not available, 
so it is preferable to not allow the application to access the CMSIS peripheral 
definitions, which means it is recommended to not use the same build 
configuration as for physical devices, but one tailored for emulation.

I checked the ARM CMSIS definitions and they provide some more or less generic 
definitions, for example they provide the device names ARMCM0, ARMCM0P, ARMCM3, 
ARMCM4, etc.

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.

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

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 and then add drivers for these virtual devices, to have 
a convenient test platform for TCP/IP stacks, USB stacks, etc.

for this latest case it is obvious that the emulation will not match any 
physical device, since it might get implemented with semihosting like 
technologies, and custom device names (like QEMUCM3, for example) would be a 
more appropriate solution.

---

to conclude, from the Eclipse plug-ins point of view, I would prefer to build 
projects targeted for more or less generic devices like ARMCM3 (possibly 
QEMUCM3, after adding virtual devices) to run them on QEMU, instead of 
targeting them to any specific device (like Luminary or STM).

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

---

there are many things to discuss related to the integration of an emulator in a 
development suite, and on the usability of such a solution, and I'm convinced 
the experience of the developers on this list is amazing, unfortunately up to 
now it was not fully used for helping those working with Cortex-M devices.

regards,

Liviu