From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54041) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bpqUt-000288-29 for qemu-devel@nongnu.org; Fri, 30 Sep 2016 01:36:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bpqUo-0000EO-Re for qemu-devel@nongnu.org; Fri, 30 Sep 2016 01:36:34 -0400 Received: from mx1.redhat.com ([209.132.183.28]:43778) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bpqUo-0000EE-Hy for qemu-devel@nongnu.org; Fri, 30 Sep 2016 01:36:30 -0400 From: Markus Armbruster References: <0c4600f5c922569a57f4e9a9f1b6b4b5469b2a4c.1475102513.git.alistair.francis@xilinx.com> <871t03jbxh.fsf@dusky.pond.sub.org> Date: Fri, 30 Sep 2016 07:36:26 +0200 In-Reply-To: (Alistair Francis's message of "Thu, 29 Sep 2016 17:25:20 -0700") Message-ID: <874m4yx82t.fsf@dusky.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Qemu-devel] [PATCH v12 2/2] docs: Add a generic loader explanation document List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alistair Francis Cc: Peter Maydell , "qemu-devel@nongnu.org Developers" , Peter Crosthwaite , Christopher Covington , Paolo Bonzini Alistair Francis writes: > On Thu, Sep 29, 2016 at 2:24 AM, Markus Armbruster wrote: >> Alistair Francis writes: >> >>> Signed-off-by: Alistair Francis >>> Reviewed-by: Peter Maydell >>> --- >>> V11: >>> - Fix corrections >>> V10: >>> - Split the data loading and PC setting >>> V9: >>> - Clarify the image loading options >>> V8: >>> - Improve documentation >>> V6: >>> - Fixup documentation >>> V4: >>> - Re-write to be more comprehensive >>> >>> docs/generic-loader.txt | 81 +++++++++++++++++++++++++++++++++++++++++++++++++ >>> 1 file changed, 81 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..d1f8ce3 >>> --- /dev/null >>> +++ b/docs/generic-loader.txt >>> @@ -0,0 +1,81 @@ >>> +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 Data into 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=,data=,data-len= >>> + [,data-be=][,cpu-num=] >>> + >>> + - The address to store the data in. >>> + - The value to be written to the address. The maximum size of >>> + the data is 8 bytes. >>> + - The length of the data in bytes. This argument must be >>> + included if the data argument is. >>> + - 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. >>> + - The number of the CPU's address space where the data should >>> + be loaded. If not specified the address space of the first >>> + CPU is used. >>> + >>> +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'. >> >> Unless you bypassed QemuOpts number parsing somehow, octal works as >> well. In case you did bypass: don't! Command line consistency matters. >> Follow-up patch reverting the bypass would be required. >> >> Not sure we want to document QemuOpts number syntax everywhere we >> explain how a certain feature uses the command line. A pointer to the >> canonical place could be better. Anyway, not something that needs >> fixing before we commit. > > I didn't bypass it, octal should work as well. I have clarified that a > bit in the doc. Thanks. >>> + >>> +An example of loading value 0x8000000e to address 0xfd1a0104 is: >>> + -device loader,addr=0xfd1a0104,data=0x8000000e,data-len=4 >>> + >>> +Setting a CPU's Program Counter >>> +--------------------- >>> +The loader device allows the CPU's PC to be set from the command line. This >>> +can be done by following the syntax below: >>> + >>> + -device loader,addr=,cpu-num= >>> + >>> + - The value to use as the CPU's PC. >>> + - The number of the CPU whose PC should be set to the >>> + specified value. >>> + >>> +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 setting CPU 0's PC to 0x8000 is: >>> + -device loader,addr=0x8000,cpu-num=0 >>> + >>> +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=[,addr=][,cpu-num=][,force-raw=] >>> + >>> + - A file to be loaded into memory >>> + - 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. >>> + - 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 or in the case of an ELF file to >>> + the value in the header. This option should only be used >>> + for the boot image. >>> + This will also cause the image to be written to the specified >>> + CPU's address space. If not specified, the default is CPU 0. >> >> Using @cpu-num both for further specifying the meaning of @addr and for >> setting that CPU's PC is awkward. Are you sure there will never be a >> use case where you need to specify the CPU without also setting its PC? >> >> To be clear: while I feel this is a question we must discuss and >> resolve, I don't think we need to hold the series for it. > > I agree that this can occur. Internally in the loader framework is a > set_pc variable. > > In the future we can make this user accessible and then allow that to > decide if the PC should be set or not. If you can't do it right away, please document it as restriction, and add a TODO comment to lift it. >>> + - Forces the file to be treated as a raw image. This can be >>> + used to specify the load address of ELF files. >> >> "Specifying the load address of an ELF file" sounds like loading a >> position-independent ELF file at a particular address. But I guess this >> is actually for loading a file raw even though it is recognized by QEMU >> as ELF. > > This option basically does make an ELF file position-independent as > the user can control where it is loaded. Aha. Then the name "force-raw" is confusing. >>> + >>> +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 >> >> Naive question: if you want to more than one thing (where "thing" is one >> of the three cases described above), do you need a separate -device for >> each, or can you combine them into one? > > You can't really squash them together. If you wanted to set two > registers, you would need two commands. That's okay. It just isn't quite obvious to me in the text. > > Thanks, > > Alistair > >> >> >> Again, while my questions may lead to improvements, they can be applied >> on top. >>