Hi,
One test to try. Could you put jp5.0.2 kernel into jp5.1 environment and see if it bypass the issue?
If it is, then it could at least give us a clue that this issue is from kernel.
Hi,
I did put release_tag jetson_35.1 into jp5.1.1. The same issue occurs.
One question. When I do a uname -r for all release (5.0.2 and 5.1.1) I get 5.10.104-tegra. Is that expected?
I will also try JP5.0.2 with the kernel from JP5.1.1.
Malcolm
I get 5.10.104-tegra. Is that expected?
Yes, it is expected for now. It may change in later jetpack release in future.
I did try the JP5.0.2 with the JP5.1. The unit works properly. There is no kernel trap.
This would imply that the issue occurs due to the code up date from the apply_binaries rather than the kernel version? How do I change what is applied during apply_binaries? I would like to isolate the update is causing the problem.
Malcolm
Could you clarify what does that mean jp5.0.2 with jp5.1? Kernel image? UEFI? kernel module? DTB?
If you cannot describe it well, please tell us what got replaced on your side. I can use that to tell what might be the cause.
I extracted the Linux_for_Tegra for JP5.0.2 (Jetson_Linux_R35.1.0_aarch64.tbz2) and used the kernel source from JP5.1.1 (tag jetson_35.3.1).
So this test used JP5.0.2 environment but with the kernel for JP5.1.1. This combination works.
Malcolm
Hi,
Sorry to say that but this stuff still not specific enough to know where goes wrong.
Also, what things got replace after you āused the kernel sourceā? What binaries got replaced?
Just in case you donāt get my point.
What you just did only proves kernel may not be the issue. But we already have certain confidence about that because you already did similar test 18hours ago.
āJP5.0.2 environmentā has too many factors. MB1/MB2/UEFI/Pinmux/ ā¦lots of binaries could be the cause and didnāt narrow down it yetā¦
Summary:
Works: Linux_For_Tegra (Jetson_Linux_R35.1.0_aarch64.tbz2) with kernel tag jetson_35.3.1
Kernel Panic: Linux_For_Tegra (JJetson_Linux_R35.3.1_aarch64.tbz2) with kernel tag jetson_35.3.1
I changed to JP5.0.2 Linux_For_Tegra (Jetson_Linux_R35.1.0_aarch64.tbz2) previously I used JP5.1.1 Linux_For_Tegra (Jetson_Linux_R35.3.1_aarch64.tbz2) . The same kernel version was used jetson_35.3.1.
This test implies that the kernel works fine but using a different Linux_for_Tegra environment the kernel panic occurs.
Malcolm
Hi,
As I keep asking: What are the exact binaries you changed when you use ākernel tag jetson_35.3.1ā on jp5.0.2 BSP?
Kernel change includes kernel dtb/kernel image/kernel modules. Did you replace all 3 of them? Or you only replace 1 file?
Please confirm it so that I can make sure something right hereā¦
In both tests, I applied our patches to the kernel and device tree to tag Jetson_35.3.1. This will change some modules and result in a new dtb.
However, the kernel for both tests below are identical as the same kernel base is used and the patches applied:
Works: Linux_For_Tegra (Jetson_Linux_R35.1.0_aarch64.tbz2) with kernel tag jetson_35.3.1
Kernel Panic: Linux_For_Tegra (Jetson_Linux_R35.3.1_aarch64.tbz2) with kernel tag jetson_35.3.1
The difference in the test environments is the version of Linux_For_Tegra that is used. Summary, the image usingJetson_Linux_R35.1.0 doesnāt kernel panic, but Jetson_Linux_R35.3.1 we see the kernel panic.
The difference between the two is what apply_binaries.sh does to the kernel/rootfs files?
Malcolm
The difference between the two is what apply_binaries.sh does to the kernel/rootfs files?
No. it is notā¦
Before running apply_binaries, there are already lots of other bootloader binaries there.
Your test is not able to exclude them out. That is what I trying to say in previous commentsā¦
So you are sure the ko files and dtb files are also updated? That is the only thing I want to know here.
Yes. The .ko and dtb are updated in both tests. I see the changes in the running image.
Malcolm
Then I think the issue here is from the UEFI. Please use the UEFI from jp5.0.2 version and test.
Thanks. I was out of the office most of the day, but I will try tomorrow. and get back to you as soon as I have tried it.
Malcolm
Hi
The 5.0.2 bootloader has solved the kernel panic.
Do you have any ideas why the new bootloader is causing this problem?
Malcolm
We are still tracking it.
Hi WayneWWW,
Would you be able to update us on a release date with a fix for the UEFI for 5.1.1?
We need to have the over-the-air update capability which is not in the 5.0.2 bootloader.
Also, we have noticed that the fan doesnāt run after the boot is complete. It appears to be related to the 5.0.2 UEFI. Is there a way to reenable the fan, after boot, for our testing?
Malcolm
Sorry, this issue is still under investigation and ETA is still unknown.