Rob Herring <robh@xxxxxxxxxx> writes:
> 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.
Where are these schema's stored?
I'm agnostic about where we eventually document this behaviour as long
as we can come up with a canonical documentation of it somewhere.
Otherwise I worry we will end up with numerous approaches all slightly
different in their behaviour.
>
>> 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
>>
--
Alex Bennée
Virtualisation Tech Lead @ Linaro
