Hello,
Quentin, thanks for starting this discussion.
On 10.02.25 17:25, Quentin Schulz wrote:
> On 2/9/25 3:28 PM, Simon Glass wrote:
>> On Thu, 6 Feb 2025 at 08:46, Quentin Schulz <quentin.sch...@cherry.de> wrote:
>>>>> 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.
>>>>
>>>> Could/shoud this be a phandle instead? It might be more efficient.
AFAIK, all other properties in /chosen (e.g. stdout-path) are strings
Having this one be a phandle would be confusing IMO.
>>> - a boot source would not be available in DT yet (though we probably
>>> shouldn't write it in /chosen/bootsource since we wouldn't know the
>>> proper path to it), e.g. USB loading, this is usually done via a
>>> proprietary protocol and/or tool (e.g. rockusb/rkdeveloptool for
>>> Rockchip) but no USB support yet in boot program or kernel (that was the
>>> case for a long time for RK3588 for example and I still have at least
>>> one device without the USB node described yet).
I don't think we want to go there. /chosen/bootsource should always point at
an existing node. If there is no node, the property shouldn't be there at all
until an actual hardware device tree node is created first.
>>> And additional argument for full-path: Barebox already uses that.
>>
>> Were there discussions with that, which could be used here?
>>
>
> @Ahmad, any piece of history you'd like to share here maybe?
I can't share history, as the addition in 2018 predates my involvement
with the project. I can share some thoughts and experiences though:
- Inside barebox, the bootsource is most often used for
- loading the correct environment:
For modern boards, barebox automatically looks up a GPT partition with the
barebox environment type UUID and loads it. As there can be multiple such
partitions,
it prefers the partition that is located on the original boot medium as
indicated
by the bootsource.
- setting a barebox update handler as the default:
barebox_update /mnt/tftp/my-barebox-image without further arguments will by
default
update the barebox binary on the original boot medium
- inside scripts. A common stanza is an init script that has:
if [ $bootsource = serial ]; then global.autoboot_timeout=30; fi
So the boot is delayed a little.
- If standardized, /chosen/bootsource could be useful to pass information from
first to second stage bootloader. E.g. on Rockchip, the information where the
system is booted from is in RAM that's only available early on in EL3.
Currently, barebox running as first stage copies that information to a place
where it's not clobbered by BL31, but we could in theory also have the barebox
prebootloader parse it and fix it up into the device tree it already passes
along to barebox proper.
- /chosen/bootsource can be used in userspace to detect if the system was
booted in recovery mode and to adapt accordingly.
- /chosen/bootsource can be used to load boot state from the correct boot
medium. This is useful when the exact same image is flashed to e.g. a SD
and an eMMC.
As Quentin mentions this is only about the first external boot medium.
This doesn't reduce usefulness much though, because systems increasingly
have a single boot medium anyway (e.g. eMMC boot partition + user area).
Cheers,
Ahmad
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
