Re: [Qemu-devel] [RFC] extensions to the -m memory option

[Liviu Ionescu]

> On 01 Jun 2015, at 10:19, Paolo Bonzini <address@hidden> 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