Open Hardware & RISC-V

BeaglePlay network boot guide cuts kernel dev loop from SD card swaps to pure NFS

Key Takeaway

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=dhcp and mounts root over NFS
  • Host uses socket-activated tftp-server and nfs-utils with no_root_squash and async for the export
  • Rootfs copied from BeaglePlay Debian image with rsync -aHAX --numeric-ids and 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.cfg append must be single-line; keyword is fdtoverlays not fdtoverlay; overlays require explicit fdt entry
  • serverip must be set after dhcp since 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 →