Network Booting (iPXE)

So basically I would like to network boot using the USB ethernet IC.
I tried following the instructions from iPXE.org however, when I tried building I run into compiler errors.
//
gcc: error: unrecognized argument in option ‘-mabi=lp64’
gcc: note: valid arguments to ‘-mabi=’ are: aapcs aapcs-linux apcs-gnu atpcs iwmmxt
gcc: error: unrecognized command line option ‘-mcmodel=kernel’
make: *** [bin/__divdi3.o] Error 1
//
I googled the errors and I have found out that this is an error due to a lack of cross compilation.
I still don’t understand the full extent of the problems I am getting.
Could anyone lend a hand? Or even suggest an alternative.

Thanks.

This isn’t an answer, but more information on what you are using to boot (it seems PXE over network with the NIC being USB) may be needed.

Perhaps this information will help. The network adapter has to be supported not only under the Linux kernel, but also under the boot loader. On a desktop it is possible for a PCIe add-on NIC to be supported via the BIOS without the boot loader getting in the middle (this doesn’t mean PXE support wouldn’t be needed, it’s just saying perhaps the NIC wouldn’t need special handling).

For your USB NIC you’d need USB to work first, which it does on the u-boot distributed with L4T. The NIC would also have to be supported by u-boot. Most likely your NIC has been tested and works under a fully booted system (meaning via the kernel), but do test this anyway. The next requirement is to be sure the NIC is supported by u-boot…this may be somewhat problematic as it depends on the compiled source code. I can pretty much guarantee much of the L4T u-boot is custom to Tegra products and a mainstream u-boot would probably break boot…so you have these choices: (1) Use the L4T with a NIC functioning both in the kernel and existing u-boot; or (2) build and compile a new NIC driver integrated into u-boot, possibly porting something.

I’m not positive, but I’m thinking the Realtek R8168/R8169 could be supported already by u-boot; the kernel itself does support that chipset series of ethernet NICs. So verify first that the running L4T can use the adapter (it doesn’t even have to be configured, it just has to show up properly under ifconfig). After that you can use the serial console and see what you can do to poke around for indicators of NIC life. For serial console wiring see:
http://elinux.org/Jetson/TX1_Serial_Console

FYI, the TX1 kernel requires cross compile. An actual cross compile recipe is here. That particular post is for R24.1, but the kernel is the same in R24.2 (there may have been a fix of a mentioned missing quote mark…it’s easy to spot):
https://devtalk.nvidia.com/default/topic/936880/jetson-tx1/jetson-tx1-24-1-release-need-help-with-complier-directions-can-not-complie/post/4885136/#4885136

Thanks for the quick reply.
After running ifconfig the results are as follows.
eth0 Link encap:Ethernet HWaddr 00:04:4b:58:31:a0
inet addr:10.0.131.202 Bcast:10.0.255.255 Mask:255.255.0.0
inet6 addr: fe80::204:4bff:fe58:31a0/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:443163 errors:0 dropped:1 overruns:0 frame:0
TX packets:203428 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:613256444 (613.2 MB) TX bytes:15215168 (15.2 MB)

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:3908 errors:0 dropped:0 overruns:0 frame:0
TX packets:3908 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:454418 (454.4 KB) TX bytes:454418 (454.4 KB)

wlan0 Link encap:Ethernet HWaddr 00:04:4b:58:31:9e
inet6 addr: fe80::204:4bff:fe58:319e/64 Scope:Link
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:65 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:10844 (10.8 KB)

I actually thought once I build the iPXE I would be able to break out of u-boot and enter into iPXE boot. Was I too naive to think like that?
Also with the link you gave me about cross compilation, I can’t use make mrproper. Can I just install mroper? Or do I need to update something?
Sorry if these questions are really basic, I’m new to this…

It’s been several years since I last dealt with PXE. This was on x86_64, but despite having a real BIOS I still had to modify grub to simultaneously have diskless/headless/keyboardless (and Jetson’s have neither grub nor BIOS). What it comes down to is that whatever is providing boot configuration must be visible to u-boot. In addition, when control transfers to the kernel, the kernel must use a device the boot loader knows about without restarting the device.

An example of one issue is that u-boot supports USB2, but not USB3. You can boot from a USB2 hard disk. Configuration of the kernel makes it optional as to whether the kernel uses USB2 or USB3. One would think it is ok to set up the kernel in this case to USB3…but at the moment of handing off to the kernel the root partition is lost and boot would fail. In the case of u-boot supporting only USB2 it is not possible to hand off a partition to the kernel with USB3 due to the interruption in access while switching modes.

