Feedback on Experimental UEFI Firmware

Robotics & Edge Computing Jetson Systems Jetson Xavier NX
,
42

Hello!

Apologies! Looks like a completely missed this. Do you mean accelerated graphics support within the UEFI bootloader for graphical display? If so there are not current plans to support this for Jetson Xavier platforms.

Jon

43

Hello all!

In case you have not seen, we have release an updated version of the UEFI bootloader for the Jetson Xavier platforms …

There are some details in the README about what is new/fixed.

Jon

1 Like
Custom initramfs on Jetpack 5.1.1 for AGXI
44

Just confirming… It does look like your’s and Vidya’s patches are in the 5.13 mainline kernel so no need for anything else for PCIe support right?

45

Yes they are in Linux v5.13 and so if you are using that, you should be all set.

Cheers
Jon

1 Like
46

Ah I meant GPU acceleration with mainline kernel (meaning solely for rendering purposes, not CUDA etc.).

47

@jonathanh I think there’s an issue with the new UEFI…

Edited with correct info…

Installed new firmware over L4T 32.6.1.
sudo ./flash.sh --no-systemimg jetson-xavier-nx-uefi external

Boot stock Fedora 34 kernel-5.13.13-200…
Kernel command line: BOOT_IMAGE=(hd0,gpt2)/vmlinuz-5.13.13-200.fc34.aarch64 clk_ignore_unused nr_uarts=4 cma=256M enforcing=0 no_console_suspend console=ttyTCU0,115200 console=tty0 root=/dev/nvme0n1p4 rootfstype=f2fs rootflags=defaults,noatime,discard text rd.shell=1 audit=0

arm-smmu 12000000.iommu: probing hardware configuration...
arm-smmu 12000000.iommu: SMMUv2 with:
arm-smmu 12000000.iommu:         stage 1 translation
arm-smmu 12000000.iommu:         stage 2 translation
arm-smmu 12000000.iommu:         nested translation
arm-smmu 12000000.iommu:         stream matching with 128 register groups
arm-smmu 12000000.iommu:         64 context banks (0 stage-2 only)
arm-smmu 12000000.iommu:         Supported page sizes: 0x61311000
arm-smmu 12000000.iommu:         Stage-1: 48-bit VA -> 48-bit IPA
arm-smmu 12000000.iommu:         Stage-2: 48-bit IPA -> 48-bit PA
...
arm-smmu 12000000.iommu: Unexpected global fault, this could be serious
arm-smmu 12000000.iommu:         GFSR 0x80000002, GFSYNR0 0x00000002, GFSYNR1 0x00000014, GFSYNR2 0x00000000
arm-smmu 12000000.iommu: Unexpected global fault, this could be serious
arm-smmu 12000000.iommu:         GFSR 0x80000002, GFSYNR0 0x00000002, GFSYNR1 0x00000014, GFSYNR2 0x00000000
arm-smmu 12000000.iommu: Unexpected global fault, this could be serious
arm-smmu 12000000.iommu:         GFSR 0x80000002, GFSYNR0 0x00000002, GFSYNR1 0x00000014, GFSYNR2 0x00000000
arm-smmu 12000000.iommu: Unexpected global fault, this could be serious
arm-smmu 12000000.iommu:         GFSR 0x80000002, GFSYNR0 0x00000002, GFSYNR1 0x00000014, GFSYNR2 0x00000000
arm-smmu 12000000.iommu: Unexpected global fault, this could be serious
arm-smmu 12000000.iommu:         GFSR 0x80000002, GFSYNR0 0x00000002, GFSYNR1 0x00000014, GFSYNR2 0x00000000

Had to go back to the 1.1.0 version of the firmware.

Full log attached…

smmu.log (35.1 KB)

48

@jonathanh What kernel does the 1.1.1 tegra194-p3509-0000+p3668-0000-uefi.dtb assume?

The 1.1.0 dtb looks pretty much the same as the stock 5.13.14. There are only a few tweaks.
but…
The 1.1.1 dtb has the iommu stuff which 5.13.14 does not.
5.14.1 has the iommu stuff but also a bunch of stuff (adma, i2s, dmic,dspk, etc) that the 1.1.1 dtb does not.

49

Oh, may want to include a note in the new README that the QSPI partition layout changed with 1.1.1.

50

Hello!

Ah yes. It is something that we would like to do, but currently there is no ETA for this. Sorry about that.

Jon

51

Hello!

The UEFI firmware assumes no kernel version. Technically, the device tree images are backwards compatible with kernel versions and so it should not matter. Now in the mainline kernel we have been working to enable support for the SMMU on Tegra194 and this release of the UEFI firmware happens to include the device-tree change from the Linux v5.14 that enable the SMMU.

These SMMU faults are coming from the ethernet controller and we are looking into these. However, I don’t believe that these are related to UEFI bootloader update but just something that is a consequence of enabling the SMMU. Chances are the issue has always been there with Linux, but now we have enabled the SMMU we are actually seeing it.

If you use the dtb from the Fedora 5.13.14 kernel (by loading it in GRUB by adding the “devicetree ($root)/dtb/nvidia/tegra194-p2972- 0000 .dtb” string to the GRUB config) then you probably will not see the SMMU faults. However, the problem is probably still happening.

Jon

52

Hello!

Yes so far we have not documented that and to be honest, I was not sure that we needed to. Not that we are hiding anything, the information is available in the XML file that is used to flash the QSPI. However, just so that I understand, how is the partition information helpful/useful?

Jon

53

Yeah, I should have been clearer. What I was really after was if there were any kernel driver changes that needed to match the dtb shipped with 1.1.1 or vice versa.

Gotcha. I’ll try that combination later today.

54

Replacing the signed dtb (or other images) in the QSPI on a running device without having to go into recovery mode and running flash.sh. There’s probably an “ota thing” to do this but I just haven’t looked at the ota stuff much.

55

FYI… Regarding the serial port availability issue I reported a while back… Here’s the workaround I’m using now to free the 40pin header uart for other things (in devicetree mode anyway)…

/ {
	aliases {
		serial0 = &uarta;
	};

	bus@0 {
		uarta: serial@3100000 {
			compatible = "nvidia,tegra194-hsuart";
			reg = <0x03100000 0x40>;
			reg-shift = <2>;
			interrupts = <GIC_SPI 112 IRQ_TYPE_LEVEL_HIGH>;
			clocks = <&bpmp TEGRA194_CLK_UARTA>;
			clock-names = "serial";
			resets = <&bpmp TEGRA194_RESET_UARTA>;
			reset-names = "serial";
			current-speed = <115200>;
			status = "okay";
		};
	};
};

BTW, Any news on devicetree pinmux support? It’s kind of a pain to have to create a pinmux cfg and flash it for every change.

56

Hello!

Not that I am aware of. We need to look into this SMMU issue, but that could very well be a kernel issue.

Jon

57

Given that this is still experimental, the only way to flash is by going into recovery mode and that is what we recommend users do for now.

Jon

58

I knew it wasn’t supported so no worries.

59

Not yet, but it is on the list.

Jon

60

Cool, thanks. I think I’ve got the pins all set for now anyway. :)

61

@jonathanh : Flashing 1.1.1 with the 5.13.14 dtb worked fine.

Noticed this in the UEFI resource settings…

                   /----------------------------------------\                   
                   | Port Disabled                          |                   
                   | Console Enabled - 16550                |                   
                   | Console Enabled - NVIDIA 16550         |                   
                   | Serial Debug Enabled - NVIDIA 16550    |                   
                   \----------------------------------------/

What do they do?