please refer to developer guide, did you applied Boot Time Reduction to disable logs?
you may examine the uart definitions, using $ dmesg | grep THS to check the mappings.
and, please also disassembler your dtb file into text file, $ dtc -I dtb -O dts -o output.txt tegra210.dtb for examination.
Also, from the host system ( at path: nvidia/nvidia_sdk/JetPack_4.2.1_Linux_GA_P3448-0020/Linux_for_Tegra/kernel/dtb) when I run the command: dtc -I dtb -O dts -o ou tput.txt tegra210-p3448-0002-p3449-0000-b00.dtb, I get an output which is attached here: output.txt (279.4 KB).
As seen from the output.txt file, I see the 70006040 component has status = “okay”.
Any suggestions as to how to approach this further?
that seems correct,
did you also modify p3448-0000.conf.common file to change the command-line? it should by default output bootloader logs via uart-b.
here’s an external page for your reference, Jetson Nano Style - Serial Console - JetsonHacks.
Even if we don’t modify the above line, the result is the same: no preboot/bootup UART logs.
We believe the nvgetty is trying to start a console on /dev/ttyTHS1. So our next step is to disable this service at rootfs (using chroot) and then flash the system again. But in any case, we should have seen those bootloader logs which you provided, right? We do not see them at all. The result is always the same: no uart preboot/boot-up logs, only a tegra-login prompt on boot.
Is there something else to check/change? Please let us know.
We believe that the electronics is correct, otherwise we wouldn’t have been able to view the tegra-login prompt.
I’ll suspect it’s hardware design issue,
you don’t need extra configuration for bootloader logs on Nano DevKits, it just setup serial console via pins 203/205 and enable serial port utility to communicate with baud-rate 115200/8n1.
please refer to Nano’s device tree,
there’re three uart ports and you may also use uart-a to output logs.
Thanks for the dtsi file contents. We thought that if there was a hardware issue, we would not be able to view anything on the host console, or random characters. But we do see the following after a boot (during the boot, nothing is visible on the host console):
At the moment, we are unable to install Jetpack 4.6.1 on the host, but we are working on it. But we tried with Jetpack 4.4 and it didn’t work. Besides, we are sure that in the past we did obtain UART logs on Jetpack 4.2.1, but we unfortunately don’t have the design anymore. In that design the TX wire from the TTL to USB was probably directly soldered to either pin 203 or 236, but this whole setup was susceptible to physical damage. At the current moment we have better points on our custom carrier board to which the cable can be soldered, and these points connect to the Nano pins via the routes. So essentially, we are bringing out pins 203/205 of Jetson. But since we are not able to get the uart debug logs now, we were just wondering how to make sure that in kernel/device tree, the UART debug port is indeed mapped to pine 203/205. But like we discussed, as per you that seems to be the case, right?
Now we are trying to solder the TTL to USB cable to pins 236/38 on Nano. In that case what exactly should change? To bring the UART debug logs to port with pins 236/38 ?
Just in this file: hardware/nvidia/platform/t210/porg/kernel-dts/tegra210-porg-p3448-common.dtsi, the 70006040 and 70006000 should be swapped?
you don’t need changes.
as you can see per my previous comments #12. it’s device tree definition to have uarta route to debug port.
it’ll output logs with J44 on Nano-A02, or J50 on Nano-B01. we’ve also double confirmed with DevKit to obtain the logs,
it should be your hardware issue, please review your board design,
Okay, I understand now, thanks for clarifying, and sorry for the confusion. But let me put the question in another way:
What should I exactly change in order to make pins 203/205 the UART DEBUG port? I see by default the UART DEBUG port is on pins 236/238. Or in other words, I want UART A and B in the device tree to be swapped. This is because of the limitation of soldering that we now have, which is: we can only bring out pins 203/205 via soldering to TTL to USB converter. We want the UART DEBUG logs now (on pins 203/205), we don’t care about the console anymore.
Thank you for your support. We tried the above method, but still didn’t get the logs. It is the bootloader logs we needed, and we always received the logs on B01, just not on our carrier boards, so it was a matter of changing UART ports only.
So at the moment, we soldered the pins 236/238, instead of 203/205. And we have the UART logs now. We can close this topic, and I can continue pursuing our main issue on this link: