Feedback on Experimental UEFI Firmware

If you are comparing with the DTB that is shipped for L4T, yes there are differences, however, this is simply because we are using the device-tree from the mainline kernel source tree. The focus here has been on booting mainline Linux kernels and hence it made sense to align with the mainline device-tree.


Oh, gotcha. That makes sense now.

I’ll probably be doing some devicetree work in the near future (spi at least). Since you’re the maintainer, what branch should I develop against? I was thinking for-5.13/arm64/dt assuming I get them to you in time. If that doesn’t make sense just let me know.

Also, was the tegra_gte driver one of the contested ones? I want to try and get that working as well.


Are you planning to submit these to the upstream Linux kernel branch? If so, then we typically just develop on top of -next. The changes for v5.13 have been submitted now and so once the merge window closes for v5.13 (in about a week), changes for v5.14 can be submitted.

What do you mean by contested? Ideally, it would go upstream but there are some discussions going on about how best to go this.


-next it is. I haven’t submitted kernel patches in a very long time so I’d prefer to send them to you, properly formatted of course. Things could get very confusing if I sent them up myself while you guys are also doing it.

Sorry, this was from another thread…

The module I want to get updated first is tegra_gte because I use for precision timekeeping.

HA! I just looked at the “discussion” link in your post which was for gte. :)

Just for reference, I use the GTE/AON GPIO with pps_gpio.

@gtj, @jonathanh,
I’ve created UEFI with Jetson NX Xavier - v1.1.0-26613629 in order to avoid poluting this thread. If any of you happen to have time, please, take a look at that, as my experience was not exactly the same as the one described here. :-).

@jonathanh Just a follow-up to serial/uart usage. After much investigation I’ve realized that there are no UARTs other than serial@3100000 that can be mapped to pins on the 40-pin header. Since we can’t use that one or the TCU port for general use, we’re kinda stuck with no serial ports.

For my GPS case, I’ve had to connect it via I2C, write a userspace program to interface to the I2C bus and pipe the result to socat to create a pty. Not exactly a good way going forward.

So, any thoughts on being able to free up that serial port and using the TCU for UEFI/boot?


If you are using device-tree and not ACPI then you should be able to use the TCU. You just need to add ‘console=ttyTCU0,115200n8’ to the kernel command line. I believe that should work.


No because before the kernel is even loaded, both the TCU and uart are being used by UEFI. The GPS not only gets confused by the output to the TCU, it’s error responses confuse UEFI.

Ah I see. Yes there is no simple way to get around that at the moment. It could be possible to disable the output enable for the serial port so that UEFI does not drive it, but then we would need a means to re-enable it again later on. Is there no way to keep the GPS in reset until you are ready to use it?

Sure there are ways to get around it. One of my options was to keep the GPS reset until a GPIO goes high but then the GPS would have to re-establish a lock every time. Another option was to use a buffer on the TX/RX lines and enable/disable that with a GPIO. Maybe I could also use 2 GPIOs to pull the TX and RX lines low and change them to high-z after the kernel boots. :) None of them are long-term solutions though and certainly not for the general public who need a uart.

So I have workarounds for now but a solution would need to be found before the UEFI firmware goes GA.

Noted. I can see that this is definitely a use case that was overlooked initially.

Cool! Thanks @jonathanh !

Hey @jonathanh

Where does pinctrl-tegra194 stand on your list of 5.x porting to-dos? I been trying to get gpio-aon pins DD00 and CC07 (pins 27 and 28 on the 40pin header) to work for something other than GEN2_I2C without luck. Then I realized that pinctrl-tegra194.c is only a stub in the 5.x kernels. :)

I’ve got workarounds so I’m really just curious.



To follow up on the above, I believe that there is a simple fix for this. The UEFI bootloader for Jetson AGX Xavier uses the device-tree file in the directory Linux_for_Tegra/kernel/dtb/tegra194-p2972-0000-uefi.dtb. By default this device-tree has the serial port on the 40-pin header enabled …

$ fdtget -t s ./Linux_for_Tegra/kernel/dtb/tegra194-p2972-0000-uefi.dtb /bus@0/serial@3110000 status

However, we can disable this so that UEFI will not use it …

$ fdtput -t s ./Linux_for_Tegra/kernel/dtb/tegra194-p2972-0000-uefi.dtb /bus@0/serial@3110000 status disabled

Now if you re-flash, UEFI will not output on the serial port on the 40-pin. Then to use the serial port on the 40-pin header, when you boot Linux you just need to pass a DTB with the serial-port enabled. For Fedora you can do this via GRUB by setting the ‘devicetree’ keyword in the GRUB config.


For the NX substitute the correct dtb name or does the firmware for the NX also read the AGX dtb?


Unfortunately, I am not aware of any plans to upstream support for any additional pinmux support on Tegra194. Note that today there is only some support for some Tegra194 PCIe pins. So currently the only way to handle this is at flash time by updating the appropriate MB1 files.


Gotcha, thanks.

For NX, it would be ./Linux_for_Tegra/kernel/dtb/tegra194-p3509-0000+p3668-0000-uefi.dtb. There serial port is also different and so would be …

$ fdtput -t s ./Linux_for_Tegra/kernel/dtb/tegra194-p3509-0000+p3668-0000-uefi.dtb /bus@0/serial@3100000 status disabled


Yep, just making sure. :)
Will be testing this afternoon.