Automating U-Boot Network Boot for Embedded Linux (TFTP + NFS)

Booting embedded Linux over the network is one of the fastest and most efficient ways to develop and test Yocto-based systems.
By automating U-Boot to fetch the kernel via TFTP and mount the root filesystem via NFS, developers can skip SD card flashing entirely and enjoy near-instant iteration cycles.

This article shows how to fully automate that process — so your board boots directly from the network on every power-up.

#Why Automate Network Boot

During early hardware bring-up and system integration, you often recompile the kernel, device tree, or rootfs several times per day.
Instead of manually entering boot commands or reflashing local storage, automated network booting allows:

⚡ Faster iteration: Just rebuild and reboot — no SD reimage
🔁 Consistent startup: Same boot procedure every time
🧠 Simpler testing: Kernel and filesystem both live on the host
💾 Zero flash wear: Great for NAND/eMMC-limited devices

#1. Prepare the Network Boot Environment

Before automating, confirm your network boot setup works manually:

Kernel (zImage or Image) and DTB are in /tftpboot/
Root filesystem is exported via /nfs/

U-Boot can successfully run:

 1tftp ${loadaddr} zImage
 2tftp ${fdtaddr} board.dtb
 3bootz ${loadaddr} - ${fdtaddr}

The Linux console shows:
```
 1VFS: Mounted root (nfs filesystem)
```

Once this is working, you can persist these steps.

#2. Define Persistent Environment Variables in U-Boot

At the U-Boot prompt, set the base parameters for your setup:

 1setenv serverip 192.168.0.1
 2setenv ipaddr 192.168.0.100
 3setenv bootfile zImage
 4setenv fdtfile board.dtb
 5setenv rootpath /nfs
 6setenv console ttyS0,115200
 7setenv nfsopts ",v3,tcp"

These values describe the host and target configuration and will be reused in every boot.

#3. Create a Network Boot Command Sequence

Now define a macro (netboot) that executes all necessary steps:

 1setenv netboot 'echo Booting from network...; tftp ${loadaddr} ${bootfile}; tftp ${fdtaddr} ${fdtfile}; setenv bootargs console=${console} root=/dev/nfs rw nfsroot=${serverip}:${rootpath}${nfsopts} ip=dhcp; bootz ${loadaddr} - ${fdtaddr}'

You can test it immediately:

 1run netboot

If everything loads correctly, you’re ready to make it permanent.

#4. Automate Boot on Power-On

Make U-Boot execute the network boot automatically after reset:

 1setenv bootcmd 'run netboot'
 2saveenv

From now on, U-Boot will automatically:

Request network configuration (DHCP)
Load the kernel and DTB from TFTP
Mount the root filesystem over NFS
Boot Linux — all without user interaction

#5. Add Fallback to Local Storage

To ensure reliability in case the network is unavailable, you can define a fallback sequence:

 1setenv bootcmd 'if run netboot; then echo "Network boot OK"; else echo "Falling back to SD card"; run mmcboot; fi'
 2saveenv

This hybrid boot logic gives you both speed during development and resilience in field conditions.

#6. Using a Boot Script (`boot.scr`)

If your U-Boot environment can’t be saved persistently, create a script instead.
Write the following to boot.cmd:

 1setenv serverip 192.168.0.1
 2setenv ipaddr 192.168.0.100
 3setenv bootfile zImage
 4setenv fdtfile board.dtb
 5setenv rootpath /nfs
 6setenv console ttyS0,115200
 7setenv nfsopts ",v3,tcp"
 8setenv bootcmd 'echo Booting from TFTP/NFS...; tftp ${loadaddr} ${bootfile}; tftp ${fdtaddr} ${fdtfile}; setenv bootargs console=${console} root=/dev/nfs rw nfsroot=${serverip}:${rootpath}${nfsopts} ip=dhcp; bootz ${loadaddr} - ${fdtaddr}'
 9run bootcmd

Compile it into a U-Boot script image:

 1mkimage -A arm -T script -C none -n "netboot script" -d boot.cmd boot.scr

Then place boot.scr in your SD card’s boot partition or in the TFTP directory.
U-Boot automatically detects and runs it during startup.

#7. Optional: Automating DHCP and PXE Boot

For larger setups or lab environments, you can take automation even further using PXE:

Configure your DHCP server to provide filename="boot.scr" or filename="zImage"
Point to the TFTP server automatically
U-Boot will download and boot the correct image with zero manual configuration

This is the same principle used in large-scale production test systems.

#8. Summary

Automating U-Boot network booting provides a powerful workflow for developers:

Fully hands-free startup over Ethernet
Seamless kernel and rootfs updates from the host
Optional fallback to local storage
Reproducible development and CI environments

At Mitkov Systems GmbH, we use this approach extensively during kernel, BSP, and driver development — especially when working with Yocto-based embedded platforms for industrial and IoT applications.

#💡 Next Steps

In upcoming articles, we’ll cover:

Using Yocto SDKs to deploy applications directly into NFS rootfs

Stay connected for more embedded Linux and BSP development insights, or contact us at
📧 mail@mitkov-systems.de

Mitkov Systems GmbH
-Specialists in Embedded Systems, IoT, and Industrial Connectivity