[U-Boot] [PATCH v2 1/1] board: raspberrypi: add serial and revision to the device tree

[Anton Gerasimov]

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[1] 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 
> environment.
>
> This allows users to select which kind of DT they want passed to the 
> kernel.
>
> For example, see dt-edit.* at:
>> http://nv-tegra.nvidia.com/gitweb/?p=3rdparty/u-boot.git;a=tree;f=arch/arm/mach-tegra;h=d9a17eec4f0271cdc3932f0cee8c39fb17197a0b;hb=l4t/l4t-r27.1 
>>
> ... and MEM_LAYOUT_ENV_SETTINGS in:
>> http://nv-tegra.nvidia.com/gitweb/?p=3rdparty/u-boot.git;a=blob;f=include/configs/tegra210-common.h;h=156b280a00f37f811c96d0006fe2b87bdeb07e74;hb=l4t/l4t-r27.1 
>>
>
> 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 
> too.
>
> [1] NVIDIA Linux for Tegra.


Yes, that's something implemented in linux-raspberrypi [1] only. My use 
case ([2], [3], or more specifically [4]) 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.

[1] 
https://github.com/raspberrypi/linux/blob/rpi-4.19.y/arch/arm/mach-bcm/board_bcm2835.c#L29
[2] https://github.com/advancedtelematic/meta-updater/
[3] https://github.com/advancedtelematic/meta-updater-raspberrypi/
[4] 
https://github.com/advancedtelematic/meta-updater-raspberrypi/blob/master/recipes-bsp/u-boot-otascript/u-boot-otascript/uEnv.txt