R35.1 kernel + Tegra19x SOC family configuration compile errors

I modified the kernel configuration by removing the tegra 23x SOC family setting and checking the tegra 19x SOC family via menuconfig.

I did this because I have a working custom board device tree which works fine with JP4.6 but causes problems with JP5.0.2 with the exact same hardware.

In order to clean potential issues I thought this action can help since I do use the tegra194 soc.

The problem is that the compilation fails.
I don’t have experience with writing device trees but I wanted to ask if there is any “quick” solution I can do about this or its part of a bigger internal issue?

compilation erros:
compilation_errors (38.0 KB)

If i leave the t23x soc family settings and still use my custom device tree then the kernel compiles successfully, but now I don’t know if all the changes this setting imported to my system are needed.

edit 1:
I’m asking this question because I noticed the errors are coming from the drivers and I think (not sure) that most of them are not related to my specific custom device tree. I need to edit the nvidia driver manually?


Someone else will need to answer, but thought you might have use for some information on this…

It isn’t unusual for older and newer Tegra SoCs to share some part of hardware. As an example, even though CPU and many other parts might change, there could be an exact match of something like a UART when migrating from older tech to newer tech. The use of both 19x series and 23x series might not be a mistake.

Additionally, device trees are not technically part of the kernel itself. This gets passed as arguments to drivers when they load and is a way to make the actual kernel code more modular. Without this, for example, you might find ten manufacturers placing the same component (and otherwise same driver) at ten different physical addresses would need ten different drivers. Only one driver is needed if that information is passed as an argument, but there is no need to build that fragment of device tree if the driver is not built, and so it is easy and convenient to have device tree compile tied in with kernel compile. You might see a family of trees built, with the correct one needing to be picked for the specific SoC or carrier board (building all of a family is not really an error; just install the one for your module and carrier board, or edit for your customization and use just that).

The 4.x series JetPack/SDKM uses a 4.x series Linux kernel, and the 5.x series JetPack/SDKM uses the 5.x series kernel. There is no guarantee that drivers or function calls to a completely new major release will be an exact match to the older release, but if they have the same device tree arguments, then there would be no need to change the device tree. On the other hand, just as a contrived example, perhaps the 5.x series kernel adds a new parameter, in which case the old tree would need something appended. I don’t know if if NVIDIA ported to the 5.x kernel such that the device tree remains unchanged or not, but there is every reason to believe that some change is needed since the drivers the tree is passed to have had a major revision. It seems from your error log that due to removing some of the configuration various header definitions are missing, and so I’d add that content back in and work on the device tree directly by going over what differences you have on your carrier board versus the dev kit carrier board.

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