change device-tree at runtime

[maggu2810]

Hello,
I am using a custom distribution based on "kirkstone-l4t-r32.7.x".
I am using A/B layout with mender.

I use a custom hardware that provides a connector where cameras can be plugged.
The camera and the respective serializer / deserializer needs to be part of the device tree.
The machine itself is always the same the device trees just differ what cameras are connected.
I could define different machine configurations and every one uses its separate device tree but I am thinking of another approach.

I already created a device tree without camera specific parts and an overlay with the camera relevant parts.
The base device tree is setup in the Yocto machine configuration and built. I flashed the image and all is working -- for sure without the camera specific parts.
Now, for further testing I used the extlinux.conf mechanism to provide kernel + initrd + device tree from file system.
First I setup the configuration, put the files into the FS and restarted the system to check if the extlinux.conf mechanism works.
It did.
After that I used
dtc -O dtb ... overlay-with-camera-stuff.dts to generate a dtbo from my DT overlay source file.
and ftdoverlay -v -i the-dtb-created-by-yocto-build.dtb -o dtb-with-cam.dtb dtbo-generated-by-command-above.dtbo
I copied that file on the target and modified the extlinux.conf to use that device tree.
After rebooting the system all is working as expected and also the cameras are working.

My next test has been to load the overlay at runtime using a kernel patch that can be found at several places that provides a mechanism in configfs. Loading the overlay works, also the modules are loaded automatically but the v4l devices are not created. As this mechanism is not supported by mainline kernel and also have known bugs, I would prefer another mechanism.

What I am thinking about:

• The system itself "knows" what cameras are connected and so which overlay needs to be applied.
• The image initially uses the base device tree only and writes it into written to the kernel-dtb / kernel-dtb_b
• The rootfs of the image contains dtb files for all valid camera variants (generated e.g. by ftdoverlay of base and overlay).
• At runtime the DTB partition of the current started system is read out (e.g. dd), compared to the expected DTB (based on the knowledge with camera variant is attached), and if not match the correct DTB is dd'ed to the partition and a reboot is triggered.

Questions:

• How should a recipe looks like that generated mutliple DTBs using the "base device tree" specified in the machine configuration and the overlay files.
• I assume the generated DTBs needs to be signed because the partition are marked oem_sign.
• How to read and write the partition (dd?)

I know that writing to the DTB and a power loss is critical but I assume the time slot is very short.

Are there better approaches without generating a machine for every possible camera variant?

-- update --

I read https://github.com/OE4T/meta-tegra/wiki/Using-device-tree-overlays but for "Runtime application of overlay" the used L4T version is to old.

[madisongh]

With the L4T R32 series, the answer may depend on which SoC you're targeting, but NVIDIA has a way to modify the device tree at boot-time by including an EEPROM either on your camera module or on your carrier board. It's somewhat documented in the developer guide. I used it on a TX2-based project some year back to handle differences between revisions of our hardware, and it worked fine.

Otherwise you could probably hack cboot (for T186/T194) or u-boot (for T210) to use some other mechanism to distinguish between your different hardware models and make modifications in a similar way to NVIDIA's 'plugin manager'.

[maggu2810]

Currently it is based on conf/machine/jetson-xavier-nx-devkit-emmc.conf.
Can you point me to the section in the developer guide or share some further information how you did it?

Do you know if it will work to dd to the specific mmcblk partition? How to generate the content that can be dd'ed? Is it just a signed dtb? I also read https://github.com/OE4T/meta-tegra/wiki/Secure-Boot-Support#kernel-and-dtb-encryption so I assume as I do not yet set one explicit I used a null key.
I also assume the files that are part of the tegraflash tar.gz are already signed or not (so ready to use). Is this correct?

Mender writes the partition on its update process implementation, too. So at least it should be possible. I just need to find the mechanism used.

[maggu2810]

I assume I need a bup_payload that contains the kernel-dtb only and then I could run tegra-bootloader-update using the slot suffix of the current slot (update kernel-dtb of active and not of the inactive slot),
Is this correct?
The commands can be executed by a script easily.

Now I have to figure out how to generate such a bup_payload.
After building the image and extract the tegraflash archive I found generate_bup_payload that generates a kernel_only_payload that contains kernel and kernel-dtb. I assume I need to check how the script (and the called ones) are working and if it is possible to generate one for kernel-dtb only.
The next step (if it will be reached ever) to check how a custom kernel-dtb only bup_payload could be generate by a bitbake recipe on build time that depends on the DTB generated by the kernel build.

-- update --

I comment the two lines

ENTRY_LIST[kernel]=""${signed_dir}"/${kernel_image_base}_sigheader.img.${signed_ext} kernel ${bsp_ver} 0 $_common_spec;"

in l4t_bup_gen.func and called ./generate_bup_payload.sh. This generates me a kernel_only_payload file that contains the kernel-dtb only (it is about 399 KB in size - I assume it fits to the partition size).

[madisongh]

Can you point me to the section in the developer guide or share some further information how you did it?

I don't think there is a step-by-step guide to this in the docs. There's a mention of the plugin manager in a couple of places, a separate document in the downloads area with the EEPROM format (we have a tool that understands that format), and the plugin manager code in the cboot sources. I worked it out from those.

Do you know if it will work to dd to the specific mmcblk partition? How to generate the content that can be dd'ed? Is it just a signed dtb?

For the kernel DTB, yes, it's just the signed binary. And if you're using the Android partition-style method of booting, loading the correct, signed, DTB into the kernel-dtb partition(s) is all you need.