I am working on L4T 34.1.1. I have Xavier NX SOM on a custom board. I had it booting earlier with cutom pinmux, padvoltage and device tree. Had some issues with the few interfaces but the board was booting.
Now it is observed that the board flash successfully, but hangs at some point while booting even with the older working setup. I was suspecting it was from rootfs as it was not being flashed properly since i could see kernel prints and then freeze. I used external rootfs and tried many things but seems the issue is not from rootfs. Apart from that no changes were done and I was able to run 32.x JP versions without any issues. Is there anything else changes from older versions to newer L4T 34.1 version? I am compiling stock kernel without any modifications. I have attached debug log and flashing log for reference.
If any additional info is required I can provide.
Jun22_dmesg_debug.log (47.7 KB)
Jun22_flash.log (59.7 KB)
Does it always hang in same error?
Not always the same error but everytime after some kernel prints.
Please set similar parameter to your kernel command line. This will lead us to where it gets hang.
console=none and keep_bootcon
Hi Wayne, it is observed that the issue is from device-tree. If I use stock dtb from nvidia it does boot. I have to use our custom dtb, so need to port device tree from 4.9 kernel to 5.10.
Can you share any document on how to port device tree for Jetson Linux 34.1?
What functionality are you asking for?
After debugging, suppose if I enable the UART node ‘uartc: serial@c280000’, the board does not boot. I want to use this UART for my radar application. With older 32.x releases I am enabling this node and it does work as expected. Is there anything else that is affecting this? Or is this UART being used elsewhere?( as per my knowledge it is not used).
Is same error reproducible if you use devkit to enable this uart node?
Sorry, I did not test it with devkit. Devkit isn’t available with us right now. But same setup worked with older releases.
Please at least follow above instructions I shared and give me the log with keep_bootcon in your kernel cmdline.