Networking is not any different. The u-boot boot loader must have network access to its configuration and to whatever device it hands over to the kernel. The kernel must have uninterrupted access just as if the device is physically connected for uninterrupted operation. Because of this PXE is not difficult if you have support for your NIC in both u-boot and the Linux kernel. Are you using a USB NIC?

About compile. mrproper is just a target within the kernel source. If you can’t use it it means you don’t have full kernel source. Kernel headers are just a tiny subset and perhaps you got headers (which is possible if you just need an outside driver but doesn’t work for much else). Full kernel source is available here for L4T (the current release is R24.2):
https://developer.nvidia.com/embedded/linux-tegra

Cross compile requires a 32-bit armhf compiler (this is for a 32-bit compatibility mode the hardware supports), plus an entire 64-bit aarch64/arm64 tool chain. If you have those, and set the proper environment variables, then “make mrproper” or “make O=$TEGRA_KERNEL_OUT mrproper” should function (the $TEGRA_KERNEL_OUT is just an environment variable you’ve set to where you want output to go…using O= puts it there, without O= it uses the kernel source tree itself which is messy and not advised). The links mentioned earlier talk about setting environment variables CROSS_COMPILE, CROSS32CC, and ARCH…the kernel build picks that up if they’ve been set.

If your host is Ubuntu I think cross compilers and tool chains are available on one of the Ubuntu repos, but I use Fedora and manually install Linaro compilers so I’m not sure which packages to use when building via an x86_64 Ubuntu host.

NOTE: I don’t see any external NIC in your ifconfig. By default a Jetson would show lo, wlan0, and eth0. An add-on NIC over USB would show another entry.

I was wondering, how is it possible to not detect the USB NIC using ifconfig if I’m connected the internet.

Also I run ifconfig again after reflashing.
enx00044b58264b Link encap:Ethernet HWaddr 00:04:4b:58:26:4b
inet addr:10.0.11.220 Bcast:10.0.255.255 Mask:255.255.0.0
inet6 addr: fe80::204:4bff:fe58:264b/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:181299 errors:0 dropped:0 overruns:0 frame:0
TX packets:94211 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:183661087 (183.6 MB) TX bytes:12204364 (12.2 MB)
Is this what I’m supposed to be seeing?

The trouble is that I see only one wired NIC…and the Jetson has an integrated wired NIC. So either the USB NIC or the integrated NIC is not showing up. “lsusb -t” would show layout of USB devices to verify physical cabling, but unless a kernel driver has detected and taken ownership of a NIC the NIC won’t show up on “ifconfig”. Perhaps ifconfig just isn’t showing an unconfigured NIC…to be certain what is the output of “ifconfig -a”?

Do keep in mind that the NIC will need to be seen not only in Linux, but also in the boot loader. I think if you use serial console there are some u-boot command line tools which might let you verify this.

Additional note: If the NIC does show up on ifconfig you should also be sure the driver is integrated in the kernel, or else that an initrd has the module available (otherwise the driver would be missing until further into the boot…which couldn’t happen if the driver is required for the continuation of boot).

Ah, yes. I’m not sure how to get into the serial console. I read the link you gave me, do I need some kind of connector to actually access the serial console? If so, why can’t I just get into the serial console.

With a normal PC you can just press delete or some other key and it interrupts the normal booting procedure to get into the BIOS configuration etc. When I start up the Jetson TX1 the screen stays black and instantly loads up ubuntu 16.04. I tried holding shift, ~, delete and other keys, in the end I could not interrupt the normal boot procedure.

I really thought it would be easy as just building iPXE and rebooting then interrupting the boot to get into iPXE boot. It seems like the network booting a Jetson is not very straight forward or I am not smart enough to get it working…

I currently don’t have access to the Jetson TX1, but when I do I will reply with the output for “ifconfig -a”.

Thanks for continual help.

On a normal PC you have a BIOS (or its UEFI equivalent). That BIOS provides a uniform interface to boot loaders, and that interface includes driver support for certain minimal features of the motherboard. For example, USB and USB keyboards are set up by the BIOS, as well as drivers for any SATA port. When you halt boot on that PC you are entering into the BIOS editing environment. Embedded systems do not have a BIOS…everything done in the BIOS is instead done in the boot loader (this is in addition to the things a PC boot loader would do). Especially important would be a video driver…boot loaders on a PC do not need to have a video driver because the motherboard does this for them before the boot loader is ever reached. Putting an entire video driver in a small embedded system’s boot loader is rather difficult.

