Netbooting piCorePlayer 3.x

(Summarized from posts in the pCP 3.10 announce/support thread.)

A seemingly operational pCP player can be obtained via net booting, a Pi 3 feature only:

1. Take a linux server with disk space, install a tftp server to support Pi 3 net booting. I chose dnsmasq, the conf for the tftp server is extremely simple. "server=172.17.0.2" is the DNS/DHCP server on that network. There is no interference between the 2 machines:
   Code:

   ---

   server=172.17.0.2
dhcp-range=172.17.255.255,proxy
log-dhcp
enable-tftp
tftp-root=/tftp
pxe-service=0,"Raspberry Pi Boot"

   ---

   The tftp tree structure is like this. 12345abc and abcde123 represent the serial number of 2 different Pi 3s. bootcode.bin has to be placed directly under the tftp root:
   Code:

   ---

   /tftp/
├── 12345abc
│  ├── bcm2708-rpi-0-w.dtb
...
│  └── start_x.elf
├── abcde123
│  └── Pls_bind_to_nfs_exported_boot_directory
└── bootcode.bin

   ---

   The contents of the "12345abc" directory is the same as the first partition on a pCP image, with a custom cmdline.txt.
2. On that server, setup exports to provide the player with its data partition(s). The main export is the home of pCP, copied from the second partition of a pCP image. There is need for a secondary export, since pCP offers changing boot parameters and loading hardware firmware ("overlays") from the GUI. There has to be an automatic link between that export and the directory served by tftp in order for pCP to be able to reboot into new settings.
   As of now I am using a single NFS export on the server.
   Code:

   ---

   /export 172.17.0.0/16(rw,sync,no_subtree_check,no_root_squash)

   ---

   Here is the tree:
   Code:

   ---

   /export/
├── 12345abc
│  ├── BOOT
│  │  ├── bcm2708-rpi-0-w.dtb
...
│  │  └── start_x.elf
│  └── TCE
│      └── tce
│          ├── mydata.tgz
...
├── abcde123
...

   ---

   To link the /tftp directory with the updatable (exported) BOOT directory, I've chosen to setup a bind mount (e.g. "mount -o bind /export/12345abc/BOOT/ /tftp/12345abc"). The pCP machine reboots in new settings like on the regular SD-based version.
3. On the pCP instance, setup a custom /opt/bootlocal.sh script and save it ("pcp bu"):
   Code:

   ---

   #!/bin/sh
# put other system startup commands here

GREEN="$(echo -e '\033[1;32m')"

echo
echo "${GREEN}Running bootlocal.sh..."
#pCPstart------
/home/tc/www/cgi-bin/do_rebootstuff.sh 2>&1 | tee -a /var/log/pcp_boot.log
#pCPstop------

# NFS mounting. See http://forum.tinycorelinux.net/index.php?topic=19913.0
for i in `cat /proc/cmdline`; do           
case $i in                     
    nfsboot*)                               
        # Allows to update pCP boot config over NFS
        NFSBOOT=${i#*=}
        BOOTMNT="/mnt/mmcblk0p1"
        SERVER=$(echo $NFSBOOT | awk -F: '{ print $1 }')
        DIR=$(echo $NFSBOOT | awk -F: '{ print $2 }')
        OPTS=$(echo $NFSBOOT | awk -F: '{ print $3 }' | tr ',' ' ')
        OPTS=$(echo defaults noauto nolock addr=${SERVER} ${OPTS} | tr ' ' ',')
        echo "Creating directory ${BOOTMNT}"
        sudo mkdir ${BOOTMNT} >/dev/null 2>&1
        # pCP checks in fstab for device /dev/mmcblk itself so mounts fail...
        # echo "Creating /etc/fstab entry for ${BOOTMNT} over NFS"
        # ME="$0"
        # sudo sh -c "cat << EOF >> /etc/fstab
## Added by $ME
#${SERVER}:${DIR} ${BOOTMNT} nfs ${OPTS} 0 0
#EOF
#"
        # ... so instead we mount permanently as pCP won't mount/unmount
        # if mounted already.
        echo "Mounting ${SERVER}:${DIR} to ${BOOTMNT}"
        sudo mount -t nfs -o ${OPTS} ${SERVER}:${DIR} ${BOOTMNT}
        ;;
    nfsmount*)
        # Keep pCP happy with a normal-looking SD mount
        NFSMOUNT="/mnt/nfs"
        TCEMNT="/mnt/mmcblk0p2"
        echo "Creating directory ${TCEMNT}"
        sudo mkdir ${TCEMNT} >/dev/null 2>&1
        echo "Adding bind mount for ${TCEMNT}"
        sudo mount -o bind ${NFSMOUNT} ${TCEMNT} >/dev/null 2>&1
        ;;
