qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v7 3/3] docs: Add a generic loader explanation d


From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH v7 3/3] docs: Add a generic loader explanation document
Date: Mon, 13 Jun 2016 18:49:35 +0100

On 13 June 2016 at 18:45, Alistair Francis <address@hidden> wrote:
> On Thu, Jun 9, 2016 at 10:45 AM, Peter Maydell <address@hidden> wrote:
>> On 25 May 2016 at 19:49, Alistair Francis <address@hidden> wrote:
>>> Signed-off-by: Alistair Francis <address@hidden>
>>> ---
>>> V6:
>>>  - Fixup documentation
>>> V4:
>>>  - Re-write to be more comprehensive
>>>
>>>  docs/generic-loader.txt | 54 
>>> +++++++++++++++++++++++++++++++++++++++++++++++++
>>>  1 file changed, 54 insertions(+)
>>>  create mode 100644 docs/generic-loader.txt
>>>
>>> diff --git a/docs/generic-loader.txt b/docs/generic-loader.txt
>>> new file mode 100644
>>> index 0000000..effb244
>>> --- /dev/null
>>> +++ b/docs/generic-loader.txt
>>> @@ -0,0 +1,54 @@
>>> +Copyright (c) 2016 Xilinx Inc.
>>> +
>>> +This work is licensed under the terms of the GNU GPL, version 2 or later.  
>>> See
>>> +the COPYING file in the top-level directory.
>>> +
>>> +
>>> +The 'loader' device allows the user to load multiple images or values into
>>> +QEMU at startup.
>>> +
>>> +Loading Memory Values
>>> +---------------------
>>> +The loader device allows memory values to be set from the command line. 
>>> This
>>> +can be done by following the syntax below:
>>> +
>>> +    -device loader,addr=<addr>,data=<data>,data-len=<len>
>>> +    -device loader,addr=<addr>,cpu-num=<cpu-num>
>>> +
>>> +NOTE: It is also possible to mix the commands above, e.g. include the 
>>> cpu-num
>>> +      argument with the data argument.
>>
>> Is that actually useful?
>
> Sometimes it is. You can use it to set data in other CPU address spaces.

Right, but do you want it to do that and also set the PC of the other CPU
at the same time? That's the bit that doesn't make sense to me.
I think we should keep "set PC" and "write to memory" orthogonal,
rather having an option combo that does both on the same data.

> It also is not forbidden in all the checks, so I think it is still
> worth mentioning.

Better to forbid combinations that don't make sense rather than document them.

>> Does this also cause the loader to write via this CPU's address space?
>
> The file loading does not follow the CPUs address spaces. It only sets
> the CPUs program counter.
>
> The <data> writes follow the CPUs address spaces though.

That's irritatingly inconsistent. Can we have both use the CPU's
address space, please?

thanks
-- PMM



reply via email to

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