When booting something like a hypervisor there is need to communicate
to it how the first guest will be loaded. Typically the firmware or
boot loader will put the kernel and ramdisk in memory and pass the
information to the hypervisors boot code. This mechanism currently
works with Xen on the Arm platform and would be equally applicable to
other such hypervisors.
However this specification doesn't address the needs of a dom0less
system (where there is no "root" guest to launch the others) so is
currently very much an RFC.
Signed-off-by: Alex Bennée <alex.bennee@xxxxxxxxxx>
Cc: Julien Grall <julien@xxxxxxx>
Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>
Cc: Carl van Schaik <cvanscha@xxxxxxxxxxxxxxxx>
---
source/chapter3-devicenodes.rst | 55 +++++++++++++++++++++++++++++++++
1 file changed, 55 insertions(+)
diff --git a/source/chapter3-devicenodes.rst b/source/chapter3-devicenodes.rst
index 958257e..3c021a4 100644
--- a/source/chapter3-devicenodes.rst
+++ b/source/chapter3-devicenodes.rst
@@ -488,6 +488,61 @@ For compatibility, a client program might want to support
*linux,stdout-path* if a *stdout-path* property is not present. The meaning
and use of the two properties is identical.
+``chosen`` modules
+~~~~~~~~~~~~~~~~~~
+
+In a multi-stage boot, for example booting a hypervisor directly, the
+firmware may need to describe where the booting stage can find the
+next bit of software. These are described with one or more ``module``
+nodes which describe where in memory the module can be found and how
+to boot it. The ``module`` nodes should be filtered out from the DT
+passed to the next stage.
+
+.. tabularcolumns:: | p{4cm} p{0.75cm} p{4cm} p{6.5cm} |
+.. table:: ``/chosen/module`` Node Properties
+
+ ======================= ===== ===================== ===============================================
+ Property Name Usage Value Type Definition
+ ======================= ===== ===================== ===============================================
+ ``bootargs`` O ``<string>`` A string that specifies the boot arguments for
+ the client program. The value could
+ potentially be a null string if no boot
+ arguments are required.
+ ``compatible`` OR ``<string>`` Describes the module, may contain the following
+ strings:
+
+ - ``multiboot,kernel``: This indicates the
+ module is a multiboot compatible
+ kernel image
+
+ - ``multiboot,ramdisk``:
+ This indicates the module is a ramdisk
+ image. Kernels confirming to the
+ multiboot spec will expect to be
+ pointed to the ramdisk as part of
+ the boot information
+ Usage legend: R=Required, O=Optional, OR=Optional but Recommended, SD=See Definition
+ ===================================================================================================
+
+**Example**
+
+.. code-block:: dts
+
+ chosen {
+ bootargs = "dom0_mem=128M loglvl=all guest_loglvl=all";
+ stdout-path = "/pl011@9000000";
+
+ module@0x47000000 {
+ bootargs = "console=hvc0";
+ compatible = "multiboot,module\0multiboot,kernel";
+ reg = <0x00 0x47000000 0x00 0xe47a00>;
+ };
+ };
+
+In this example the root bootargs are passed to the first stage and
+configure the hypervisor with the module being a kernel image that the
+hypervisor will boot with specific arguments for the guests kernel.
+
``/cpus`` Node Properties
-------------------------
--
2.39.2
