qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Liviu Ionescu
Subject: Re: [Qemu-devel] [RFC] extensions to the -m memory option
Date: Mon, 1 Jun 2015 12:23:03 +0300

> On 01 Jun 2015, at 11:53, Paolo Bonzini <address@hidden> wrote:
> 
>> 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.

the internal flash size is fixed and known from the device name (or explicitly 
overwritten by a command line option).

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

ok, thank you, I'll consider it.

however, the desired behaviour is

- the -pflash specifies a file path, no need for size
- when emulation starts, if -pflash is used and the file exists, its content is 
loaded as initial flash content
- when emulation ends, if -pflash is used, the flash content is saved to this 
file
- if the gdb server is used, it must allow for some parts of the flash to be 
overwritten by GDB, for example the bootloader is located either in low or high 
memory, and the rest of the flash is reprogrammed by the debugger with each 
session, the bootloader (and the rest of the flash) remaining persistent 
between sessions.

does the existing -pflash implementation matches this expected use case? 


regards,

Liviu




reply via email to

[Prev in Thread] Current Thread [Next in Thread]