| Message ID | ac853042b91a5ca98cf8f2314716f2a504a66c62.1464201427.git.alistair.francis@xilinx.com |
|---|---|
| State | New |
| Headers | show |
On 25 May 2016 at 19:49, Alistair Francis <alistair.francis@xilinx.com> wrote: > Signed-off-by: Alistair Francis <alistair.francis@xilinx.com> > --- > 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? > + > + <addr> - The address to store the data or the value to set the CPUs PC "to use as the CPU's PC" > + <data> - The value to be written to the addr. The maximum size of the Either "to the address" or "to <addr>". > + data is 8 bytes. We should say whether addresses and data are mandatorily hex, or if decimal is also allowed. > + <data-len> - The length of the data in bytes. This argument must be included > + if the data argument is. > + <data-be> - Set to true if the data to be stored on the guest should be > + written as big endian data. The default is to write little > + endian data. > + <cpu-num> - This will cause the CPU to be reset and the PC to be set to > + the value of addr. > + > +An example of loading value 0x8000000e to address 0xfd1a0104 is: > + -device loader,addr=0xfd1a0104,data=0x8000000e,data-len=4 > + > +Loading Files > +------------- > +The loader device also allows files to be loaded into memory. This can be done > +similarly to setting memory values. The syntax is shown below: > + > + -device loader,file=<file>,addr=<addr>,cpu-num=<cpu-num>,force-raw=<raw> > + > + <file> - A file to be loaded into memory > + <addr> - The addr in memory that the file should be loaded. This is > + ignored if you are using an ELF (unless force-raw is true). > + This is required if you aren't loading an ELF. > + <cpu-num> - This specifies the CPU that should be used. This is an > + optional argument and will cause the CPU's PC to be set to > + where the image is stored. This option should only be used > + for the boot image. Does it actually set the PC to where the image is stored, or does it use the ELF entry point specified in the ELF file? Does this also cause the loader to write via this CPU's address space? (If so, is it possible to load a file via a specific CPU's address space but not set its program counter?) > + <force-raw> - Forces the file to be treated as a raw image. This can be > + used to specify the load address of ELF files. > + > +An example of loading an ELF file which CPU0 will boot is shown below: > + -device loader,file=./images/boot.elf,cpu-num=0 > -- > 2.7.4 > thanks -- PMM
On Thu, Jun 9, 2016 at 10:45 AM, Peter Maydell <peter.maydell@linaro.org> wrote: > On 25 May 2016 at 19:49, Alistair Francis <alistair.francis@xilinx.com> wrote: >> Signed-off-by: Alistair Francis <alistair.francis@xilinx.com> >> --- >> 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. It also is not forbidden in all the checks, so I think it is still worth mentioning. > >> + >> + <addr> - The address to store the data or the value to set the CPUs PC > > "to use as the CPU's PC" Fixed. > >> + <data> - The value to be written to the addr. The maximum size of the > > Either "to the address" or "to <addr>". Fixed. > >> + data is 8 bytes. > > We should say whether addresses and data are mandatorily hex, or if decimal > is also allowed. Both are supported. I have added documentation for the values. > >> + <data-len> - The length of the data in bytes. This argument must be included >> + if the data argument is. >> + <data-be> - Set to true if the data to be stored on the guest should be >> + written as big endian data. The default is to write little >> + endian data. >> + <cpu-num> - This will cause the CPU to be reset and the PC to be set to >> + the value of addr. >> + >> +An example of loading value 0x8000000e to address 0xfd1a0104 is: >> + -device loader,addr=0xfd1a0104,data=0x8000000e,data-len=4 >> + >> +Loading Files >> +------------- >> +The loader device also allows files to be loaded into memory. This can be done >> +similarly to setting memory values. The syntax is shown below: >> + >> + -device loader,file=<file>,addr=<addr>,cpu-num=<cpu-num>,force-raw=<raw> >> + >> + <file> - A file to be loaded into memory >> + <addr> - The addr in memory that the file should be loaded. This is >> + ignored if you are using an ELF (unless force-raw is true). >> + This is required if you aren't loading an ELF. >> + <cpu-num> - This specifies the CPU that should be used. This is an >> + optional argument and will cause the CPU's PC to be set to >> + where the image is stored. This option should only be used >> + for the boot image. > > Does it actually set the PC to where the image is stored, or does it > use the ELF entry point specified in the ELF file? The value in the elf file, I will correct that. > > 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. Thanks, Alistair > (If so, is it possible to load a file via a specific CPU's address space > but not set its program counter?) > >> + <force-raw> - Forces the file to be treated as a raw image. This can be >> + used to specify the load address of ELF files. >> + >> +An example of loading an ELF file which CPU0 will boot is shown below: >> + -device loader,file=./images/boot.elf,cpu-num=0 >> -- >> 2.7.4 >> > > thanks > -- PMM >
On 13 June 2016 at 18:45, Alistair Francis <alistair.francis@xilinx.com> wrote: > On Thu, Jun 9, 2016 at 10:45 AM, Peter Maydell <peter.maydell@linaro.org> wrote: >> On 25 May 2016 at 19:49, Alistair Francis <alistair.francis@xilinx.com> wrote: >>> Signed-off-by: Alistair Francis <alistair.francis@xilinx.com> >>> --- >>> 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
On Mon, Jun 13, 2016 at 10:49 AM, Peter Maydell <peter.maydell@linaro.org> wrote: > On 13 June 2016 at 18:45, Alistair Francis <alistair.francis@xilinx.com> wrote: >> On Thu, Jun 9, 2016 at 10:45 AM, Peter Maydell <peter.maydell@linaro.org> wrote: >>> On 25 May 2016 at 19:49, Alistair Francis <alistair.francis@xilinx.com> wrote: >>>> Signed-off-by: Alistair Francis <alistair.francis@xilinx.com> >>>> --- >>>> 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. Ok, I have done that. > >>> 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? I don't see an easy way to set the address space for the multiple loader functions. Any ideas? Thanks, Alistair > > thanks > -- PMM >
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. + + <addr> - The address to store the data or the value to set the CPUs PC + <data> - The value to be written to the addr. The maximum size of the + data is 8 bytes. + <data-len> - The length of the data in bytes. This argument must be included + if the data argument is. + <data-be> - Set to true if the data to be stored on the guest should be + written as big endian data. The default is to write little + endian data. + <cpu-num> - This will cause the CPU to be reset and the PC to be set to + the value of addr. + +An example of loading value 0x8000000e to address 0xfd1a0104 is: + -device loader,addr=0xfd1a0104,data=0x8000000e,data-len=4 + +Loading Files +------------- +The loader device also allows files to be loaded into memory. This can be done +similarly to setting memory values. The syntax is shown below: + + -device loader,file=<file>,addr=<addr>,cpu-num=<cpu-num>,force-raw=<raw> + + <file> - A file to be loaded into memory + <addr> - The addr in memory that the file should be loaded. This is + ignored if you are using an ELF (unless force-raw is true). + This is required if you aren't loading an ELF. + <cpu-num> - This specifies the CPU that should be used. This is an + optional argument and will cause the CPU's PC to be set to + where the image is stored. This option should only be used + for the boot image. + <force-raw> - Forces the file to be treated as a raw image. This can be + used to specify the load address of ELF files. + +An example of loading an ELF file which CPU0 will boot is shown below: + -device loader,file=./images/boot.elf,cpu-num=0
Signed-off-by: Alistair Francis <alistair.francis@xilinx.com> --- 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