Booting Orin Nano via PXE over IPv4 issue

Robotics & Edge Computing Jetson & Embedded Systems Jetson Orin Nano
1

I have a Jetson Orin Nano 4GB and 8GB running Jetpack 6.1 and I am trying to get it booting via PXE based on what your documentation describes here:

https://docs.nvidia.com/jetson/archives/r36.4/DeveloperGuide/SD/FlashingSupport.html#configuring-a-pxe-boot-server-for-uefi-bootloader-on-jetson

I checked all files and configurations multiple times. They are correctly set up.
The grubnetaa64.efi.signed file is reachable via TFPT and the NFS is also exposed according to your documentation. Unfortunately I do not even get to this point.
The boot via PXE stops with error code: PXE-E16: No valid offer received.
But when I run Wireshark on the Ethernet-Connection I can clearly see that a DHCP Offer is sent via Broadcast:

Dynamic Host Configuration Protocol (Offer)
    Message type: Boot Reply (2)
    Hardware type: Ethernet (0x01)
    Hardware address length: 6
    Hops: 0
    Transaction ID: 0xe57ee678
    Seconds elapsed: 0
    Bootp flags: 0x8000, Broadcast flag (Broadcast)
        1... .... .... .... = Broadcast flag: Broadcast
        .000 0000 0000 0000 = Reserved flags: 0x0000
    Client IP address: 0.0.0.0
    Your (client) IP address: 192.168.137.157
    Next server IP address: 192.168.137.187
    Relay agent IP address: 0.0.0.0
    Client MAC address: NVIDIA_xx:xx:xx (48:b0:2d:xx:xx:xx)
    Client hardware address padding: 00000000000000000000
    Server host name not given
    Boot file name: efi/grubnetaa64.efi.signed
    Magic cookie: DHCP
    Option: (53) DHCP Message Type (Offer)
        Length: 1
        DHCP: Offer (2)
    Option: (54) DHCP Server Identifier (192.168.137.187)
        Length: 4
        DHCP Server Identifier: 192.168.137.187
    Option: (51) IP Address Lease Time
        Length: 4
        IP Address Lease Time: (43200s) 12 hours
    Option: (1) Subnet Mask (255.255.255.0)
        Length: 4
        Subnet Mask: 255.255.255.0
    Option: (3) Router
        Length: 4
        Router: 192.168.137.187
    Option: (17) Root Path
        Length: 10
        Root Path: /srv/tftp/
    Option: (255) End
        Option End: 255
    Padding: 0000000000000000000000000000000000000000

It seems that this Offer is not received by the Jetson.
Is there anything wrong with this offer that keeps the Jetson from accepting it?

3

Hi harald.funk,

Are you using the devkit or custom board for Orin Nano?
Could you also verify with the latest Jetpack 6.2(R36.4.3)?

Please share the full log when you try to boot from PXE.

4

I am using standard devkit right now:

  • 8GB: Nvidia devkit
  • 4GB: Seedstudio devkit

Issue is same on both setups

That’s all I get on serial console:

Jetson System firmware version 36.2.0-gcid-35084178 date 2023-12-19T05:26:19+00:
00
ESC   to enter Setup.
F11   to enter Boot Manager Menu.
Enter to continue boot.
**  WARNING: Test Key is used.  **

>>Start PXE over IPv4.
  PXE-E16: No valid offer received.

 e[2Je[01;01He[12;23He[0me[30me[47m                boot                e[13;23He[0me[37me[40m   Reboot Into Firmware Interface   e[14;01H
5

This error means that the Orin Nano(client) cannot receive any response(EFI_NO_RESPONSE) from PXE server.

Please share detailed steps how did you configure PXE server from host.
In addition, do you configure UEFI to disable some network feature?

It seems you are using JP6.0 DP(r36.2.0), which is the developer preview release.
Could you update to the latest JP6.2(r36.4.3) to verify?

7

Unfortunately there is no request to the PXE Server from Orin Nano. I mirrored the Ethernet Port of the Orin Nano and all I can see in Wireshark are recurrent DHCP Discover requests from Orin Nano which get answered by my DHCP Server with DHCP Offer messages as described above. After that no other ethernet packages are sent from Orin Nano except additional DHCP Discover requests.

For me it looks like the the Orin Nano is not accepting the DHCP Offer that is sent from my DHCP Server. From my understanding the Orin Nano should answer with an DHCP Request after the Offer, but this gets never sent.
Is there something wrong with the Offer sent by my DHCP server (see above)?

I also checked for FTP/TFTP or NFS related packages in the traces but there is no communication visible. Which makes sense as the DHCP process seems to never get completed.

I did not make any changes on the UEFI network settings. I also see identical behaviour on a 8GB and a 4GB Jetson Orin Nano Board, so it seems to be a general issue.

I just shared the logs from my 4GB Version which indeed has still a 6.0 DP Bootloader on it. My 8GB Device runs on JP6.1 and has the same issue. I can try updating this to JP6.2 but as it shows the same behaviour on 6.0DP and 6.1 I would highly doubt that it has something to do with the JP-Version.

8

Problem is solved!

I updated my Orin Nano to JP6.2. With this version randomly the Jetson Orin not stopped with the DHCP Offer but also sent back an Request and stopped after the ACK of that.

I tried to debug why it sometimes stopped after the DHCP Offer and sometimes after DHCP ACK and found out that another participant in the network (Baumer industry camera) sends ICMP messages directly to the Orin Nanos MAC-address with the content “Destination unreachable (Port Unreachable)” at the time of the DHCP Offer and Request. This seems to somehow disturbs the PXE Boot routine of the Orin Nano and causes this issue.

If I remove the camera from the network (and reboot the Orin Nano) the Orin Nano boots via PXE without any issue.

The behavior is reproducible. If I reconnect the camera to the network, PXE boot stops working again.

Interestingly the ICMP package seems to disturb the PXE process in a way, that a restart of the Orin Nano is needed to get it back to work. If I just try to restart the PXE Boot from Boot Manager after one unsuccessful PXE boot trial, it is still unusable even if the Baumer Camera is removed from the network in the meantime.

So it seems that the unexpected ICMP package during PXE boot causes something to crash inside the UEFI. I just removed the camera from the network so far to get it working, but I guess your developer should have a look on that to find the root cause of this issue.

9

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