Change DTBS after new Kernel compiled

Hi,

I compiled a custom Kernel, where I enabled some modules. Is it necessary to replace dtbs as well ?
For instance, I added modules related to encryption algorithms, and even crypto offload. Should I change the DTBS is this case ?

If so, is it possible to do it without flashing the device entirely ?

Thanks

Hi,

If the new driver does not need to read parameters from device tree or need device tree to enable it, then it is not needed.

Some details might be useful to you…

Some devices in a system are “plug-n-play”. The device itself has a mechanism to self-describe, and there is a hot plug or similar system which can query that, and announce to drivers what and where the device is. Other devices cannot self-describe, and are directly on some physical bus address; these devices need a device tree fragment for that device. Other devices are generally not modified by adding kernel modules (or by leaving the original kernel Image features intact).

Did you start with the same kernel configuration as the existing system, e.g., tegra_defconfig or the “/proc/config.gz”, followed by adding something new? Or was there a significant change in previous drivers due to changed hardware, e.g., a new carrier board design? Unless you changed the carrier board, or added drivers for some device directly connected to a physical bus and having its own address, then you won’t need to change the device tree.

I’m asking as I am using new modules like XFRM and other IPSEC related, and the kernel is systematically crashing with this error:

[  210.579741] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020
[  210.588861] Mem abort info:
[  210.591752]   ESR = 0x96000004
[  210.594941]   EC = 0x25: DABT (current EL), IL = 32 bits
[  210.600407]   SET = 0, FnV = 0
[  210.603569]   EA = 0, S1PTW = 0
[  210.606799] Data abort info:
[  210.609764]   ISV = 0, ISS = 0x00000004
[  210.613728]   CM = 0, WnR = 0
[  210.616789] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000135f74000
[  210.623441] [0000000000000020] pgd=0000000000000000, p4d=0000000000000000

Can’t do match to decode this, but from what I saw in other posts, it is related to drivers :

If the error is really related to some drivers, should I replace the dtbs ?

Hi,

I don’t know much about the drivers you are talking about. But the error you are telling is a very common things in kernel world. If your driver is trying to access some illegal memory, then it will give this error.

It is all case by case. For example, the thread you are referring to is related to camera driver. But XFRM and IPSEC are obviously not related to camera at all… So it is pointless to refer to that post and try to modify device tree in camera sensor…

1 Like

Hi @WayneWWW ,

Is there anyway to debug that ? There is not much info, and that all we have.

Hi,

Since this seems not NV driver, I could only suggest you to check some linux online resources first.

I will also suggest that knowing your kernel configuration matched the existing configuration prior to making changes is really the first step. If you take a configuration which is incorrect for your Jetson, and make a modification, then even if your modification is correct it will fail. This is why I asked if you started with “tegra_defconfig”. Knowing if you only added modules, versus having changed the actual Image (the non-modular kernel) also matters, because then you can verify if the installation is correct or not (and incorrect installation might mix and match things not intended to go together in some cases). There is no definition of how it should behave when you mix things not intended to mix.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.