On 28 October 2014 16:38, Liviu Ionescu <i...@livius.net> 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
