PXE Boot still unavailable on AGX Orin?

[marc.mercer]

There was a post here a few weeks back that was not actually addressed properly. Has support for PXE been added to the AGX Orin with newer jetpack sdks?

See the following two threads:

UEFI Jetson Orin no PXE boot option

Hi, I’m using the Jetson Orin devkit. I’d like to use PXEboot. I flashed the UEFI on the device with the following command. sudo ./flash.sh -k A_cpu-bootloader jetson-agx-orin-devkit mmcblk0p1 When I boot up, however, I don’t see the option to use PXE for booting. It only shows the options UEFI SD Device UEFI eMMC Device UEFI Shell How can I enable PXEv4 on the Jetson AGX Orin developer kit?

and

UEFI HTTP/PXE boot unavailable on Orin AGX Devkit

During boot on an Orin AGX devkit, , when I press ESC to enter the UEFI menu, I do not see the IPv4/6 HTTP or PXE boot options like I do on a Xavier AGX devkit–even though the network cable is plugged in and I can access the network from Linux. Is network booting in UEFI unsupported on the Orin AGX devkit? Based on my brief look at the edk2-nvidia source, it doesn’t look like it has support for the Aquantia PHY on the devkit.

Would be great to get a definitive response on whether or not this is going to be addressed in the kit at some point.

Thanks

[KevinFFF]

Hi marc.mercer,

Are you using the devkit or custom board for AGX Orin?
What’s the Jetpack version in use?

For PXE boot, it should be supported and you can refer to the following topics.
Orin Nx Dev Kit PXE Boot - Jetson & Embedded Systems / Jetson Orin NX - NVIDIA Developer Forums
PXE Setup for Jetson AGX Orin with Jetpack 6.0 - Jetson & Embedded Systems / Jetson AGX Orin - NVIDIA Developer Forums

[marc.mercer]

Hi Kevin,

So we currently use Advantech as our supplier, and they provide a custom carrier board, but it should be the same standard devkit board.

I found this thread that you had participated in:

Orin Network boot not working on some units

We are trying to get http networking boot working on Orin dev kits. We have one “t234-A01-0-Silicon” that works, but we also have four “t234-A01-1-Silicon“ units where it appears the devices are not getting recognized by the drivers. The option to configure the network devices is not in the bios and the UEFI shell does not show the drivers loading any Ethernet devices. We have tested all units with the same full firmware flash in a few different versions including the newest at this point in ti…

Unfortunately I am not quite that deep into the internals of the hardware, so I’m making my way through it. I had our local and our remote office test all of our Orins and they all have the same issue.

We’re currently running the following according to /etc/nv_tegra_release

# R36 (release), REVISION: 3.0, GCID: 36191598, BOARD: generic, EABI: aarch64, DATE: Mon May  6 17:34:21 UTC 2024
# KERNEL_VARIANT: oot
TARGET_USERSPACE_LIB_DIR=nvidia
TARGET_USERSPACE_LIB_DIR_PATH=usr/lib/aarch64-linux-gnu/nvidia

With bootcontrol :

TNSPEC 3701-501-0005-G.0-1-1-jetson-agx-orin-devkit-
COMPATIBLE_SPEC 3701--0005--1--jetson-agx-orin-devkit-
TEGRA_BOOT_STORAGE mmcblk0
TEGRA_CHIPID 0x23
TEGRA_OTA_BOOT_DEVICE /dev/mtdblock0
TEGRA_OTA_GPT_DEVICE /dev/mtdblock0

What was interesting is that I attempted to do the i2cdump -f -y 0 0x56 just to see what values we would have… and I get back.. nothing

No size specified (using byte-data access)
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
10: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
20: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
30: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
40: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
50: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
60: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
70: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
80: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
90: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
a0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
b0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
c0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
d0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
e0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
f0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX

Now, as I said, I am brand new to this, so I am simply digging in without full understanding to see if i can find something, and learning as I go. I had thought that these were standard, but they could also be slightly customized. As far as I know, I should see Aquantia for the onboard cards… but I don’t, we have i350s…

mic-733ao@ubuntu:~$ lspci
0004:00:00.0 PCI bridge: NVIDIA Corporation Device 229c (rev a1)
0004:01:00.0 Non-Volatile memory controller: Phison Electronics Corporation PS5013 E13 NVMe Controller (rev 01)
0007:00:00.0 PCI bridge: NVIDIA Corporation Device 229a (rev a1)
0007:01:00.0 Ethernet controller: Intel Corporation I350 Gigabit Network Connection (rev 01)
0007:01:00.1 Ethernet controller: Intel Corporation I350 Gigabit Network Connection (rev 01)
0007:01:00.2 Ethernet controller: Intel Corporation I350 Gigabit Network Connection (rev 01)
0007:01:00.3 Ethernet controller: Intel Corporation I350 Gigabit Network Connection (rev 01)

So I’m debating if there are further changes that prevent the UEFI network boot. Forgive any ignorance here, I’ll become more educated on this as I go along, but It’s only my 2nd day interacting with the devices.

[KevinFFF]

@marc.mercer

What was interesting is that I attempted to do the i2cdump -f -y 0 0x56 just to see what values we would have… and I get back.. nothing

It may be expected as there’s no EEPROM on your custom carrier board designed by Advantech.
You can try running the following command to read the EEPROM inside the module.

# i2cdump -f -y 0 0x50

@marc.mercer

# R36 (release), REVISION: 3.0

Okay, it seems you are using Jetpack 6.0 (L4T r36.3.0). Is there the custom BSP package with Jetpack 6.2.1 available to verify?

@marc.mercer

I found this thread that you had participated in:

Oh, it is a known issue which may block the network boot device.
Have you tried applying that patch to check if it could help?

Please refer to Build with docker · NVIDIA/edk2-nvidia Wiki · GitHub to build UEFI source and apply the change there.