On Tue, Jul 12, 2016 at 9:31 AM, Peter Maydell <peter.mayd...@linaro.org> wrote: > On 2 July 2016 at 02:07, Alistair Francis <alistair.fran...@xilinx.com> wrote: >> Signed-off-by: Alistair Francis <alistair.fran...@xilinx.com> >> --- >> V8: >> - Improve documentation >> V6: >> - Fixup documentation >> V4: >> - Re-write to be more comprehensive >> >> docs/generic-loader.txt | 60 >> +++++++++++++++++++++++++++++++++++++++++++++++++ >> 1 file changed, 60 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..34684fc >> --- /dev/null >> +++ b/docs/generic-loader.txt >> @@ -0,0 +1,60 @@ >> +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> >> + >> + <addr> - The address to store the data or the value to use as the >> + CPU's PC. >> + <data> - The value to be written to the address. 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. >> + >> +For all values both hex and decimal values are allowed. By default the >> values >> +will be parsed as decimal. To use hex values the user should prefix the >> number >> +with a '0x'. >> + >> +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. > > For an ELF file we use the start address specified in the ELF header, right?
Yes, I have specified that now in the docs. > > We also end up writing to that CPU's address space, but only for ELF files. Yes, this will apply to all images in the next version. > >> + <force-raw> - Forces the file to be treated as a raw image. This can be >> + used to specify the load address of ELF files. > > Presumably it results in the ELF file being dumped into memory as a raw > image without any regard to what the segment headers say about loading, > offsets, etc? Correct, I have made that more clear. Thanks, Alistair > >> + >> +For all values both hex and decimal values are allowed. By default the >> values >> +will be parsed as decimal. To use hex values the user should prefix the >> number >> +with a '0x'. >> + >> +An example of loading an ELF file which CPU0 will boot is shown below: >> + -device loader,file=./images/boot.elf,cpu-num=0 > > thanks > -- PMM >