I am using the Jetson TX1 with L4T version 24.2.
I need to connect several serial devices to the DEV board so i need to use also the J21 serial port UART.
The problem is that because of the console definition of the J21 port I can not restart the Tegra while the serial device is connected. this is a critical thing because we are going to encapsulate the Tegra into a custom shield so we want be able to connect/disconnect the serial device on each restart. Please help what can i do to solve the problem?. BTY i do not actually need tho console option. how can i overrun it?
Serial console is easy to disable once you reach the Linux kernel. You’d just remove the extlinux.conf APPEND items for this feature. Unfortunately, this isn’t the problem. The problem is that this serial port is more or less hard wired into the u-boot boot loader code, and this operates prior to the kernel ever starting. You’d have to modify u-boot to avoid an issue from activity stopping boot (activity on that port would be mistaken for a keystroke and u-boot would think you want to halt boot and enter its command line).
Thanks very much for the reply.
So, how can i modify the u-boot to not using this serial as a console?
or is there any another way to use both console option and connect serial device without having the “Restart issue”
Please note that my knowledge in linux is limited (I am a windows expert…)
Rewriting part of the boot loader would be a difficult task. The real workaround is to not send any data to the serial console during boot. If you can pause whatever sends data from the non-Jetson to the Jetson, then it won’t halt. Normally the non-Jetson would be a serial console terminal program and it would only send when a key is hit on a keyboard…not halting is as simple as not touching the keyboard. In your case you will probably find the simplest solution is to “pause” or disable your host application during the reboot. Do you have the ability to stop your serial port application during the reboot?
Actually the “non-Jetson” is not a program but a COTS Device (GPS\INS card) in which i do not have any control. basically it should not send any data during boot. on the Tegra side for sure no code is running during boot (my code)
from your analysis and my experience, I can assume that while reboot, the Tegra sends some data on the serial port for recovering any connected console device but my device “thinks” it is a “legal” attempt to connect and send a NACK or connection error message that can cause the tegra to think that a console device is connected.
Yes, the start of boot results in output to the serial console, so if your device listens during that time there is a strong possibility that it would also reply (which is a mistake that would halt during u-boot stage).
All steps to work around this are essentially the same…stop a keystroke from appearing during u-boot stage (even if it isn’t really a keystroke).
One method you’ve thought of already…edit u-boot itself and remove its serial console function. Probably not a good idea, and not easy.
Another method is to disable the COTS device until something triggers connecting it. An example would be using a GPIO which would only assert upon kernel load (once kernel loads it’s easy to disable serial console function simply by not adding the option in the command line in extlinux.conf). The GPIO could be used to enable the power going to the COTS device.
If the reboot can be sensed in any way, then you could simply put a solid state relay in with a short delay upon detecting power, e.g., 5 seconds.
There may be something in the u-boot environment which can be set to disable halting to u-boot command line, but I do not know what it is (or even if such a thing exists…it it does exist, then this would mean extlinux.conf is your only interaction with u-boot other than flashing once that environment is set up).