So serial console is used instead. It’s just a serial UART with a string of bytes. No video driver required, no framebuffer required, no network stack required, no keyboard software required (including USB variants), no special protocols. But serial UARTs are not smart, they need to be told what speed to run at, along with any conventions like if flow control is used and if parity is used (but this is integral in the UART itself, only a tiny amount of support is required in software). The basic and minimal connection is a ground plus a TX and RX line. Assuming software flow control, this is all you’d use. Add hardware flow control via clear-to-send (CTS) and request-to-send (RTS) and speeds or cable lengths can increase…that’s two more wires, and those are optional. Video can fail (or not be implemented in the case of an embedded boot loader stage), ethernet can fail, and almost anything you can think of which can fail won’t get in the way of a serial UART doing nothing more than streaming bytes it sees. All of the video and other drivers are actually on the remote host that runs the serial console program. Since u-boot does not have a video driver you must use serial console via serial UART to access the features which a BIOS would do on a PC.

Incidentally, although an embedded system seems light weight and simpler than a PC, the boot loader does more than grub and could be considered more complicated even if it is less flexible.

So if you want to see the boot loader you have to see that stream of bytes. If you want to talk to the boot loader you have to also send a stream of bytes. A serial console program such as minicom or PuTTY or gtkTerm (my favorite) does the display and formatting of that stream of bytes from the remote host PC. To work with any PXE environment on a Jetson will pretty much make serial console mandatory.

If you want to modify or compile a boot loader on a PC you won’t have any real issues because all of the stuff which is custom to the motherboard hardware is in the BIOS. If you go to use an alternative boot loader source not written for a Jetson you will lose all customization…which includes serial console hardware, memory controller, eMMC access, USB hardware, ethernet hardware, so on. If you want to compile and modify the boot loader on the Jetson expect to start with the source code provided in the L4T distribution. If not, then you have lots of work ahead (or whoever makes it work has lots of work ahead). You could consider customizing someone else’s boot loader as writing a complete BIOS in software and integrating it into the normal boot loader functionality.

Some of the boot loader functionality may actually be slightly simpler because “t-boot” (nvtboot, or tegra-boot), part of the boot environment, is actually built into the Jetson. There may be some small and critical early steps to booting a Jetson which would not be required in u-boot because of this.

Overall though I do believe the existing u-boot has some support for network booting. That network boot environment can be edited from the serial console prompt, and so it is flexible and not necessarily too difficult to work with if you use the supplied u-boot with serial console.

That was very informative! Thanks.
After using “ifconfig -a” the results are as follows.
dummy0 Link encap:Ethernet HWaddr ae:3f:cb:e0:00:3b
BROADCAST NOARP MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

enx00044b58264b Link encap:Ethernet HWaddr 00:04:4b:58:26:4b
inet addr:10.0.128.45 Bcast:10.0.255.255 Mask:255.255.0.0
inet6 addr: fe80::204:4bff:fe58:264b/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:158100 errors:0 dropped:0 overruns:0 frame:0
TX packets:82425 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:215331556 (215.3 MB) TX bytes:7370818 (7.3 MB)

ip6tnl0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
NOARP MTU:1452 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:1283 errors:0 dropped:0 overruns:0 frame:0
TX packets:1283 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:153549 (153.5 KB) TX bytes:153549 (153.5 KB)

rmnetctl Link encap:IPIP Tunnel HWaddr
NOARP MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

sit0 Link encap:IPv6-in-IPv4
NOARP MTU:1480 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

tunl0 Link encap:IPIP Tunnel HWaddr
NOARP MTU:0 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

wlan0 Link encap:Ethernet HWaddr 00:04:4b:58:26:49
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
I think the second NIC is dummy0, just a guess.
Also, I went on http://www.jetsonhacks.com/2016/09/28/build-tx1-kernel-and-modules-nvidia-jetson-tx1/. After looking through the configuration for the kernel I believe I have the right drivers installed.

Of those devices listed these appear to be an actual hardware NIC:

  • wlan0
  • enx00044b58264b

Within those which are hardware devices, only enx00044b58264b has traffic. On my L4T R24.2 JTX1 my integrated NIC is listed as “eth0”. udev is responsible for naming, and can change depending on software versions, but I’m wondering why yours shows as enx00044b58264b. I had assumed this was the integrated NIC because there is always the integrated NIC unless the kernel driver does not exist…which in turn would require a kernel reconfiguration to skip the driver. Either your integrated NIC is missing because of driver issues, or udev has switched naming scheme.

Can you verify L4T release version? See “head -n 1 /etc/nv_tegra_release”. Also, can you describe any kernel configuration changes you might have from a custom kernel build? At least one of the two wired NICs is failing to show…if your add-on NIC is working I’m wondering what happened to the integrated NIC.

