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

[Peter Crosthwaite]

On Mon, Jun 1, 2015 at 1:53 AM, Paolo Bonzini <address@hidden> wrote:
>
>
> 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. :)
>

You still want to be able to use elf using a proper elf load process
even if the target memory is a persistent flash. These micros tend to
have small memory-mapped executable flashes so from a debug and
programming model that really look and feel like RAM and should be
usable by -kernel.

If all we are worried about the name of -kernel can we give it an alias?

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

You should define size to match the board and part with either an
error condition or padding policy. Truncating the flash to something
smaller than the part is trap for users. Perhaps something like:

"WARNING: block device /foo/bar/blah.bin is smaller than flash for STMXXXXX"

Semi-related, I have had problems in the past with users bringing
small SD card images to QEMU and falling over because the driver only
support SDHC (requiring 2GB+ block devices to activate over SDSC).

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

You could support both. -plfash and -kernel, the latter trumping the
former, to emulate a JTAG blobbing in an elf to persistent flash. All
with a unified interface for loading an elf in the first place.
arm_load_kernel doesn't (or shouldn't) really care where or what type
of memory it loads to, so if told to load to the flash this should be
ok.

Use cases:

-kernel alone can load software to either RAM or flash from elf or RAW
image. Handles all build-and-debug flows
-pflash can test realistic boot from raw flash image. Useful for late
stage development image testing
neither is used when using a pure gdb flow
both is used when developing apps that interact with flash data
(include apps that are hosted on the flash itself!).

Regards,
Peter

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