Hi,
From my understanding, the UEFI default baud-rate of the debug UART is 115200.
I want to recompile the UEFI (Downloaded the sources) with different baud-rate (9600 or 230400)
Where can I find the file to replace it?
Hi,
What’s your reason to change the UEFI baud-rate?
Thanks
Hi,
In my project, I am working with Jetson NX Xavier, connected with DJI PSDK via UART and Ethernet to DJI Matrice 300 RTK.
I have an issue that the drone sends data to the UART at power startup and somehow, I don’t know why, the NX goes straight to it’s boot screen ( like when you enter a value before the kernel is up) and I see like a lot of data is “garbaging” the UART even tho the DEBUG UART is /dev/ttyTCU0 and the drone is connected straight to /dev/ttyTHS0
That’s why I want to change the baudrate of the UEFI at startup so the drone won’t be able to “talk” to me.
When I raise the drone’s UART baudrate to 230400 the problem stops, but I can’t really work in this baudrate.
Found a topic about it here:
Hi,
Is There a possibility to receive the same binary but for different L4T?
I am using L4T 35.1.0 with JetPack 5.0.2
Something which might matter is a description of a common issue many people have. Some serial UARTs are free to use for any purpose, while others are bound to a serial console. There is a distinction to be made between time in boot and time within the Linux kernel which I’ll add, but I’ll start by describing the Linux side first.
Any “/dev/ttyTHS#” or “/dev/ttyS#”, or any serial port in general, will be listed with a group ownership (use “ls -l”) of either console or dialout. If the group is dialout, then you are free to use it any way you want. If the group is console, then this is a serial console and any bytes going to it are the same as typing in a console. Some bytes might come back as well, e.g., randomly sending bytes to a console might show the error from a shell not understanding what your bytes mean. To use such a serial UART for your own purposes it is mandatory that the serial console program not bind to that UART. At times it would seem to work when using such a port, but you would end up with failure in the end.
The above was when Linux runs. There is also the a boot stage in which a serial console can be used to interrupt boot. Linux has not yet started, and so this is set up in the boot code itself and regardless of what Linux is set up for, that code is independent. Removing a serial console from a UART in Linux does not remove the serial console from the boot stages. Sending a byte to a serial console at the wrong moment during boot is the same as hitting a key to interrupt boot, and I believe this is what you are seeing. There is no baud rate change that would fix this.
I do not know the specific change or debug step to verify if “/dev/ttyTHS0” in Linux corresponds to a serial console within the boot stages, but I’d say it is almost certain to be what is happening. What you really need is a way to unbind serial console from that UART during boot stages. If the baud rate changes this, then it is because the timing of pressing the key on the keyboard for interrupt has changed. As soon as something happens which sends a byte at the moment when interrupt is available boot will halt again. You’re just changing timing and getting away with your application on a console more often. Maybe @DavidDDD has information on verifying what UART is used during boot and whether this might correspond to “/dev/ttyTHS0” when fully booted.
Since this is from a DJI I have to assume that this uses its own third party carrier board, and thus the device tree would differ from a dev kit. If at any time there was some sort of flash or update which put the dev kit device tree back in, or boot configuration, then this would account for why UART assignment is something odd.
Hi linuxdev,
Thanks for the reply.
You are right. Changing the baudrate won’t help.
It took me some time to understand that the solution will be as you said to “unbind serial console from that UART during boot stages”.
I tried to add a new dtb file for the uefi as mentioned here: Always restart when using NX system
but that didn’t work.
I think that removing the 5-seconds menu from my UEFI boot screen will be the best solution for now.
Removing 5 seconds will also make life difficult if you want to put that time back. What application is it that connects to a UART and which might be looking like a keystroke? A temporary workaround might simply be to disconnect that app/device during boot. @DavidDDD could probably also give you a way to remove serial console from that specific UART during boot stages (and hopefully the UART of issue is not the one dedicated to serial console; if that’s the case, then you should use a different UART since there is one which cannot be unbound).
Hi,
The application on boot is a DJI Drone, so I can’t modify its messaging on boot.
If @DavidDDD could give an advise to such solution it would be great because removing the 5 seconds delay also causes me problems, the UEFI chooses to reboot for unknown reason sometimes.
If this is a drone there is no way you want to have the possibility of a serial console and drone communications conflict (even during boot). The trick is going to be to either move to a different serial port, or else to remove serial console in the boot stage. Serial console is rather important though so far as working on a unit which is seemingly not working, so I’d really advise switching to a different port over removing serial console in boot stages (and removing this in boot stages will be significantly more difficult). Hopefully @DavidDDD can suggest how to remove serial console or suggest a different port (incidentally, changing the baud rate in boot stages is likely going to be at least as difficult as simply disabling serial console in boot stages, so changing baud rate is the more difficult and least effective strategy).