> On 01 Jun 2015, at 10:19, Paolo Bonzini <pbonz...@redhat.com> wrote: > > Regarding flash, I'm still curious about some questions I have... > > 1) who initializes flash contents?
the flash region is created with memory_region_init_ram() memory_region_set_readonly() so it behaves like ram, but prevents writes. if -kernel is present, the memory content is loaded from the external image (which is not at all a kernel, as the confusing option implies). if -kernel is not used, but -gdb is used, memory content is loaded by the gdb client, as for any debug session using a jtag/swd. > 2) can the running program modify flash at run-time? if so, how? sure, using vendor specific procedures; each mcu family has a flash control interface. > and > if so, are the writes supposed to stick around from one QEMU invocation > to the next? that would be useful for testing bootloaders, but it is not yet implemented. I guess a command line option to define the path to a file where the flash content will be saved to/loaded from would do the trick. --- for those not familiar with Cortex-M devices, the major use cases for emulating them that I consider are: 1 - as target for debug sessions, replacing a physical board connected via jtag/swd; the 'flash' is written on each debug session, via gdb client commands, passed to qemu in gdb server mode. the 'GNU ARM Eclipse QEMU' plug-in does just that, behaving exactly like the J-Link plug-in or the OpenOCD plug-in. this is generally an interactive session, under user control. the desired integration with GNU ARM Eclipse requires the QEMU emulation of Cortex-M devices to fully support the CMSIS startup code (generally setting the PLL clocks), and one GPIO port for blinking a LED. this will provide a convenient test environment for the projects generated by the GNU ARM Eclipse C/C++ wizards, which generate simple 'blinky' projects. for a nice feedback, the emulator should display a picture of the board, and the LED to turn on and off as a square saturated colour area in the actual LED location. 2 - as a convenient platform for running unit tests; in this case the .elf is loaded via -kernel, full semihosting is enabled, and argv[] are passed to the application; the result of the test is an exit code and an .xml with details about each test case. this is generally a scripted session, running under a continuous integration server, like Hudson/Jenkins, and requires a convenient way to pass semihosting arguments to the application. (the current implementation using the '-semihosting-config arg=' syntax is NOT designed with this kind of ease of use in mind, it is too complicated, it requires a wrapper to pack the arguments, and encourages inconsistent use for arm/mips targets). 3 - as you noticed, there are other use cases, like testing bootloaders, but they are less frequent. regards, Liviu