esac
done

   ---

   This codes stays inactive until cmdline.txt includes the relevant boot parameters.
4. On the server, edit cmdline.txt to set the parameters, e.g.:
   Code:

   ---

   nfsmount=172.17.71.10:/export/12345abc/TCE nfsboot=172.17.71.10:/export/12345abc/BOOT:udp,vers=3,noatime

   ---

   1. nfsmount is a true TCLinux bootcode, this is processed in /etc/init.d/tc-config. This export gets mounted under /mnt/nfs. It should support the form <server>:<export>:<mount options> but the script only looks for some special options (noping?) and doesn't apply generic ones, like udp. The bootlocal.sh script adds a bind mount from /mnt/nfs to /mnt/mmcblk0p2, to (marginally) improve system reporting on the pCP GUI.
   2. nfsboot is implemented in bootlocal.sh, in the same fashion as tc-config except it processes mount options. This export contains the boot partition for configuration changes, and gets mounted to /mnt/mmcblk0p1 to let pCP work (almost) normally.
5. Boot the Pi player without an SD, and after a little while, the server shows:
   Code:

   ---

   Apr  3 23:30:23 luns dnsmasq-dhcp[425]: 653460281 available DHCP subnet: 172.17.255.255/255.255.0.0
Apr  3 23:30:23 luns dnsmasq-dhcp[425]: 653460281 vendor class: PXEClient:Arch:00000:UNDI:002001
Apr  3 23:30:23 luns dnsmasq-dhcp[425]: 653460281 PXE(eth0) b8:27:eb:01:02:03 proxy
Apr  3 23:30:23 luns dnsmasq-dhcp[425]: 653460281 tags: eth0
...
Apr  3 23:30:24 luns dnsmasq-tftp[425]: sent /tftp/bootcode.bin to 172.17.255.192
...
Apr  3 23:30:25 luns dnsmasq-tftp[425]: sent /tftp/12345abc/config.txt to 172.17.255.192
...
Apr  3 23:30:28 luns dnsmasq-tftp[425]: sent /tftp/12345abc/cmdline.txt to 172.17.255.192
...
Apr  3 23:30:48 luns rpc.mountd[502]: authenticated mount request from 172.17.255.192:920 for /export/12345abc/TCE (/export)
Apr  3 23:30:56 luns rpc.mountd[502]: authenticated mount request from 172.17.255.192:697 for /export/12345abc/BOOT (/export)

   ---

For what I've seen, pCP works normally. Some features like wifi setup, available space or partition resizing either don't make much sense anymore or quit. The routines that mount/dismount the boot partition around system updates are disabled due to the permanent NFS mount of /mnt/mmcblk0p1; They can't manage using an /etc/fstab entry for the NFS share (they look for /dev/mmcblk0 it seems).
In my use case, considering there is a good chance I will ultimately disable the web GUI on players, I feel like this solution works already. I will check it with the latest release, as I had to stuff pCP 3.10 with new firmwares taken from a Raspbian install to obtain the initial net boot attempt.

Given the tftp/nfs couple is relatively simple and lightweight, I have a feeling these could be installed on a "mothership" pCP instance. The server could be used to receive the contents of a running pCP player's SD, allowing it to net boot on the next reboot. Possibly, it could react to hits from unknown serial numbers and copy a netboot-ready instance of pCP in a new directory to allow a factory-fresh(*) Pi3 to boot as a pCP player. I will probably not use such things personally for now; in my case the server will be a Raspbian machine.
(*) AFAIK for now you need to boot once a factory-fresh Pi 3 from an SD with a config.txt file that includes "program_usb_boot_mode=1". Perhaps future batches of Pi 3 will have this flag set from factory.

If using an iSCSI LUN, moving from the network to an SD might be even simpler, as the LUN could be a pCP.img file with 2 partitions. I'm not sure this is needed and haven't checked if Pi 3/piCore can net boot from iSCSI.

Overall I am excited by this capability. Pi 3 netboot is great, and in the case of pCP, this more or less takes us back to the magic days of player auto-upgrade when installing a new version of LMS. It's been a long time since my SB3s haven't seen a firmware update :)

EDIT. 3.20beta netboots without further need to fiddle with firmware. The analog output sounds as good as possible, and sync seem fine too :)