Jetson agx orin make kernel5.1.10

I don’t understand why I get such error messages when I build kernel source code.

You need to start with a clean kernel source. Then you need to make particular configurations. You have no configuration so you are building absolutely everything. This includes conflicting software, software for IBM mainframes, software probably for the wrong architecture, software for floppy drives in the 1990s, software for fiber optic transceivers on the bottom of the ocean, so on. Kernels are definitely not compiled with just a “make” command to build everything.

To start with, what is the L4T release on your Jetson? You can get this with “head -n 1 /etc/nv_tegra_release”. Then you can go to that release, and the documentation and downloadable content will be specific to your exact release:
https://developer.nvidia.com/linux-tegra

There is documentation, and within that the section “Kernel Customization” shows you how to build via cross compile from a Linux host PC. It is also possible to build natively on the Jetson if you have enough disk space, but there are some changes in the procedure (cross compiling involves more tools and setup than does native compiling). Also, you can usually install any new kernel or kernel module with simpler methods than the documentation provides (the documentation centers on setting up to flash with that content, but most of the time you can simply work with file copies).

I will emphasize that sometimes features can be installed as a module instead of being integrated into the kernel, and doing so simplifies things greatly for installation, but not all content can be installed as a module (and not all content can be integrated).

If you can give more information on what you actually want to change or occur, then it might be easier to give advice or instructions. Be sure to include if you are building software on the host PC versus natively directly on the Jetson. If the latter, you will need plenty of extra disk space, but something like an external USB drive can work for that.

The reason I built the kernel was because I had an error compiling the driver source on jetson,

My driver has worked correctly on jetson_linux_r35.3.1 1_aarch64(kernel 5.10.104), but my current version is R35.4.1(kernel 5.10.120).

dmesg:root@tegra-ubuntu:/# [ 2511.597607] xpcie_dev: disagrees about version of symbol module_layout

The kernel has to start with the correct configuration before building. In this case you’d have to start with a copy of the existing kernel’s configuration, and then use a dependency-aware configuration editor to add the driver you are interested in. The problem is extremely likely to be one of having a lot of conflicting configuration details. You must also be careful to correctly choose CONFIG_LOCALVERSION to avoid issues like module layout incompatibility.

This is a bit more detail around that topic (there is some repetition in this since it is a more general description of the topic):

Unlike most software you might compile the kernel is a large collection of separate programs (mostly drivers) that must work together, and yet the kernel source contains driver source for many things which won’t work together. Examples might be compiling for a driver that is architecture dependent when you are using a different architecture (e.g., it might contain assembler); or one driver which supersedes another driver and changes the API; plus drivers you simply cannot use, e.g., a 100Gb/s or faster fiber backbone NIC using a proprietary bus.

Of all of the above, the points to think about which are most relevant:

  • The build target tegra_defconfig is almost the exact configuration Jetsons ship with. The CONFIG_LOCALVERSION string would also have to be set to “-tegra” for this to be a shipping system’s configuration.
  • The running system produces a compressed copy of its configuration in this file, and except for CONFIG_LOCALVERSION, this would normally be the same as tegra_defconfig, but there are exceptions:
    /proc/config.gz
    (this isn’t a real file, it is a driver in RAM pretending to be a file, so you could copy it somewhere else and `gunzip it)
  • Many configuration items can be added as a module, which far simplifies installation and many details if and only if you have started with a fully matching configuration (including CONFIG_LOCALVERSION). Once you change anything integrated into the kernel itself (not module format) everything has to be installed.
  • You don’t have to remove the old kernel. You can create a second boot entry for backup. Your new entry could be the default first entry. Then you could pick the backup if things go wrong. This only matters if you’ve changed the main kernel Image; adding new modules is relatively low risk and won’t require a second boot entry. All of this can be done without flashing since the official docs revolve around changing the flash software with new content and then flashing.

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