Add a generic loader
v12 cover Add a generic loader
This work is based on the original work by Li Guang with extra features added by Peter C and myself.
The idea of this loader is to allow the user to load multiple images or values into QEMU at startup.
Memory values can be loaded like this: -device loader,addr=0xfd1a0104,data=0x8000000e,data-len=4
Images can be loaded like this: -device loader,file=./images/u-boot.elf,cpu=0
This can be useful and we use it a lot in Xilinx to load multiple images into a machine at creation (ATF, Kernel and DTB for example).
Tested with the latest Xilinx ZynqMP machine, if I enable EL3 and EL2 I can boot ATF through to u-boot using the loader to load the images.
It can also be used to set registers.
This patch series makes the load_elf() function more generic by not requiring an architecture. It also adds new functions load_elf_as(), load_uimage_as and load_image_targphys_as which allows custom AddressSpaces when loading images.
V12:
- All patches have been reviewed
- Most patches have been merged
- The commit message of the actual device patch has been updated to justify why it is a device.
Alistair Francis (2):
generic-loader: Add a generic loader
docs: Add a generic loader explanation document
MAINTAINERS | 6 ++ docs/generic-loader.txt | 81 ++++++++++++++++ hw/core/Makefile.objs | 2 + hw/core/generic-loader.c | 197 +++++++++++++++++++++++++++++++++++++++ include/hw/core/generic-loader.h | 46 +++++++++ 5 files changed, 332 insertions(+) create mode 100644 docs/generic-loader.txt create mode 100644 hw/core/generic-loader.c create mode 100644 include/hw/core/generic-loader.h
Signature · 1 line
2.7.4
PATCH v12 1/2 generic-loader: Add a generic loader
Add a generic loader to QEMU which can be used to load images or set memory values.
Internally inside QEMU this is a device. It is a strange device that provides no hardware interface but allows QEMU to monkey patch memory specified when it is created. To be able to do this it has a reset callback that does the memory operations.
This device allows the user to monkey patch memory. To be able to do this it needs a backend to manage the datas, the same as other memory-related devices. In this case as the backend is so trivial we have merged it with the frontend instead of creating and maintaining a seperate backend.
---
V12:
- Update commit message to justify using -device
V11:
- Small corrections
- Don't check for !data as writing a value of 0 is valid.
V10:
- Split out the PC setting and data loading
V9:
- Fix error messages
- Updated some incorrect logic
- Add address space loading support for all image types
- Explain why the reset is manually registered
V8:
- Code corrections
- Rebase
V7:
- Rebase
V6:
- Add error checking
V5:
- Rebase
V4:
- Allow the loader to work with every architecture
- Move the file to hw/core
- Increase the maximum number of CPUs
- Make the CPU operations conditional
- Convert the cpu option to cpu-num
- Require the user to specify endianess
V3:
- Pass the ram_size to load_image_targphys()
V2:
- Add maintainers entry
- Perform bounds checking
- Register and unregister the reset in the realise/unrealise
Changes since RFC:
- Add BE support
MAINTAINERS | 6 ++ hw/core/Makefile.objs | 2 + hw/core/generic-loader.c | 197 +++++++++++++++++++++++++++++++++++++++ include/hw/core/generic-loader.h | 46 +++++++++ 4 files changed, 251 insertions(+) create mode 100644 hw/core/generic-loader.c create mode 100644 include/hw/core/generic-loader.h
MAINTAINERS +6 -0
@@ -1013,6 +1013,12 @@ M: Dmitry Fleytman <[email protected]> S: Maintained F: hw/net/e1000e* +Generic Loader +M: Alistair Francis <[email protected]> +S: Maintained +F: hw/core/generic-loader.c +F: include/hw/core/generic-loader.h + Subsystems ---------- Audio
hw/core/Makefile.objs +2 -0
@@ -17,3 +17,5 @@ common-obj-$(CONFIG_SOFTMMU) += loader.o common-obj-$(CONFIG_SOFTMMU) += qdev-properties-system.o common-obj-$(CONFIG_SOFTMMU) += register.o common-obj-$(CONFIG_PLATFORM_BUS) += platform-bus.o + +obj-$(CONFIG_SOFTMMU) += generic-loader.o
hw/core/generic-loader.c new file +197 -0
197 lines not on this page · raw message
include/hw/core/generic-loader.h new file +46 -0
46 lines not on this page · raw message
Signature · 1 line
2.7.4
Re: [Qemu-devel] [PATCH v12 1/2] generic-loader: Add a generic loader
Quoted 8 lines · Alistair Francis
Add a generic loader to QEMU which can be used to load images or set memory values.
Internally inside QEMU this is a device. It is a strange device that provides no hardware interface but allows QEMU to monkey patch memory specified when it is created. To be able to do this it has a reset callback that does the memory operations.
Quoted 5 lines
This device allows the user to monkey patch memory. To be able to do this it needs a backend to manage the datas, the same as other memory-related devices. In this case as the backend is so trivial we have merged it with the frontend instead of creating and maintaining a seperate backend.
Works for me.
Quoted 2 lines
Signed-off-by Alistair Francis <[email protected]>Reviewed-by Peter Maydell <[email protected]>
[...]
Quoted 13 lines
hw/core/generic-loader.c new file +7
-0@@ -0,0 +1,197 @@ +/* +* Generic Loader +* +* Copyright (C) 2014 Li Guang +* Copyright (C) 2016 Xilinx Inc. +* Written by Li Guang <[email protected]> +*
hw/core/generic-loader.c line 17
Quoted 10 lines
hw/core/generic-loader.c new file +10
-0+* This program is free software; you can redistribute it and/or modify it +* under the terms of the GNU General Public License as published by the +* Free Software Foundation; either version 2 of the License, or +* (at your option) any later version. +* +* This program is distributed in the hope that it will be useful, but WITHOUT +* ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or +* FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License +* for more details. +*/
The text you added to the commit message would make a lovely comment here. Please add it.
hw/core/generic-loader.c line 25
Quoted 8 lines
hw/core/generic-loader.c new file +8
-0+ +#include "qemu/osdep.h" +#include "qom/cpu.h" +#include "hw/sysbus.h" +#include "sysemu/dma.h" +#include "hw/loader.h" +#include "qapi/error.h" +#include "hw/core/generic-loader.h"
[...]
Thank you very much for processing my much-too-late design review graciously.
Re: [Qemu-devel] [PATCH v12 1/2] generic-loader: Add a generic loader
Quoted 10 lines · Markus Armbruster
Quoted 8 lines · Alistair Francis
Add a generic loader to QEMU which can be used to load images or set memory values.
Internally inside QEMU this is a device. It is a strange device that provides no hardware interface but allows QEMU to monkey patch memory specified when it is created. To be able to do this it has a reset callback that does the memory operations.
Quoted 7 lines
Quoted 5 lines
This device allows the user to monkey patch memory. To be able to do this it needs a backend to manage the datas, the same as other memory-related devices. In this case as the backend is so trivial we have merged it with the frontend instead of creating and maintaining a seperate backend.
Works for me.
Great!
Quoted 22 lines
Quoted 3 lines
Signed-off-by Alistair Francis <[email protected]>Reviewed-by Peter Maydell <[email protected]>[...]
Quoted 18 lines
hw/core/generic-loader.c new file +12
-0@@ -0,0 +1,197 @@ +/* +* Generic Loader +* +* Copyright (C) 2014 Li Guang +* Copyright (C) 2016 Xilinx Inc. +* Written by Li Guang <[email protected]> +* +* This program is free software; you can redistribute it and/or modify it +* under the terms of the GNU General Public License as published by the +* Free Software Foundation; either version 2 of the License, or +* (at your option) any later version. +*
Quoted 8 lines
hw/core/generic-loader.c line 17
Quoted 5 lines
hw/core/generic-loader.c new file +5
-0+* This program is distributed in the hope that it will be useful, but WITHOUT +* ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or +* FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License +* for more details. +*/ The text you added to the commit message would make a lovely comment here. Please add it.
Adding it in.
Quoted 11 lines
Quoted 9 lines
hw/core/generic-loader.c new file +8
-0+ +#include "qemu/osdep.h" +#include "qom/cpu.h" +#include "hw/sysbus.h" +#include "sysemu/dma.h" +#include "hw/loader.h" +#include "qapi/error.h" +#include "hw/core/generic-loader.h" [...]
Quoted 2 lines
Thank you very much for processing my much-too-late design review graciously.
No worries
Quoted 2 lines
Thanks!
Alistair
Quoted 1 line
PATCH v12 2/2 docs: Add a generic loader explanation document
In reply to Alistair Francis---
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
docs/generic-loader.txt new file +81 -0
@@ -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=<addr>,data=<data>,data-len=<data-len> + [,data-be=<data-be>][,cpu-num=<cpu-num>] + + <addr> - The address to store the data in. + <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> - 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'. + +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=<addr>,cpu-num=<cpu-num> + + <addr> - The value to use as the CPU's PC. + <cpu-num> - 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=<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 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. + <force-raw> - Forces the file to be treated as a raw image. This can be + used to specify the load address of ELF files. + +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
Signature · 1 line
2.7.4
Re: [Qemu-devel] [PATCH v12 2/2] docs: Add a generic loader explanation document
Quoted 48 lines · Alistair Francis
Signed-off-by Alistair Francis <[email protected]>Reviewed-by Peter Maydell <[email protected]>---
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 comprehensivedocs/generic-loader.txt | 81 +++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 81 insertions(+) create mode 100644 docs/generic-loader.txtdocs/generic-loader.txt new file +22
-0@@ -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=<addr>,data=<data>,data-len=<data-len> + [,data-be=<data-be>][,cpu-num=<cpu-num>] + + <addr> - The address to store the data in. + <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.
docs/generic-loader.txt line 32
Quoted 10 lines
docs/generic-loader.txt new file +10
-0+ <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> - 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.
Quoted 30 lines
docs/generic-loader.txt new file +30
-0+ +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=<addr>,cpu-num=<cpu-num> + + <addr> - The value to use as the CPU's PC. + <cpu-num> - 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=<file>[,addr=<addr>][,cpu-num=<cpu-num>][,force-raw=<raw>] + + <file> - A file to be loaded into memory
docs/generic-loader.txt line 72
Quoted 10 lines
docs/generic-loader.txt new file +10
-0+ <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 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.
docs/generic-loader.txt line 74
Quoted 2 lines
docs/generic-loader.txt new file +2
-0+ <force-raw> - 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.
docs/generic-loader.txt line 81
Quoted 7 lines
docs/generic-loader.txt new file +7
-0+ +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?
Again, while my questions may lead to improvements, they can be applied on top.
Re: [Qemu-devel] [PATCH v12 2/2] docs: Add a generic loader explanation document
Quoted 65 lines · Markus Armbruster
Quoted 48 lines · Alistair Francis
Signed-off-by Alistair Francis <[email protected]>Reviewed-by Peter Maydell <[email protected]>---
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 comprehensivedocs/generic-loader.txt | 81 +++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 81 insertions(+) create mode 100644 docs/generic-loader.txtdocs/generic-loader.txt new file +22
-0@@ -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=<addr>,data=<data>,data-len=<data-len> + [,data-be=<data-be>][,cpu-num=<cpu-num>] + + <addr> - The address to store the data in. + <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.docs/generic-loader.txt line 32
Quoted 10 lines
docs/generic-loader.txt new file +10
-0+ <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> - 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.
Quoted 4 lines
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.
Quoted 46 lines
Quoted 31 lines
docs/generic-loader.txt new file +30
-0+ +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=<addr>,cpu-num=<cpu-num> + + <addr> - The value to use as the CPU's PC. + <cpu-num> - 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=<file>[,addr=<addr>][,cpu-num=<cpu-num>][,force-raw=<raw>] + + <file> - A file to be loaded into memorydocs/generic-loader.txt line 72
Quoted 10 lines
docs/generic-loader.txt new file +10
-0+ <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 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?
Quoted 2 lines
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.
Quoted 8 lines
docs/generic-loader.txt line 74
Quoted 3 lines
docs/generic-loader.txt new file +2
-0+ <force-raw> - 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.
Quoted 12 lines
docs/generic-loader.txt line 81
Quoted 8 lines
docs/generic-loader.txt new file +7
-0+ +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=0Naive 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.
Thanks,
Alistair
Quoted 5 lines
Again, while my questions may lead to improvements, they can be applied on top.
Re: [Qemu-devel] [PATCH v12 2/2] docs: Add a generic loader explanation document
Quoted 66 lines · Alistair Francis
Quoted 65 lines · Markus Armbruster
Quoted 48 lines · Alistair Francis
Signed-off-by Alistair Francis <[email protected]>Reviewed-by Peter Maydell <[email protected]>---
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 comprehensivedocs/generic-loader.txt | 81 +++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 81 insertions(+) create mode 100644 docs/generic-loader.txtdocs/generic-loader.txt new file +22
-0@@ -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=<addr>,data=<data>,data-len=<data-len> + [,data-be=<data-be>][,cpu-num=<cpu-num>] + + <addr> - The address to store the data in. + <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.docs/generic-loader.txt line 32
Quoted 10 lines
docs/generic-loader.txt new file +10
-0+ <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> - 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.
Quoted 7 lines
Quoted 4 lines
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.
Quoted 45 lines
Quoted 45 lines
Quoted 30 lines
docs/generic-loader.txt new file +30
-0+ +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=<addr>,cpu-num=<cpu-num> + + <addr> - The value to use as the CPU's PC. + <cpu-num> - 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=<file>[,addr=<addr>][,cpu-num=<cpu-num>][,force-raw=<raw>] + + <file> - A file to be loaded into memorydocs/generic-loader.txt line 72
Quoted 10 lines
docs/generic-loader.txt new file +10
-0+ <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 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?
Quoted 8 lines
Quoted 2 lines
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_pcvariable.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.
Quoted 10 lines
Quoted 7 lines
docs/generic-loader.txt line 74
Quoted 2 lines
docs/generic-loader.txt new file +2
-0+ <force-raw> - 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.
Quoted 12 lines
Quoted 11 lines
docs/generic-loader.txt line 81
Quoted 7 lines
docs/generic-loader.txt new file +7
-0+ +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=0Naive 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?
Quoted 2 lines
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.
Quoted 10 lines
Thanks,
Alistair
Quoted 5 lines
Again, while my questions may lead to improvements, they can be applied on top.
Re: [Qemu-devel] [PATCH v12 2/2] docs: Add a generic loader explanation document
Quoted 126 lines · Markus Armbruster
Quoted 66 lines · Alistair Francis
Quoted 65 lines · Markus Armbruster
Quoted 48 lines · Alistair Francis
Signed-off-by Alistair Francis <[email protected]>Reviewed-by Peter Maydell <[email protected]>---
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 comprehensivedocs/generic-loader.txt | 81 +++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 81 insertions(+) create mode 100644 docs/generic-loader.txtdocs/generic-loader.txt new file +22
-0@@ -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=<addr>,data=<data>,data-len=<data-len> + [,data-be=<data-be>][,cpu-num=<cpu-num>] + + <addr> - The address to store the data in. + <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.docs/generic-loader.txt line 32
Quoted 10 lines
docs/generic-loader.txt new file +10
-0+ <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> - 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.
Quoted 7 lines
Quoted 4 lines
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.
Quoted 48 lines
Quoted 47 lines
Quoted 30 lines
docs/generic-loader.txt new file +30
-0+ +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=<addr>,cpu-num=<cpu-num> + + <addr> - The value to use as the CPU's PC. + <cpu-num> - 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=<file>[,addr=<addr>][,cpu-num=<cpu-num>][,force-raw=<raw>] + + <file> - A file to be loaded into memorydocs/generic-loader.txt line 72
Quoted 10 lines
docs/generic-loader.txt new file +10
-0+ <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 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.
Quoted 8 lines
Quoted 5 lines
I agree that this can occur. Internally in the loader framework is a
set_pcvariable.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.
I have a patch that adds known restrictions.
Quoted 9 lines
Quoted 9 lines
Quoted 8 lines
docs/generic-loader.txt line 74
Quoted 3 lines
docs/generic-loader.txt new file +2
-0+ <force-raw> - 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.
Quoted 4 lines
Quoted 2 lines
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.
I disagree. It tells QEMU to treat the image as just a dumb blob, instead of loading it as and ELF file. I thin force-raw makes sense as the user is telling QEMU that the image should be treated as a raw image, no matter what it actually is.
Thanks,
Alistair
Quoted 29 lines
Quoted 13 lines
Quoted 12 lines
docs/generic-loader.txt line 81
Quoted 8 lines
docs/generic-loader.txt new file +7
-0+ +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=0Naive 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?
Quoted 2 lines
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.
Quoted 10 lines
Thanks,
Alistair
Quoted 5 lines
Again, while my questions may lead to improvements, they can be applied on top.
Re: [Qemu-devel] [PATCH v12 2/2] docs: Add a generic loader explanation document
Quoted 150 lines · Alistair Francis
Quoted 126 lines · Markus Armbruster
Quoted 66 lines · Alistair Francis
Quoted 65 lines · Markus Armbruster
Quoted 48 lines · Alistair Francis
Signed-off-by Alistair Francis <[email protected]>Reviewed-by Peter Maydell <[email protected]>---
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 comprehensivedocs/generic-loader.txt | 81 +++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 81 insertions(+) create mode 100644 docs/generic-loader.txtdocs/generic-loader.txt new file +22
-0@@ -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=<addr>,data=<data>,data-len=<data-len> + [,data-be=<data-be>][,cpu-num=<cpu-num>] + + <addr> - The address to store the data in. + <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.docs/generic-loader.txt line 32
Quoted 10 lines
docs/generic-loader.txt new file +10
-0+ <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> - 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.
Quoted 7 lines
Quoted 4 lines
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.
Quoted 48 lines
Quoted 47 lines
Quoted 30 lines
docs/generic-loader.txt new file +30
-0+ +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=<addr>,cpu-num=<cpu-num> + + <addr> - The value to use as the CPU's PC. + <cpu-num> - 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=<file>[,addr=<addr>][,cpu-num=<cpu-num>][,force-raw=<raw>] + + <file> - A file to be loaded into memorydocs/generic-loader.txt line 72
Quoted 10 lines
docs/generic-loader.txt new file +10
-0+ <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 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.
Quoted 8 lines
Quoted 5 lines
I agree that this can occur. Internally in the loader framework is a
set_pcvariable.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.
I have a patch that adds known restrictions.
Quoted 12 lines
Quoted 11 lines
Quoted 8 lines
docs/generic-loader.txt line 74
Quoted 3 lines
docs/generic-loader.txt new file +2
-0+ <force-raw> - 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.
Quoted 6 lines
Quoted 1 line
Aha. Then the name "force-raw" is confusing.
I disagree. It tells QEMU to treat the image as just a dumb blob, instead of loading it as and ELF file. I thin force-raw makes sense as the user is telling QEMU that the image should be treated as a raw image, no matter what it actually is.
I'm still confused then.
I can see two possible features here, and based on your documentation and commentary, I can't tell which one you implemented:
0. QEMU can load raw files and ELF executable files. Raw files are loaded verbatim at a the specified address. ELF executable files are loaded by an ELF loader, which loads the program header table's loadable segments.
1. force-raw overrides the ELF detection, to let you load an ELF executable file verbatim, as if it was raw.
2. force-raw lets you overrides the ELF file's load address: the ELF loader uses the specified address instead of the address contained in the ELF file.
Which one is it? Your latest answer strongly suggests 1, but prior answers have made me suspect 2.
Re: [Qemu-devel] [PATCH v12 2/2] docs: Add a generic loader explanation document
Quoted 164 lines · Markus Armbruster
Quoted 150 lines · Alistair Francis
Quoted 126 lines · Markus Armbruster
Quoted 66 lines · Alistair Francis
Quoted 65 lines · Markus Armbruster
Quoted 48 lines · Alistair Francis
Signed-off-by Alistair Francis <[email protected]>Reviewed-by Peter Maydell <[email protected]>---
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 comprehensivedocs/generic-loader.txt | 81 +++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 81 insertions(+) create mode 100644 docs/generic-loader.txtdocs/generic-loader.txt new file +22
-0@@ -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=<addr>,data=<data>,data-len=<data-len> + [,data-be=<data-be>][,cpu-num=<cpu-num>] + + <addr> - The address to store the data in. + <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.docs/generic-loader.txt line 32
Quoted 10 lines
docs/generic-loader.txt new file +10
-0+ <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> - 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.
Quoted 7 lines
Quoted 4 lines
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.
Quoted 48 lines
Quoted 47 lines
Quoted 30 lines
docs/generic-loader.txt new file +30
-0+ +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=<addr>,cpu-num=<cpu-num> + + <addr> - The value to use as the CPU's PC. + <cpu-num> - 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=<file>[,addr=<addr>][,cpu-num=<cpu-num>][,force-raw=<raw>] + + <file> - A file to be loaded into memorydocs/generic-loader.txt line 72
Quoted 10 lines
docs/generic-loader.txt new file +10
-0+ <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 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.
Quoted 8 lines
Quoted 5 lines
I agree that this can occur. Internally in the loader framework is a
set_pcvariable.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.
I have a patch that adds known restrictions.
Quoted 12 lines
Quoted 11 lines
Quoted 8 lines
docs/generic-loader.txt line 74
Quoted 3 lines
docs/generic-loader.txt new file +2
-0+ <force-raw> - 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.
Quoted 6 lines
Quoted 1 line
Aha. Then the name "force-raw" is confusing.
I disagree. It tells QEMU to treat the image as just a dumb blob, instead of loading it as and ELF file. I thin force-raw makes sense as the user is telling QEMU that the image should be treated as a raw image, no matter what it actually is.
I'm still confused then.
I can see two possible features here, and based on your documentation and commentary, I can't tell which one you implemented:
Quoted 7 lines
0. QEMU can load raw files and ELF executable files. Raw files are loaded verbatim at a the specified address. ELF executable files are loaded by an ELF loader, which loads the program header table's loadable segments.
1. force-raw overrides the ELF detection, to let you load an ELF executable file verbatim, as if it was raw.
This is what the option does. It forces the image to be treated as a raw image.
I'm sorry if I implied it was option 2 instead.
Thanks,
Alistair
Quoted 8 lines
2. force-raw lets you overrides the ELF file's load address: the ELF loader uses the specified address instead of the address contained in the ELF file.
Which one is it? Your latest answer strongly suggests 1, but prior answers have made me suspect 2.
Re: [Qemu-devel] [PATCH v12 2/2] docs: Add a generic loader explanation document
Quoted 170 lines · Alistair Francis
Quoted 169 lines · Markus Armbruster
Quoted 150 lines · Alistair Francis
Quoted 126 lines · Markus Armbruster
Quoted 66 lines · Alistair Francis
Quoted 65 lines · Markus Armbruster
Quoted 48 lines · Alistair Francis
Signed-off-by Alistair Francis <[email protected]>Reviewed-by Peter Maydell <[email protected]>---
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 comprehensivedocs/generic-loader.txt | 81 +++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 81 insertions(+) create mode 100644 docs/generic-loader.txtdocs/generic-loader.txt new file +22
-0@@ -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=<addr>,data=<data>,data-len=<data-len> + [,data-be=<data-be>][,cpu-num=<cpu-num>] + + <addr> - The address to store the data in. + <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.docs/generic-loader.txt line 32
Quoted 10 lines
docs/generic-loader.txt new file +10
-0+ <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> - 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.
Quoted 7 lines
Quoted 4 lines
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.
Quoted 48 lines
Quoted 47 lines
Quoted 30 lines
docs/generic-loader.txt new file +30
-0+ +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=<addr>,cpu-num=<cpu-num> + + <addr> - The value to use as the CPU's PC. + <cpu-num> - 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=<file>[,addr=<addr>][,cpu-num=<cpu-num>][,force-raw=<raw>] + + <file> - A file to be loaded into memorydocs/generic-loader.txt line 72
Quoted 10 lines
docs/generic-loader.txt new file +10
-0+ <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 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.
Quoted 8 lines
Quoted 5 lines
I agree that this can occur. Internally in the loader framework is a
set_pcvariable.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.
I have a patch that adds known restrictions.
Quoted 12 lines
Quoted 11 lines
Quoted 8 lines
docs/generic-loader.txt line 74
Quoted 3 lines
docs/generic-loader.txt new file +2
-0+ <force-raw> - 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.
Quoted 6 lines
Quoted 1 line
Aha. Then the name "force-raw" is confusing.
I disagree. It tells QEMU to treat the image as just a dumb blob, instead of loading it as and ELF file. I thin force-raw makes sense as the user is telling QEMU that the image should be treated as a raw image, no matter what it actually is.
I'm still confused then.
I can see two possible features here, and based on your documentation and commentary, I can't tell which one you implemented:
0. QEMU can load raw files and ELF executable files. Raw files are loaded verbatim at a the specified address. ELF executable files are loaded by an ELF loader, which loads the program header table's loadable segments.
Quoted 4 lines
Quoted 2 lines
1. force-raw overrides the ELF detection, to let you load an ELF executable file verbatim, as if it was raw.
This is what the option does. It forces the image to be treated as a raw image.
Okay, makes sense now.
Quoted 1 line
I'm sorry if I implied it was option 2 instead.
No problem. Suggest to clarify docs/generic-loader.txt, perhaps like this:
Loading Files
-------------
The loader device also allows files to be loaded into memory. It can load raw files and ELF executable files. Raw files are loaded verbatim. ELF executable files are loaded by an ELF loader. The syntax is shown below:
[...]
<force-raw> - force-raw=on forces the file to be treated as a raw
image. This can be used to load ELF files as if they were raw.
Re: [Qemu-devel] [PATCH v12 2/2] docs: Add a generic loader explanation document
Quoted 175 lines · Markus Armbruster
Quoted 173 lines · Alistair Francis
Quoted 171 lines · Markus Armbruster
Quoted 150 lines · Alistair Francis
Quoted 126 lines · Markus Armbruster
Quoted 66 lines · Alistair Francis
Quoted 65 lines · Markus Armbruster
Quoted 48 lines · Alistair Francis
Signed-off-by Alistair Francis <[email protected]>Reviewed-by Peter Maydell <[email protected]>---
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 comprehensivedocs/generic-loader.txt | 81 +++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 81 insertions(+) create mode 100644 docs/generic-loader.txtdocs/generic-loader.txt new file +22
-0@@ -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=<addr>,data=<data>,data-len=<data-len> + [,data-be=<data-be>][,cpu-num=<cpu-num>] + + <addr> - The address to store the data in. + <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.docs/generic-loader.txt line 32
Quoted 10 lines
docs/generic-loader.txt new file +10
-0+ <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> - 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.
Quoted 7 lines
Quoted 4 lines
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.
Quoted 48 lines
Quoted 47 lines
Quoted 30 lines
docs/generic-loader.txt new file +30
-0+ +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=<addr>,cpu-num=<cpu-num> + + <addr> - The value to use as the CPU's PC. + <cpu-num> - 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=<file>[,addr=<addr>][,cpu-num=<cpu-num>][,force-raw=<raw>] + + <file> - A file to be loaded into memorydocs/generic-loader.txt line 72
Quoted 10 lines
docs/generic-loader.txt new file +10
-0+ <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 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.
Quoted 8 lines
Quoted 5 lines
I agree that this can occur. Internally in the loader framework is a
set_pcvariable.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.
I have a patch that adds known restrictions.
Quoted 12 lines
Quoted 11 lines
Quoted 8 lines
docs/generic-loader.txt line 74
Quoted 3 lines
docs/generic-loader.txt new file +2
-0+ <force-raw> - 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.
Quoted 6 lines
Quoted 1 line
Aha. Then the name "force-raw" is confusing.
I disagree. It tells QEMU to treat the image as just a dumb blob, instead of loading it as and ELF file. I thin force-raw makes sense as the user is telling QEMU that the image should be treated as a raw image, no matter what it actually is.
I'm still confused then.
I can see two possible features here, and based on your documentation and commentary, I can't tell which one you implemented:
0. QEMU can load raw files and ELF executable files. Raw files are loaded verbatim at a the specified address. ELF executable files are loaded by an ELF loader, which loads the program header table's loadable segments.
1. force-raw overrides the ELF detection, to let you load an ELF executable file verbatim, as if it was raw.
Quoted 8 lines
Quoted 1 line
This is what the option does. It forces the image to be treated as a raw image.
Okay, makes sense now.
Quoted 1 line
I'm sorry if I implied it was option 2 instead.
No problem. Suggest to clarify
docs/generic-loader.txt, perhaps like this:
Too easy. I sent a V3 of my docs updating patch which fixes this.
It's called: docs/generic-loader: Update the document
Thanks,
Alistair
Quoted 14 lines
Loading Files
-------------The loader device also allows files to be loaded into memory. It can load raw files and ELF executable files. Raw files are loaded verbatim. ELF executable files are loaded by an ELF loader. The syntax is shown below:
[...]
<force-raw> - force-raw=on forces the file to be treated as a raw
image. This can be used to load ELF files as if they were raw.
Your series failed automatic build test. Please find the testing commands and their output below. If you have docker installed, you can probably reproduce it locally.
Hi,
Your series failed automatic build test. Please find the testing commands and their output below. If you have docker installed, you can probably reproduce it locally.
Type: series
Message-id: [email protected]
Subject: [Qemu-devel] [PATCH v12 0/2] Add a generic loader
=== TEST SCRIPT BEGIN ===
#!/bin/bash
set -e
git submodule update --init dtc
# Let docker tests dump environment info
export SHOW_ENV=1
make J=8 docker-test-quick@centos6
make J=8 docker-test-mingw@fedora
=== TEST SCRIPT END ===
Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384 Switched to a new branch 'test'
e1a89b7 docs: Add a generic loader explanation document 1826cff generic-loader: Add a generic loader
=== OUTPUT BEGIN ===
Submodule 'dtc' (git://git.qemu-project.org/dtc.git) registered for path 'dtc' Cloning into 'dtc'...
Submodule path 'dtc': checked out '65cc4d2748a2c2e6f27f1cf39e07a5dbabd80ebf'
BUILD centos6
=== OUTPUT END ===
Abort: command timeout (>3600 seconds)
---
Email generated automatically by Patchew [http://patchew.org/].
Please send your feedback to [email protected]
Quoted 25 lines · [email protected] writes:
Hi,
Your series failed automatic build test. Please find the testing commands and their output below. If you have docker installed, you can probably reproduce it locally.
Type: series
Message-id: [email protected]
Subject: [Qemu-devel] [PATCH v12 0/2] Add a generic loader=== TEST SCRIPT BEGIN ===
#!/bin/bash
set -e
git submodule update --init dtc
# Let docker tests dump environment info
export SHOW_ENV=1
make J=8 docker-test-quick@centos6
make J=8 docker-test-mingw@fedora
=== TEST SCRIPT END ===Updating
3c8cf5a9c21ff8782164d1def7f44bd888713384Switched to a new branch 'test'
e1a89b7 docs: Add a generic loader explanation document 1826cff generic-loader: Add a generic loader
Quoted 8 lines
=== OUTPUT BEGIN ===
Submodule 'dtc' (git://git.qemu-project.org/dtc.git) registered for path 'dtc' Cloning into 'dtc'...
Submodule path 'dtc': checked out '65cc4d2748a2c2e6f27f1cf39e07a5dbabd80ebf'
BUILD centos6
=== OUTPUT END ===Abort: command timeout (>3600 seconds)
Patchew hiccup or a real problem?
Quoted 1 line · Markus Armbruster
Patchew hiccup or a real problem?
Looks like a hiccup to me.
Can you let me know if you're happy with the new commit messages? If so I'll apply these to target-arm.next.
thanks
-- PMM
Quoted 4 lines · Peter Maydell
Quoted 1 line · Markus Armbruster
Patchew hiccup or a real problem?
Looks like a hiccup to me.
Same, it looks like it can't clone dtc.
Thanks,
Alistair
Quoted 7 lines
Can you let me know if you're happy with the new commit messages? If so I'll apply these to target-arm.next.
thanks
-- PMM
Quoted 7 lines · Alistair Francis
Quoted 4 lines · Peter Maydell
Quoted 1 line · Markus Armbruster
Patchew hiccup or a real problem?
Looks like a hiccup to me.
Same, it looks like it can't clone dtc
I think it cloned dtc but then hung after that; either way, nothing to do with these patches.
-- PMM
Quoted 4 lines · Alistair Francis
Quoted 3 lines · Peter Maydell
Quoted 1 line · Markus Armbruster
Patchew hiccup or a real problem?
Quoted 11 lines
Quoted 1 line
Looks like a hiccup to me.
Same, it looks like it can't clone dtc.
Thanks,
Alistair
Quoted 3 lines
Can you let me know if you're happy with the new commit messages? If so I'll apply these to target-arm.next.
I just sent out a V13 which include Markus's updates. It doesn't touch any code, just updated the comments in the c file and re-words the value passing in the doc.
Thanks,
Alistair
Quoted 4 lines
Quoted 4 lines
thanks
-- PMM
Quoted 34 lines · Markus Armbruster
Quoted 32 lines · [email protected] writes:
Hi,
Your series failed automatic build test. Please find the testing commands and their output below. If you have docker installed, you can probably reproduce it locally.
Type: series
Message-id: [email protected]
Subject: [Qemu-devel] [PATCH v12 0/2] Add a generic loader=== TEST SCRIPT BEGIN ===
#!/bin/bash
set -e
git submodule update --init dtc
# Let docker tests dump environment info
export SHOW_ENV=1
make J=8 docker-test-quick@centos6
make J=8 docker-test-mingw@fedora
=== TEST SCRIPT END ===Updating
3c8cf5a9c21ff8782164d1def7f44bd888713384Switched to a new branch 'test'
e1a89b7 docs: Add a generic loader explanation document 1826cff generic-loader: Add a generic loader=== OUTPUT BEGIN ===
Submodule 'dtc' (git://git.qemu-project.org/dtc.git) registered for path 'dtc' Cloning into 'dtc'...
Submodule path 'dtc': checked out '65cc4d2748a2c2e6f27f1cf39e07a5dbabd80ebf'
BUILD centos6
=== OUTPUT END ===
Quoted 3 lines
Quoted 1 line
Abort: command timeout (>3600 seconds)
Patchew hiccup or a real problem?
Likely a docker hiccup. The laste line being "BUILD centos6" means the "make docker-test-quick@centos6" is hung. I don't know much more either. :(
Fam