I have been learning about device trees recently. When I was using Linux-4.9.307 on the official kernel website, I compiled a minimalist device tree that I wrote and ran the kernel in uboot. I mounted a normal root file system ramdisk and encountered an error message: Kernel panic - not syncing: Attempted to kill init! Exitcode=0x000000b, but when I use the latest stable version kernel on the official website, linux-6.4.8, I can enter the root file system normally. Then, I switched to a kernel with the same branch version, 4.9.310, and reported the same error as 4.9.307.
板子的设备树文件:board.dts (394 Bytes)
cpu设备树文件:cpu.dtsi (6.2 KB).
错误日志:putty .log (16.2 KB)
Uboot startup parameters and commands:
Hi 2297514590,
Are you using the devkit or custom board for Jetson Nano?
What’s your Jetpack version in use?
How do you configure for the “minimalist” device tree?
[ 0.884394] Unable to handle kernel NULL pointer dereference at virtual address 00000004
..
[ 1.313839] [<ffffff80083a9244>] tegra_read_chipid+0x1c/0x28
From your error log, it seems tegra_read_chipid causing null pointer kernel panic.
What is “linux-6.4.8”? Is that from our official L4T release?
If you could boot up with specific device tree and release, but having issue after update the device tree, I would suggest you could debug from comparing the difference in the device tree files.
I just used it to learn how to replace the device tree file for testing. The above CPU.dtsi and board.dts are the currently used minimalist device tree files. As for what you mean by “how to configure a minimalist device tree”, I don’t know what it means. Isn’t the device tree not required to be configured? Just compile and set the startup command in uboot,This is my uboot startup command and startup parameters:
Kernel official website linux-6.4.8:
There is no problem with the device tree itself. I have tried using the Linux 6.4.8 kernel and successfully mounted it on the randisk using the minimalist device tree file I wrote myself. However, neither Linux 4.9.307 nor 4.9.310 can enter the randisk
![2d31cce95a93dd4a8e570ea07923885|690x277]
What you’re talking about may be tegra_ Read_ Chipid caused the null pointer kernel to crash. I found this function in the Linux-4.9.307 kernel source code. Can you help me see where the problem is? I’m a bit confused
I can’t be of much use on this, but thought I’d throw some information in…
Think of the device tree as arguments passed to kernel drivers. For plug-n-play hardware there is no need, but a lot of hardware cannot “self describe”, and the device tree is often used to tell drivers about a physical address to find hardware at, combined with arguments to pass to the driver (and a list of compatible drivers). I do see in the OOPS for the tegra_read_chipid that this is in a call stack which also looks at clocks (the clk_disable_unused...). So for most of the hardware you would need to enable a particular power rail and clock prior to performing the tegra_read_chipid, so it is possible that this is failing because of lack of correct power rail or clock bring-up.
The part which makes this somewhat interesting is that you are using a kernel from mainline, and not the NVIDIA kernel source (at least that is what it appears to be since I see “The Linux Kernel Archives”). To be sure, much of the hardware is located in “out of tree” content. Whenever you build a kernel from NVIDIA and configure for that particular NVIDIA hardware you will see a lot of “_ddot_” macros in the path of files involved in the step. These are just “../” macros, which mean “the parent directory of the current directory”. Should you append enough of those, then you drop below the $TOP of the actual kernel source, and can then reenter into the out of tree content. This probably (I’m not certain) includes some of the power management and/or clocks (but actual content for this case is irrelevant, I’m just suggesting some drivers might be missing).
On top of all of this, because the device tree is essentially a set of arguments for specific drivers, if the particular kernel driver is one which is tuned by NVIDIA to work with their hardware, then even if the same driver is present the differences might mean it ignores or fails to correctly understand some device tree fragment. So one of the things you’d have to do is determine that every mainline driver (or really any non-NVIDIA release) is the same in how it handles that device tree fragment.
On the other hand, if you are using an actual NVIDIA kernel, and you can get this tree to work, then the tree is probably correct (for that variant of the kernel). If not, then there is almost no chance that the tree would work with the mainline kernel (which even if exact, would not work in that case; if modified, that mainline kernel would interpret the device tree differently).
So, you are using the devkit or custom board? and the Jetpack release?
You could just use default configuration for device tree and make sure it could boot up w/o issue. After that, you could customize device tree for your use case.
Jetson Nano is using K4.9, it would not work with K6.4.8 and you need to use the L4T release like R32.7.4.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.