[U-Boot] [PATCH v2 1/1] board: raspberrypi: add serial and revision to the device tree
tossel at gmail.com
Wed Feb 20 18:26:50 UTC 2019
On 2/20/19 6:15 PM, Stephen Warren wrote:
> On 2/20/19 10:04 AM, Alexander Graf wrote:
>> On 02/20/2019 05:59 PM, Stephen Warren wrote:
>>> On 2/20/19 5:09 AM, Anton Gerasimov wrote:
>>>> Raspberry Pi bootloader adds this node to fdt, but if u-boot script
>>>> doesn't reuse the tree provided by it, this information is lost.
>>>> Revision and serial are displayed in /proc/cpuinfo after boot.
>>> Are these properties documented in the upstream Linux kernel in
>>> Documentation/devicetree/bindings/? If so, this patch is fine. If
>>> not, we should not merge it, since we don't want to pollute the DT
>>> with non-standard properties (or: add this to the upstream kernel DT
>>> documentation, and then apply this patch once the doc update is
>>> approved upstream).
>> Hm, it almost looks like it's a downstream hack. Unfortunately as
>> U-Boot we're in this really weird place where people may want to use
>> it to load downstream kernels.
> For similar things in L4T's downstream fork of U-Boot, what I've
> done is this:
> a) U-Boot implements the code to set various DT properties, or copy
> them from the DT provided by whatever-runs-before-U-Boot to the DT
> U-Boot provides to whatever-runs-after-U-Boot.
> b) Whether U-Boot actually does this set/copy operation is determined
> by the value of an environment variable.
> c) The default U-Boot environment enables all set/copy operations
> required by L4T.
> d) If someone wants a "pure upstream" DT passed to the kernel, they
> can edit the environment to disable those operations, and save the
> This allows users to select which kind of DT they want passed to the
> For example, see dt-edit.* at:
> ... and MEM_LAYOUT_ENV_SETTINGS in:
> I'm pretty sure the value of fdt_copy_node_paths was longer in some
> release, but I don't remember which one, so can't quickly find it. And
> yes, the links above are about copying nodes between DTs, but you can
> imagine a similar flag env. var. for the feature in this current patch
>  NVIDIA Linux for Tegra.
Yes, that's something implemented in linux-raspberrypi  only. My use
case (, , or more specifically ) for u-boot on Raspberry Pi
includes letting the user update the device tree as a part of their FIT
image, so using the device tree provided by the primary bootloader would
not quite work here.
But I understand that it might not quite belong to the u-boot code base,
so this functionality might continue its existence as a patch applied in
meta-updater. As for polluting the device tree, it just imitates the
pollution already done by the proprietary Raspberry Pi bootloader, so I
don't think it should be a problem.
More information about the U-Boot