BeaglePlay network boot guide cuts kernel dev loop from SD card swaps to pure NFS
A BeagleBoard.org developer documented setting up TFTP/NFS network boot on BeaglePlay, eliminating physical SD card transfers for kernel and module testing.
Summary
A BeagleBoard.org developer published a detailed guide for network-booting the BeaglePlay single-board computer using U-Boot TFTP for the kernel and device tree, with an NFS-exported root filesystem from a Fedora Atomic host. The setup replaces a slow development loop of repeatedly removing and copying to an SD card. The post includes specific fixes for boot failures, such as masking the bbbio-set-sysconf.service dependency on /boot/firmware, handling SELinux xattr conflicts during rsync, and ensuring required network and NFS drivers are built into the kernel rather than modules.
Boot flow and gotchas
- U-Boot brings up Ethernet via DHCP, downloads pxelinux.cfg over TFTP, then fetches kernel, DTB and overlays; kernel uses
ip=dhcpand mounts root over NFS - Host uses socket-activated tftp-server and nfs-utils with
no_root_squashandasyncfor the export - Rootfs copied from BeaglePlay Debian image with
rsync -aHAX --numeric-idsand SELinux filter to preserve permissions and capabilities - Required built-in kernel options:
NFS_FS,NFS_V3,ROOT_NFS,IP_PNP,IP_PNP_DHCP, plus TI Ethernet drivers (TI_K3_AM65_CPSW_NUSS,TI_DAVINCI_MDIO) pxelinux.cfgappendmust be single-line; keyword isfdtoverlaysnotfdtoverlay; overlays require explicitfdtentryserveripmust be set afterdhcpsince DHCP overwrites it with the router address- Workaround for boards without
saveenv: keep kernel on local storage, use NFS only for rootfs
Why it matters
The guide lowers the barrier for kernel development on ARM boards by replacing slow physical media transfers with a standard network boot workflow, and documents specific pitfalls that would otherwise cost hours of debugging.
Original reference: www.beagleboard.org →