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

[Paolo Bonzini <pbonzini@redhat.com>]

On 01/06/2015 10:30, Liviu Ionescu wrote:
> 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).

In this case, you should use -pflash, not -kernel; it should be a binary
file, not ELF.  -pflash does not have a confusing option
name. :)

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

This can simply be the case where -pflash is not specified.  The flash
is then initialized with zeros.  This is the case where you need to
specify the size.

Assuming this is usually driven from an external program, I honestly do
not find file.size=128K,file=null-co://,snapshot=on too bad, but I
understand how you see that differently.

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

-pflash would give you this for free.

Paolo

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