From: "Alex Bennée" <alex.bennee-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
To: devicetree-spec-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: "Alex Bennée"
<alex.bennee-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
"Julien Grall" <julien-LM2mM/qkH7s@public.gmane.org>,
"Stefano Stabellini"
<sstabellini-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
"Carl van Schaik"
<cvanscha-Rm6X0d1/PG5y9aJCnZT0Uw@public.gmane.org>
Subject: [RFC PATCH] Describe chosen modules for hypervisor booting
Date: Fri, 21 Apr 2023 17:40:12 +0100 [thread overview]
Message-ID: <20230421164012.2867267-1-alex.bennee@linaro.org> (raw)
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-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Cc: Julien Grall <julien-LM2mM/qkH7s@public.gmane.org>
Cc: Stefano Stabellini <sstabellini-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: Carl van Schaik <cvanscha-Rm6X0d1/PG5y9aJCnZT0Uw@public.gmane.org>
---
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
next reply other threads:[~2023-04-21 16:40 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-21 16:40 Alex Bennée [this message]
[not found] ` <20230421164012.2867267-1-alex.bennee-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2023-04-21 19:32 ` [RFC PATCH] Describe chosen modules for hypervisor booting Rob Herring
[not found] ` <CAL_JsqJmtcmsqRB_oiFm-cx8KU-4FgywHxK+qUn=-FvKz1d0xw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2023-04-24 12:55 ` Alex Bennée
[not found] ` <87jzy1a15e.fsf-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2023-04-24 22:41 ` Rob Herring
2023-04-24 21:49 ` Stefano Stabellini
2023-04-24 22:40 ` Rob Herring
[not found] ` <CAL_JsqJeRO_Nz29RsF_rEZ6DK+h80VJsaGeWOUJr2Qv5hKeNBQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2023-04-24 23:55 ` Stefano Stabellini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230421164012.2867267-1-alex.bennee@linaro.org \
--to=alex.bennee-qsej5fyqhm4dnm+yrofe0a@public.gmane.org \
--cc=cvanscha-Rm6X0d1/PG5y9aJCnZT0Uw@public.gmane.org \
--cc=devicetree-spec-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=julien-LM2mM/qkH7s@public.gmane.org \
--cc=sstabellini-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).