Feedback on Experimental UEFI Firmware

Robotics & Edge Computing Jetson & Embedded Systems Jetson Xavier NX
,
62

When booting in ACPI mode these control the generation of the SPCR and DBG2 tables.

Basically this mapping
Port disabled - neither are generated
Console Enabled -16550 : SPCR with subtype 0 works in linux
Console Enabled - NVIDIA 16550 : SPCR with subtype 5, does not currently work in linux but more correct to follow recently updated spcr spec
Serial Debug Enabled: Created DBG2 table with subtype 5

63

Just to confirm, are you using the Minimal Fedora 34 image or something else?

Thanks
Jon

64

It’s the Fedora 34 Server image instead of minimal.

65

Thanks, I was looking for some thing a little more functional, like it’s effect on the TCU and uarta ports. :)
’

66

Hello!

We have published a new UEFI bootloader (finally) and we did fix some issues related to SMMU faults being seen on boot. Please try the latest version here:

I would also be interested to know if the Crucial sticks still do not work with this latest version.

Thanks
Jon

67

I can try this afternoon, thanks!

68

Hello!

Thanks! Did you have chance to test this yet? I just wanted to see if this resolved some of the previous issues.

Jon

69

Sorry Jon! I got slammed the past week. I’ve got all day tomorrow to test though.

70

@jonathanh Testing results…

Environment:
Stock Fedora kernel-5.14.14-200.fc34.aarch64
Samsung SSD 950 PRO 256GB S2GLNX0H609245N NVMe
Stock DTB from UEFI 1.1.2

With Device Tree and Enable SMMU Walk Cache Disabled
Normal operation

With Device Tree and Enable SMMU Walk Cache Enabled
Faults every few seconds but otherwise seems to be functional.

[   24.429656] arm_smmu_context_fault: 141479 callbacks suppressed
[   24.429759] arm-smmu 10000000.iommu: Unhandled context fault: fsr=0x402, iova=0x7fffbcea00, fsynr=0x1b0003, cbfrsynra=0x9, cb=0
[   24.438175] arm-smmu 10000000.iommu: Unhandled context fault: fsr=0x402, iova=0x7fff800000, fsynr=0x1b0003, cbfrsynra=0x809, cb=0
[   24.439192] arm-smmu 10000000.iommu: Unhandled context fault: fsr=0x402, iova=0x7fff84d600, fsynr=0x1b0003, cbfrsynra=0xc09, cb=0
[   24.440180] arm-smmu 10000000.iommu: Unhandled context fault: fsr=0x402, iova=0x7fff8ca200, fsynr=0x1b0003, cbfrsynra=0x409, cb=0
[   24.441316] arm-smmu 10000000.iommu: Unhandled context fault: fsr=0x402, iova=0x7fff95c600, fsynr=0x1b0003, cbfrsynra=0xc09, cb=0
[   24.442337] arm-smmu 10000000.iommu: Unhandled context fault: fsr=0x402, iova=0x7fff9dd400, fsynr=0x1b0003, cbfrsynra=0x9, cb=0
[   24.443306] arm-smmu 10000000.iommu: Unhandled context fault: fsr=0x402, iova=0x7fffa58800, fsynr=0x1b0003, cbfrsynra=0x9, cb=0
[   24.444269] arm-smmu 10000000.iommu: Unhandled context fault: fsr=0x402, iova=0x7fffacd400, fsynr=0x1b0003, cbfrsynra=0x809, cb=0
[   24.445199] arm-smmu 10000000.iommu: Unhandled context fault: fsr=0x402, iova=0x7fffb487c0, fsynr=0x1b0003, cbfrsynra=0xc09, cb=0
[   24.454829] arm-smmu 10000000.iommu: Unhandled context fault: fsr=0x402, iova=0x7fff800000, fsynr=0x1b0003, cbfrsynra=0x809, cb=0

With:
ACPI, Enable SMMU Walk Cache Disabled, Enable PCIe in OS Enabled
ACPI, Enable SMMU Walk Cache Disabled, Enable PCIe in OS Disabled
ACPI, Enable SMMU Walk Cache Enabled, Enable PCIe in OS Enabled
ACPI, Enable SMMU Walk Cache Enabled, Enable PCIe in OS Disabled
Normal GRUB then…
EFI stub: Booting Linux Kernel…
EFI stub: Using DTB from configuration table
EFI stub: Exiting boot services and installing virtual address map…
HANG

So ACPI is non-functional.

Any changes in the 5.15+ kernels that would warrant me re-testing?

71

Hello!

Thanks for the feedback. Yes the SMMU page faults are expected if you enable the SMMU walk cache and so you should keep that disabled.

ACPI should be functional, what serial interface are you using for testing? For Jetson Xavier NX, the default is the UART on the 40-pin header, because the TCU is not supported with ACPI.

Linux v5.14 should be fine. I have been tested with that. Did you try the Crucial NVMe card?

Jon

72

Ah, I forgot about that. I also forgot to test the Crucial card. :) Will test both this morning.

73

With ACPI, everything seems to work except that I get the following kernel WARNINGs during startup… acpi-dmesg.log (6.3 KB)

I also tried a 250GB version of the Crucial NVMe card and had no problems. I then found the original 500GB card I reported the original problem with but I wasn’t able to get through a copy of my root filesystem without a “Unable to handle kernel paging request”. copyabort.log (3.6 KB)
This looks like an f2fs problem so I’m going to try again with ext4. I’ll let you know later today.

74

So this is interesting… I got the original 500GB Crucial card formatted but when I boot from it, even in device tree mode, I get…

[    7.679974] nvme nvme0: missing or invalid SUBNQN field.

then eventually dumped to the dracut emergency shell.
Oddly enough, the nvme devices show up fine and I can mount them in the emergency shell. Since the other Crucial card worked OK, I’m not sure what’s going on. It’s possible it’s just a bad card.

75

Hello!

Yes we have seen that warning. I did ask the upstream maintainers about this [0] but it looks like something we need to fix on with the ACPI firmware. So it is on our list to resolve.

Thanks!
Jon

[0] [RFC] PCI/MSI: Warning observed for NVMe with ACPI

76

Thanks for testing! That is odd that you can mount it manually but the kernel is not able to on boot. I guess not conclusive that it is a card problem, although it is interesting you were having issues formatting it.

Jon

78

Hey @jonathanh . Do you know if the UEFI firmware that shipped with JP 5.0 is a later version of the Experimental one or is it “new”?

79

Hello!

The version shipped with JP 5.0 is a later version. The source code is also now available on github …

Jon

80

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.