mirror of
https://github.com/edk2-porting/linux-next.git
synced 2024-12-25 21:54:06 +08:00
53275a61bc
Peter Maydell suggested that we describe new devices / DTB nodes in the kernel Documentation tree that we expose to arm "virt" guests in QEMU. Although the kernel is not required to access the fw_cfg interface, "Documentation/devicetree/bindings/arm" is probably the best central spot to keep the fw_cfg description in. Suggested-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Rob Herring <robh@kernel.org>
73 lines
3.0 KiB
Plaintext
73 lines
3.0 KiB
Plaintext
* QEMU Firmware Configuration bindings for ARM
|
|
|
|
QEMU's arm-softmmu and aarch64-softmmu emulation / virtualization targets
|
|
provide the following Firmware Configuration interface on the "virt" machine
|
|
type:
|
|
|
|
- A write-only, 16-bit wide selector (or control) register,
|
|
- a read-write, 64-bit wide data register.
|
|
|
|
QEMU exposes the control and data register to ARM guests as memory mapped
|
|
registers; their location is communicated to the guest's UEFI firmware in the
|
|
DTB that QEMU places at the bottom of the guest's DRAM.
|
|
|
|
The guest writes a selector value (a key) to the selector register, and then
|
|
can read the corresponding data (produced by QEMU) via the data register. If
|
|
the selected entry is writable, the guest can rewrite it through the data
|
|
register.
|
|
|
|
The selector register takes keys in big endian byte order.
|
|
|
|
The data register allows accesses with 8, 16, 32 and 64-bit width (only at
|
|
offset 0 of the register). Accesses larger than a byte are interpreted as
|
|
arrays, bundled together only for better performance. The bytes constituting
|
|
such a word, in increasing address order, correspond to the bytes that would
|
|
have been transferred by byte-wide accesses in chronological order.
|
|
|
|
The interface allows guest firmware to download various parameters and blobs
|
|
that affect how the firmware works and what tables it installs for the guest
|
|
OS. For example, boot order of devices, ACPI tables, SMBIOS tables, kernel and
|
|
initrd images for direct kernel booting, virtual machine UUID, SMP information,
|
|
virtual NUMA topology, and so on.
|
|
|
|
The authoritative registry of the valid selector values and their meanings is
|
|
the QEMU source code; the structure of the data blobs corresponding to the
|
|
individual key values is also defined in the QEMU source code.
|
|
|
|
The presence of the registers can be verified by selecting the "signature" blob
|
|
with key 0x0000, and reading four bytes from the data register. The returned
|
|
signature is "QEMU".
|
|
|
|
The outermost protocol (involving the write / read sequences of the control and
|
|
data registers) is expected to be versioned, and/or described by feature bits.
|
|
The interface revision / feature bitmap can be retrieved with key 0x0001. The
|
|
blob to be read from the data register has size 4, and it is to be interpreted
|
|
as a uint32_t value in little endian byte order. The current value
|
|
(corresponding to the above outer protocol) is zero.
|
|
|
|
The guest kernel is not expected to use these registers (although it is
|
|
certainly allowed to); the device tree bindings are documented here because
|
|
this is where device tree bindings reside in general.
|
|
|
|
Required properties:
|
|
|
|
- compatible: "qemu,fw-cfg-mmio".
|
|
|
|
- reg: the MMIO region used by the device.
|
|
* Bytes 0x0 to 0x7 cover the data register.
|
|
* Bytes 0x8 to 0x9 cover the selector register.
|
|
* Further registers may be appended to the region in case of future interface
|
|
revisions / feature bits.
|
|
|
|
Example:
|
|
|
|
/ {
|
|
#size-cells = <0x2>;
|
|
#address-cells = <0x2>;
|
|
|
|
fw-cfg@9020000 {
|
|
compatible = "qemu,fw-cfg-mmio";
|
|
reg = <0x0 0x9020000 0x0 0xa>;
|
|
};
|
|
};
|