From: Quentin Schulz <foss+dt@0leil.net>
To: Ahmad Fatoum <a.fatoum@pengutronix.de>,
Heiko Stuebner <heiko@sntech.de>,
devicetree-spec@vger.kernel.org, u-boot@lists.denx.de
Cc: Quentin Schulz <quentin.schulz@cherry.de>
Subject: [PATCH] Add 'bootsource' /chosen property
Date: Wed, 05 Feb 2025 10:11:34 +0100 [thread overview]
Message-ID: <20250205-bootsource-v1-1-95f4ba69ac27@cherry.de> (raw)
From: Quentin Schulz <quentin.schulz@cherry.de>
Bootloaders typically can be loaded from different storage media, such
as eMMC, SD card, SPI flash, EEPROM, but also from non-persistent media
such as USB (via proprietary protocols loading directly into SRAM, or
fastboot, DFU, etc..), JTAG, ...
This information is usually reported by the SoC-ROM via some proprietary
mechanism (some specific address in registers/DRAM for example).
It would be useful to know which medium was used to load the first stage
of the bootloader. SoC-ROM shall be ignored and not reported in this
property.
This can allow client programs to detect which medium to write to when
updating the boot program, or detect if fallback mechanisms to
unexpected medium were used to reach the client program's execution.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
---
Bootloaders typically can be loaded from different storage media, such
as eMMC, SD card, SPI flash, EEPROM, but also from non-persistent media
such as USB (via proprietary protocols loading directly into SRAM, or
fastboot, DFU, etc..), JTAG, ...
This information is usually reported by the SoC-ROM via some proprietary
mechanism (some specific address in registers/DRAM for example).
It would be useful to know which medium was used to load the first stage
of the bootloader. SoC-ROM shall be ignored and not reported in this
property.
This can allow client programs to detect which medium to write to when
updating the boot program, or detect if fallback mechanisms to
unexpected medium were used to reach the client program's execution.
Note that this property is already set by Barebox and I'm planning on
adding it to U-Boot as well, specifically for Rockchip SoCs.
I have some doubts about the wording, especially in the case of
hypervisors or chained boot programs. I'm not entirely sure what would
make the most sense to put in the property for those scenario.
---
source/chapter3-devicenodes.rst | 3 +++
1 file changed, 3 insertions(+)
diff --git a/source/chapter3-devicenodes.rst b/source/chapter3-devicenodes.rst
index 8080321d6e60d6b1e86c81af86c6850246a0223b..defd1a46e4ffaa4bb085306b5e153d38b740ac66 100644
--- a/source/chapter3-devicenodes.rst
+++ b/source/chapter3-devicenodes.rst
@@ -456,6 +456,9 @@ time. It shall be a child of the root node.
the client program. The value could
potentially be a null string if no boot
arguments are required.
+ ``bootsource`` O ``<string>`` A string that specifies the full path to the
+ node representing the device the BootROM used
+ to load the initial boot program.
``stdout-path`` O ``<string>`` A string that specifies the full path to the
node representing the device to be used for
boot console output. If the character ":" is
---
base-commit: 5688e1c0b961d2ca5a32e3b624a9f4a9b433184f
change-id: 20250205-bootsource-84df255e9e6c
Best regards,
--
Quentin Schulz <quentin.schulz@cherry.de>
next reply other threads:[~2025-02-05 9:12 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-05 9:11 Quentin Schulz [this message]
2025-02-06 12:33 ` [PATCH] Add 'bootsource' /chosen property Simon Glass
2025-02-06 15:46 ` Quentin Schulz
2025-02-09 14:28 ` Simon Glass
2025-02-10 16:25 ` Quentin Schulz
2025-02-15 11:59 ` Simon Glass
2025-02-15 12:47 ` Mark Kettenis
2025-02-15 13:04 ` Simon Glass
2025-02-20 14:52 ` Quentin Schulz
2025-02-15 15:13 ` Daniel Golle
2025-02-20 15:04 ` Quentin Schulz
2025-02-20 15:22 ` Daniel Golle
2025-02-20 15:54 ` Quentin Schulz
2025-02-23 0:33 ` Simon Glass
2025-02-20 15:52 ` Ahmad Fatoum
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=20250205-bootsource-v1-1-95f4ba69ac27@cherry.de \
--to=foss+dt@0leil.net \
--cc=a.fatoum@pengutronix.de \
--cc=devicetree-spec@vger.kernel.org \
--cc=heiko@sntech.de \
--cc=quentin.schulz@cherry.de \
--cc=u-boot@lists.denx.de \
/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 NNTP newsgroup(s).