As the title describe, we cannot get internet via cable in the real-time kernel. But we can still get the internet in the primary kernel. How to solve the internet problem?
Just in general, whenever you put a new kernel in, you must be sure you start with the original kernel’s configuration. If you don’t, then you are possibly removing important drivers. Secondarily, if the kernel is sufficiently different, possibly you need device tree changes, but that does not seem likely for your case. What is your “uname -r” output? Did you match the existing kernel’s configuration before installing it? Note that with changes that are as drastic as an entirely different kernel you must reinstall not only the kernel, but all modules.
Thank you for your reply!
Our output of "uname -r " is “5.10.104-rt63-tegra”, which I think means that we have installed real-time kernel successfully. I think we have match the existing kernel’s configuration with last kernel. Because our NX need to boot from Nvme, which is defined in the “/boot/exlinux/exlinux.conf”. And before we change it, we even can not enter the system, which you can find the detail in Why we can't update our NX system kernel by replacing the Image in /boot/? - #3 by DaneLLL.
To be frank, I have not learned Linux systematically. So I can’t make sure what is the function of device tree and whether it can affect the connection of wired network.
So I still don’t know what is the possible reason of the wired internet loss.
And now, we use primary kernel to use internet to build the environment we need. And we find that the environment exist even if we change the image to real-time kernel. So our work can continue. But we still want to know why even the wired-internet can be affected.
Because of your “uname -r”, this means all modules have to be built against that configuration, and must be placed at:
/lib/modules/5.10.104-rt63-tegra/kernel
(a subdirectory of that)
Compare the list of modules in the old location, which is probably at:
/lib/modules/5.10.104-tegra/kernel
Is something missing, especially in network modules?
Regarding device tree, some devices are “plug-n-play”. Those devices have a method of self-describing in order for drivers to decide which one works, and also addressing them (e.g., USB and PCI). Many devices are not plug-n-play, and the drivers have no idea where there are or what they are, nor what arguments to pass to the kernel. You can think of the device tree as a set of specifications which drivers see as a means to find hardware, and which driver to use, along with arguments. If a network device does not have the equivalent of a plug-n-play announcement ability, then the device would do this. Changing a carrier board and using different wiring layout is the biggest example of needing a device tree change.
Also, drivers ignore device tree nodes not intended for them. If the driver itself changes, and the previous driver understood a device tree, it is possible that the new driver does not. In that case the device tree might need modification to work with the new driver. An example would be a major API version change, in which the passing of arguments is now substantially different.
You might find this useful:
https://forums.developer.nvidia.com/t/how-to-fix-xorg-conf-in-jetson-orin/229155/12
Incidentally, the device tree is not actually part of the kernel. However, valid arguments to pass to a driver depend on that driver, and so the device tree is distributed with the kernel. Usually one just adjusts an existing device tree rather than building one from scratch if there is some change, and quite possibly you don’t need a device tree change. However, if the RT kernel changes something related to networking, then perhaps device tree is involved. I’d ignore device tree to start with.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.