L4T release: # R24 (release), REVISION: 2.1, GCID: 7791156, BOARD: t210ref, EABI: aarch64, DATE: Thu Sep 29 00:59:21 UTC 2016

Basically I just ticked any box that I thought might be relevant.
e.g. I enabled drivers for Realtek PHYs and Realtek 8168 Napi I think…

The Realtek should cover the integrated NIC. I have a second NIC in bridging mode on a JTK1 which has a Realtek chipset and it just worked out of the box without any driver changes. For the NIC you are adding on USB, what is the chipset? Or can you give information to help determine which driver it might use (such as a URL for the detailed specs on the NIC)? I’m wondering why one of the two wired NICs isn’t showing up under ifconfig.

Incidentally, even if you get this working under the Linux kernel, you still need it to work within the boot loader to do PXE boots. I don’t know which NICs are supported in the existing u-boot, but you’re probably best starting out there and getting a USB NIC which already works without porting drivers to the boot loader. Pretty much anything the boot loader supports would work in Linux, but the other way around isn’t true.

I’m not too sure how to identify the chipset.


The nvidia site doesn’t really have an extensive description of what type of chipset it is…

It’s the USB NIC I’m wondering about. You mentioned in the original post that it was “USB ethernet IC”. The integrated NIC definitely works with the Realtek driver…the USB NIC is what more information is needed on.

Sometimes USB can give information about chipset. If you run “lsusb” you’ll see a list of devices. Identify the USB NIC, look at the “ID” part. It’ll look something like “0955:7721”. If you don’t know more about what brand/model/chipset the USB NIC has, run this on the ID (substitute with the real ID) and post the info:

sudo lsusb -d 0955:7721 -vvv

I think I found it!
Bus 002 Device 002: ID 0955:09ff NVidia Corp.
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 3.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 9
idVendor 0x0955 NVidia Corp.
idProduct 0x09ff
bcdDevice 30.00
iManufacturer 1 Nvidia
iProduct 2 USB 10/100/1000 LAN
iSerial 6 000001000000
bNumConfigurations 2
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 57
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xa0
(Bus Powered)
Remote Wakeup
MaxPower 64mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 3
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0400 1x 1024 bytes
bInterval 0
bMaxBurst 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0400 1x 1024 bytes
bInterval 0
bMaxBurst 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0002 1x 2 bytes
bInterval 8
bMaxBurst 0
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 98
bNumInterfaces 2
bConfigurationValue 2
iConfiguration 0
bmAttributes 0xa0
(Bus Powered)
Remote Wakeup
MaxPower 64mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 2 Communications
bInterfaceSubClass 6 Ethernet Networking
bInterfaceProtocol 0
iInterface 5 CDC Communications Control
CDC Header:
bcdCDC 1.10
CDC Union:
bMasterInterface 0
bSlaveInterface 1
CDC Ethernet:
iMacAddress 3 00044B58264B
bmEthernetStatistics 0x00000000
wMaxSegmentSize 1514
wNumberMCFilters 0x0000
bNumberPowerFilters 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0010 1x 16 bytes
bInterval 8
bMaxBurst 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 10 CDC Data
bInterfaceSubClass 0 Unused
bInterfaceProtocol 0
iInterface 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 1
bNumEndpoints 2
bInterfaceClass 10 CDC Data
bInterfaceSubClass 0 Unused
bInterfaceProtocol 0
iInterface 4 Ethernet Data
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0400 1x 1024 bytes
bInterval 0
bMaxBurst 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0400 1x 1024 bytes
bInterval 0
bMaxBurst 0
Binary Object Store Descriptor:
bLength 5
bDescriptorType 15
wTotalLength 22
bNumDeviceCaps 2
USB 2.0 Extension Device Capability:
bLength 7
bDescriptorType 16
bDevCapabilityType 2
bmAttributes 0x00000002
Link Power Management (LPM) Supported
SuperSpeed USB Device Capability:
bLength 10
bDescriptorType 16
bDevCapabilityType 3
bmAttributes 0x02
Latency Tolerance Messages (LTM) Supported
wSpeedsSupported 0x000e
Device can operate at Full Speed (12Mbps)
Device can operate at High Speed (480Mbps)
Device can operate at SuperSpeed (5Gbps)
bFunctionalitySupport 2
Lowest fully-functional device speed is High Speed (480Mbps)
bU1DevExitLat 10 micro seconds
bU2DevExitLat 2047 micro seconds
Device Status: 0x0000
(Bus Powered)

Interesting device…it is nVidia-produced, but I can’t tell what chipset it has from that. It does show the MAC address though:

iMacAddress 3 00044B58264B

