On 28 Oct 2014, at 17:38, Peter Maydell <peter.mayd...@linaro.org> 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
