Management of machines and device-tree

[QB4-dev]

It's Enchancement proposition.

VisionSOM boards main differences are;

• boot medium: SD/EMMC/NAND
• murata WiFi/BT module presence

I am not sure if almost identical(only model property is different) device-tree files like

sls16y2_792c_256r_256n_0sf.dts
sls16y2_792c_512r_512n_0sf.dts

or

sls16y2_792c_256r_256n_1wb.dts
sls16y2_792c_512r_512n_1wb.dts

are neccessary. We have identhical device tree for this board pairs. Real difference between NAND versions of somlabs boards(NAND block geometry) is placed in machine .conf files which can share same device-tree file, but have different NAND geometry.

I've tried to create my own meta-somlabs layer, but it's not complete. I've tried to go follow Toradex philosophy:
https://developer.toradex.com/device-tree-customization#iMX_6ULL_based_Modules

I've created following files:

file	purpouse
visionsom-6ull.dtsi	common definitions for visionsom6ull boards
visionsom-6ull-wifibt.dtsi	murata WiFi/BT module pinconfig
visionsom-6ull-nand.dtsi	module with NAND memory
visionsom-6ull-nand-wifi.dtsi	module with NAND memory + WiFi/BT
visionsom-6ull-emmc.dtsi	module with EMMC memory
visionsom-6ull-emmc-wifi.dtsi	module with EMMC memory + WiFi/BT
visionsom-6ull-sd.dtsi	module with SD card
visionsom-6ull-sd-wifi.dtsi	module with SD card+ WiFi/BT

and thats all.
VisionSOM boards are not machines itself. They need carrier boards to become functional machine, so for VisionCB-STD I've made following .dts files:

file	purpouse
visioncb-std.dtsi	common definitions for VisionCB board
visioncb-std-visionsom-6ull-nand.dts	VisionCB with NAND SOM
visioncb-std-visionsom-6ull-nand-wifi.dts	VisionCB with NAND SOM + WiFi/BT
visioncb-std-visionsom-6ull-emmc.dts	VisionCB with EMMC SOM
visioncb-std-visionsom-6ull-emmc-wifi.dts	VisionCB with EMMC SOM+ WiFi/BT
visioncb-std-visionsom-6ull-sd.dts	VisionCB with SD card SOM
visioncb-std-visionsom-6ull-sd-wifi.dts	VisionCB with SD card SOM + WiFi/BT

I think that these files later in time should become a part of kernel in /arch/arm/boot/dts and that is the main reason why the number of them must be as low as possible.

Content of single .dts files looks like:

/dts-v1/;

#include "visionsom-6ull-nand-wifi.dtsi"
#include "visioncb-std.dtsi"

/ {
        model = "Somlabs VisionSOM6ULL nand WiFi on VisionCB-STD";
        compatible = "somlabs,visionsom6ull","somlabs,visioncb-std","fsl,imx6ull";
};

Then in machine .conf file we should have:

KERNEL_DEVICETREE = "visioncb-std-visionsom-6ull-nand-wifi.dtb"

and KERNEL_DEVICETREE value should be somehow provided to u-boot environment as default fdt_file - I still didn't managed this, but I like your trick with symlinking real device-tree to file wanted by u-boot.

Please let me know what do you think about this idea

Now I am building your somlabs-image-example-visioncb-6ull-std image from examples repo to test it on my boards.

Best Regards

[myfreescalewebpage]

Hi @QB4-dev

You're right, except the name I have given, they are identical!. This is to simplify the management of the symlink, e.g. the dts file is the same than the machine name for all the machines in the layer.

I've tried to create my own meta-somlabs layer

You can simply use the meta-somlabs layer and create an other layer "meta-qb4" with higher priority that override the wanted files/settings. As shown in the meta-somlabs-example I have done. Particularly, it is possible to rewrite all the dts to match you own board. Just need to write a bbappend file to do that, it's Yocto power! This as the advantage to follow the enhancements of meta-somlabs if some are performed in the future.

for VisionCB-STD I've made following .dts files

Look at my VisionCB-STD example I have made some dtsi to simplify including the various parts of the board (USB, Ethernet...) Anyway, this is only my philosophy today. I think for some real projects the best is to have only one dts file with every thing in it. This clearly simplify reviews. Too much dtsi files is not a good idea according to me.

I think that these files later in time should become a part of kernel

I don't think so. First, do you speak about the SOM or the carrier board ? The carrier board has already 3 different versions, with differences on the dts (=> 3 dts per SOM variant ?). You should also think to VisionCB-IND with and without HDMI. Then, who will be in charge to push this in the kernel and support future modifications/fixes when they are required ? I will not. Moreover, today I know there is mainline kernel (from Linus Torvalds), linux-fslc, linux-imx, and linux-fslc-imx variants, so much work to do. Finally, BCMDHD driver is removed in the last Linux version, so you need to work on old kernel versions.
To be honest with you I don't understand why dts files of some specific boards are integrated in the kernel (except it's good to have some examples to create your own).

should be somehow provided to u-boot environment as default fdt_file

That a nice solution I have already used on other SOM, but I haven't study it at the moment here.

This is interesting subject, I would like to keep the issue open so it's possible to continue the exchanges. I have just renamed the issue to be more general.

Regards,
Joel