Is Kernel Rebuild Necessary with a new Pinmux?

[don.harrison1]

I have to admit, I am really struggling with the bring-up of a custom carrier. Any help would be appreciated.
I based the new carrier on the DEV KIT, and I have built a new pinmux file with the .XLSM tool. The most significant change was from DP → HDMI. I also have one less USB and one more PCIe.

Is it necessary to rebuild the kernel? I admit not really understanding the device tree concepts.

Thanks for your help

[linuxdev]

No, the device tree is “more or less” independent. The following might give you a feel for the topic.

There are self-reporting devices, ones that are plug-n-play. These won’t need a device tree (firmware). Many devices sit on the physical bus, and cannot self-report their capabilities. One must tell the drivers where to find them, and sometimes various arguments to pass to the drivers. For non-plug-n-play devices you can think of the device tree as arguments or environment which the driver sees as it loads. One common use is to provide a physical address (things sitting directly on the bus use a physical address, not a virtual address) and other arguments, among which is a statement of what driver(s) the tree node is intended to work with. If the node is not related to a driver, then that driver simply ignores it.

Consider that the list of drivers or features being compiled into the kernel is also a list of possible device tree node requirements. Some devices, e.g., USB or PCI, won’t need a tree node. Many others will, and so those that might have a requirement more or less share the kernel build configuration. Why build a node if the kernel build does not include the relevant driver? Device trees are data passed to parts of the kernel, but are not directly part of the kernel; device trees do share kernel configuration, and as a convenience, when building a kernel, one also has the option to build the device tree based on that configuration. To emphasize, the device tree in kernel build is a case of shared configuration, not shared kernel code.

If you have not added a new kernel feature or driver which requires a new device tree node, then you don’t need this tree during kernel build, and if building a tree which uses drivers you already have, then you don’t need to build kernel code. It is also quite common to separate any kernel build and device tree build and to not bother changing them simultaneously even when drivers and features do change since if most of the configuration before and after will match, then you would only need to edit one node of the tree…the rest of the tree would remain the same.

The PINMUX spreadsheet macros build a tree after you’ve set up something in its configuration. It just happens that the config you are using will start with the default (matching the default kernel features), and that the edits will change just some particular tree node. If your kernel already has whatever driver or feature the .xlsm changed to provide, then why build a kernel? You already have that part in place.

The dtc program (“device tree compiler”) goes back and forth between the binary format (a .dtb suffix on the file) and the source format (the .dts suffix on the file). It is easy to install to manipulate via “sudo apt-get install device-tree-compiler”. It also conveniently occurs that a copy of this is available in the kernel source code, and if you build a device tree target, it builds the dtc app before working on the tree.

If you have a .dtb binary file, and wish to see its human-readable content:
dtc -I dtb -O dts -o extracted.dts <the original file name.dtb>

If you have edited the .dts, and want to make it into a binary:
dtc -I dts -O dtb -o new.dtb <input source file name.dts>

Since this is only data passed to the kernel, you can easily take the macro output and just name that for boot configuration.

Take a look at “/boot/extlinux/extlinux.conf”. You will find a device tree specification with the key/value pair “FDT” (flattened device tree, the binary .dtb format). As an example, here is one boot section in extlinux.conf:

LABEL primary
      MENU LABEL primary kernel
      LINUX /boot/Image
      FDT /boot/dtb/kernel_tegra234-p3701-0000-p3737-0000.dtb
      INITRD /boot/initrd
      APPEND ${cbootargs} root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 mminit_loglevel=4 console=ttyTCU0,115200 console=ttyAMA0,115200 console=tty0 firmware_class.path=/etc/firmware fbcon=map:0 net.ifnames=0 usbcore.usbfs_memory_mb=256

We could avoid losing the old boot entry and instead make a second boot entry (you could delete the second boot entry later if you are successful and are certain things like kernel update won’t break the edited entry):

LABEL primary
      MENU LABEL updated tree same kernel
      LINUX /boot/Image
      FDT /boot/dtb/kernel_new_tree.dtb
      INITRD /boot/initrd
      APPEND ${cbootargs} root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 mminit_loglevel=4 console=ttyTCU0,115200 console=ttyAMA0,115200 console=tty0 firmware_class.path=/etc/firmware fbcon=map:0 net.ifnames=0 usbcore.usbfs_memory_mb=256

LABEL original
      MENU LABEL original kernel
      LINUX /boot/Image
      FDT /boot/dtb/kernel_tegra234-p3701-0000-p3737-0000.dtb
      INITRD /boot/initrd
      APPEND ${cbootargs} root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 mminit_loglevel=4 console=ttyTCU0,115200 console=ttyAMA0,115200 console=tty0 firmware_class.path=/etc/firmware fbcon=map:0 net.ifnames=0 usbcore.usbfs_memory_mb=256

Or you could just edit the “FDT” line and stick with the default boot entry, but name the new .dtb. There is no reason you’d have to keep the original .dtb file name, the new tree could use a new name; the old tree could be left in place as a reference, and it would not boot unless the FDT key/value pair is changed back to point at it.

There are some differences if you have burned security fuses.

[don.harrison1]

This is great, thanks for the detail at my level. I will continue onward!