Home of the Squeezebox™ & Transporter® network music players.
Page 1 of 2 12 LastLast
Results 1 to 10 of 20
  1. #1
    Senior Member
    Join Date
    Apr 2008
    Location
    Paris, France
    Posts
    2,075

    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
    Last edited by epoch1970; 2017-04-04 at 04:15.
    3 SB 3 • Libratone Loop, Zipp Mini • iPeng (iPhone + iPad) • LMS 7.9 (linux) with plugins: CD Player, WaveInput, Triode's BBC iPlayer by bpa • IRBlaster by Gwendesign (Felix) • Server Power Control by Gordon Harris • Smart Mix, Music Walk With Me, What Was That Tune? by Michael Herger • PowerSave by Jason Holtzapple • Song Info, Song Lyrics by Erland Isaksson • AirPlay Bridge by philippe_44 • WeatherTime by Martin Rehfeld • Auto Dim Display, SaverSwitcher, ContextMenu by Peter Watkins.

  2. #2
    Senior Member sbp's Avatar
    Join Date
    Apr 2010
    Location
    Denmark
    Posts
    1,051
    Hi epoch1970.

    This is great news, thank you very much for your hard work and for the detailed documentation of the steps.

    So I will have to try this out and let us see if there is a demand for this method then it might slip into pCP.
    Regarding disabling the webGUI I agree that after you have set up your pCP you usually can forget about it as you don't need to change anything.

    Steen
    piCorePlayer a small player for the Raspberry Pi in RAM.
    Homepage: https://sites.google.com/site/picoreplayer/home

    Please donate if you like the piCorePlayer

  3. #3
    Senior Member
    Join Date
    Apr 2008
    Location
    Paris, France
    Posts
    2,075
    Sure, glad to be of help. I hope others will find the idea interesting and the explanation clear enough. (Let me know)

    My use-case is a set of players in a public place, my drivers to want this were: a. scrape a few bucks per player, b. remove a cause of failure, c. allow remote "bare metal" players administration, d. save the planet (one less part to source), e. a tiny bit less smoke in case the player somehow catches fire.

    pCP 3.20 looks/sounds good, btw. Thanks!
    3 SB 3 • Libratone Loop, Zipp Mini • iPeng (iPhone + iPad) • LMS 7.9 (linux) with plugins: CD Player, WaveInput, Triode's BBC iPlayer by bpa • IRBlaster by Gwendesign (Felix) • Server Power Control by Gordon Harris • Smart Mix, Music Walk With Me, What Was That Tune? by Michael Herger • PowerSave by Jason Holtzapple • Song Info, Song Lyrics by Erland Isaksson • AirPlay Bridge by philippe_44 • WeatherTime by Martin Rehfeld • Auto Dim Display, SaverSwitcher, ContextMenu by Peter Watkins.

  4. #4
    Senior Member th00ht's Avatar
    Join Date
    Feb 2008
    Location
    Romanshorn
    Posts
    395
    Very interesting thread. Something I thought of doing but was scared by the amount of work. Good description. Getting away from that fiddling with SD cards that need not more than a view MB is good riddance.

  5. #5
    Senior Member
    Join Date
    Dec 2015
    Posts
    106
    hey epoch1970, thanks a lot for this. this idea has interested me for a while ...

    this question is more for steen and pCP dev guys, is it possible to have to have a pi3 (or other NAS/server) as a LMS and a netboot master of everything ?

    i guess i'd love if the client Pi's could have a uSD card with the basic info to get it started, like wifi password and i2s dac config and whatever else might be different across the clients.
    that way i only need to update a single Pi when there is a new version of pCP

    i realise that you guys are super busy with other things. maybe add it to the "one day i'll get around to it" list

    thanks again

    edit- just thinking more about this ... my NAS/LMS server runs XPenology (synology nas) which has the ability to do LUNs.
    So, can i make an image of an existing pCP uSD card and drop that into a LUN and then have a little netboot code on the client Pi uSD card.
    i'm not worried about leaving a card in the client Pi's (that may be a way of getting Pi 2's up and running also ??)
    feel free to push me in the right direction

    Name:  pi.netboot.JPG
Views: 317
Size:  155.2 KB
    Last edited by huxmut; 2017-04-12 at 03:21.
    rPi 3 + rasPi 7" LCD + HiFiBerry DiGi+ | rPi 2 + IQaudio DAC+ |rPi 2 + HiFiBerry DAC+ | Squeeze Box Touch | LMS + XPenology on HP Gen 8 |


  6. #6
    Senior Member
    Join Date
    Apr 2008
    Location
    Paris, France
    Posts
    2,075
    Yes a Pi 3 can netboot clients, I can't tell how many because atm I have a single Pi serving alternatively as client and server... But since the OS is light, the Pi should be able to manage quite a few clients simultaneously. I expect to be able to test for 5 clients booting simultaneously.

    You can't netboot from wifi on Pi 3. With an external ethernet-wifi bridge that should work, though. Actually I have an old "gaming adapter" somewhere, I could verify that...

    If you keep a system on an SD, then I think you're somewhat looking at an upgrade system like pCP has already.
    3 SB 3 • Libratone Loop, Zipp Mini • iPeng (iPhone + iPad) • LMS 7.9 (linux) with plugins: CD Player, WaveInput, Triode's BBC iPlayer by bpa • IRBlaster by Gwendesign (Felix) • Server Power Control by Gordon Harris • Smart Mix, Music Walk With Me, What Was That Tune? by Michael Herger • PowerSave by Jason Holtzapple • Song Info, Song Lyrics by Erland Isaksson • AirPlay Bridge by philippe_44 • WeatherTime by Martin Rehfeld • Auto Dim Display, SaverSwitcher, ContextMenu by Peter Watkins.

  7. #7
    Senior Member
    Join Date
    Dec 2015
    Posts
    106
    thanks epoch

    Quote Originally Posted by epoch1970 View Post
    If you keep a system on an SD, then I think you're somewhat looking at an upgrade system like pCP has already.
    it's probably me justing wanting to do it for the sake of doing it rather than any logical reason, but I do like the idea of having a boot file on the sd card and the 'core' OS and config files hosted on my nas.

    now, just wondering aloud here - for those updates that currently require a total rewrite of the uSD card, would this allow me a 'no easy access' build eg. the Pi could be buried in an amplifier, where access to the SD card is time consuming/PITA.
    and, if config changes were required would it be a case of SSH into the client Pi or would it be better if the config was also remote and a plain text file for easy updates ??
    or is it more likely a case of having seperate images for each client hosted on the NAS therefore defeating my desire to have a singular pCP image hosted ??

    Again, thanks for your efforts, I've started reading up on U-boot and other ideas like that, it's quite mad what a little Pi is capable of these days
    rPi 3 + rasPi 7" LCD + HiFiBerry DiGi+ | rPi 2 + IQaudio DAC+ |rPi 2 + HiFiBerry DAC+ | Squeeze Box Touch | LMS + XPenology on HP Gen 8 |


  8. #8
    Senior Member
    Join Date
    Apr 2008
    Location
    Paris, France
    Posts
    2,075
    I don't know u-boot, tinycore and pCP enough to say what is possible in terms of updates when the system runs from the SD.

    The Pi has no traditional BIOS, the only thing it can do by itself is test the SD, the USB and the network for boot media. The media includes firmware and OS.
    Since TinyCoreLinux is so compact, I don't think you can find much gain in using some pivot OS on an SD.

    Now, according to the Pi 3 boot description, if the OS on your SD (pCP) had a "suicide" option that would remove bootcode.bin, then on reboot the machine would look for media on the USB or network to boot from.
    And if such media was available and held a new version of the OS that had a "persist to SD" option, you could reboot and write the new OS to the SD. Unplug USB or ethernet, reboot again and you're done.
    EDIT: I've tested renaming "bootcode.bin" to "bootcode.hid" in an SD, and installing it in a Pi 3. It boots from the network. Then I renamed .hid into .bin, on reboot it ran from the SD. So a flip-flop from SD to network/USB with the SD in place is possible.

    Many devices have some "maintenance" USB port, with Pi 3 you theoretically could have either an USB or ethernet maintenance port.
    Last edited by epoch1970; 2017-04-13 at 01:55.
    3 SB 3 • Libratone Loop, Zipp Mini • iPeng (iPhone + iPad) • LMS 7.9 (linux) with plugins: CD Player, WaveInput, Triode's BBC iPlayer by bpa • IRBlaster by Gwendesign (Felix) • Server Power Control by Gordon Harris • Smart Mix, Music Walk With Me, What Was That Tune? by Michael Herger • PowerSave by Jason Holtzapple • Song Info, Song Lyrics by Erland Isaksson • AirPlay Bridge by philippe_44 • WeatherTime by Martin Rehfeld • Auto Dim Display, SaverSwitcher, ContextMenu by Peter Watkins.

  9. #9

    TF card extender

    Quote Originally Posted by huxmut View Post
    ...., would this allow me a 'no easy access' build eg. the Pi could be buried in an amplifier, where access to the SD card is time consuming/PITA. ....
    Hi Humax.
    The TF card swap in systems with embedded raspberries indeed does hinder upgrades.
    When I bought a deluxe casing for my Pi , I was pleasantly surprised it came with a 'sd card extender'.
    Searching with this string on some sites will give you more info instantly.
    I do recommend you use this knowledge for any embedded pi you have already or will build in the future.

    Greetz , MH

  10. #10

    PCP usb boot

    Further reading on the other bootmodes of the pi 3, made me aware on USB boot options.
    It seems the USB boot from a regular msd is possible, and this should also be possible for small tf card readers.
    So for embedded systems that have exposed USB / ethernet ports of a rpi3 , there is a < 1 Euro solution to boot over the USB port.

    I am not sure if PCP has been tested successfully with usb boots sofar. I might have missed the discussion on this.
    Please update me with a link if this is already documented .

    MH

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •