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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