This verifies the USB ethernet is the one being used where the MAC matches. The question then is what happened to the integrated NIC? With the Realtek driver present it should show up. If you run this command, what shows up? Should show “=y”:

gunzip < /proc/config.gz | egrep -i config_net_vendor_realtek

It does come out with “=y”.
On a side note, I got the serial console working so I decided to just move on and see if I can just get anything working on that side.
Basically I connected the Rxd, Txd and gnd pins of the TX1 to a usb slot of another TX1. I am using a TX1 to network boot the other TX1 if you can understand that…

I successfully got into serial console and played around with printenv.
Printenv boot_targets => boot_targets=mmc1 mmc0 usb0 pxe dhcp
Basically I have set the boot order now so it pxe boots first.


After rebooting I got this.
missing environment variable: pxeuuid
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/00000000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/0000000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/000000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/00000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/0000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/00
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/0
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/default-arm-tegra210
No ethernet found.
missing environment varia±----------------------------+
Retrieving file: pxelinux| |
No ethernet found. | Cannot open /dev/ttyUSB0! |
missing environment varia| |
Retrieving file: pxelinux±----------------------------+
No ethernet found.
Config file not found
MMC: no card present
switch to partitions #0, OK
mmc0(part 0) is current device
Scanning mmc 0:1…


You can ignore the “Cannot open /dev/ttyUSB0”. So after seeing this I think I can be sure that it is trying to PXE boot since it’s looking for a pxe file. So now the question is how do I PXE boot?
I know I need to setup a DHCP server etc. How do I setup the pxe file assuming I had a DHCP server.
I have been searching up guides but they are all seem somewhat irrelevant.

Thanks again for the help.

You are correct about needing a server, possibly both DHCP and TFTP. However, you first need an accessible ethernet or nothing else will matter (the “no ethernet found” can’t be avoided at this stage). DHCP and TFTP servers won’t depend on whether the server is a Jetson or anything else…pretty much any Linux admin type document will work, especially an Ubuntu admin manual. Making ethernet work in u-boot on a Jetson is very hardware-specific, and this is required to access the DHCP and TFTP servers. I don’t think you can get very far in PXE boot without ethernet.

I can’t swear that this device will work on a Jetson (I have one somewhere, wish I could find it to test), but chances are good that this works on a Jetson in u-boot. This particular device is one I used from approximately the L4T 16 era on a Tegra 3 with network booting. The primary limitation is of course that it is only 100Mbit/s.

I have not yet tried to PXE boot a Jetson (I haven’t worked on PXE boot in a long time), so I don’t know exactly what to look for next. Some of the missing environment variables or files might be a clue as to when and where boot related files are being searched for. It would be ok to have multiple failures so long as at least one success occurs (it is basically going through a list of possible default file sources until finding one which works…having the environment set would mean no need to search; finding a config file would mean a properly set environment on the first try). However, if those files are expected from a network source, then the missing ethernet is something of a smoking gun evidence that it can’t succeed.

Note that when a file is missing it may be possible to manually set environment variables if you know the content of the pxelinux.cfg and if that content is not binary (firmware files, initrd, and the kernel image itself are binary…you can’t type those in by hand). Setting some environment variables via serial console might get you some more information by getting the boot to proceed further without ethernet. What does the remote pxelinux.cfg have in it (post if you can)?

Unfortunately I don’t know where pxelinux.cfg… I looked at /var/lib/tftp folder and it’s empty so was I supposed to make a pxelinux.cfg folder?

I ended up making the folder using mkdir, however I still need files ike /default /o etc.
Do I have to make the files myself?

Also my ethernet is blinking so maybe I just need to configure something or install a driver?

You have to create pxelinux.cfg on your host server. The intent is that the PXE boot device (Jetson) reads this to get information on where to download everything which would normally be stored on the hard drive. Your normal host which will provide TFTP (and probably also DHCP) needs to be set up as a TFTP server, and the files added (such as kernel, initrd, the pxelinux.cfg), and then the PXE booting device can get these. It just happens that pxelinux.cfg could be considered something like an index or set of instructions on what to load from where…it is an entry point into a network booting recipe.

Remember that it won’t matter if you’ve set up your host for DHCP serving, TFTP serving, so on, if the device trying to reach it does not have a network card. If your network card does not have a driver or configuration within u-boot then it does not have a network card regardless of physical hardware.

Most every network device blinks to indicate some state of usefulness…perhaps just to indicate traffic, perhaps to indicate 100Mbit/s operation…you have to consult your information on that adapter. Are you talking about the USB network adapter? I’d say it is a good sign to see a blinking light, but more information on model and such would help.