On Fri, Apr 21, 2023 at 11:40 AM Alex Bennée <alex.bennee@xxxxxxxxxx> wrote:
>
> 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.
This is probably something to discuss on the boot-architecture list.
>
> 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.
In the end, whatever you want to add will need a DT schema. Really,
just a schema would be fine. Much of /chosen is not in the spec.
> 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.
I think 'image' would be a bit clearer than 'module'.
> +
> +.. 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
What does "multiboot compatible" mean?
> +
> + - ``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
Why don't the existing initrd properties work?
> + 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
>
