Fix some issues with the auto-flash on the PB2i not working due to modules not being loaded in time

Author: dkulp

SD/BB64-AutoFlash.sh

@@ -3,9 +3,9 @@
 #script that can be added to kernel init= to have the BB64/PB2 Industrial
 #flash the eMMC when powered on.   It will partition the device, possibly
 #reboot to get the new patition table, then install FPP onto the eMMC
-#and then power attempt to power down.  The power  down usually will
-#fail, but the indicator lights will stop flashing/cycling to 
-#indicate it's done
+#and then power down.  The indicator lights also stop flashing/cycling to
+#indicate it's done, which is the signal to trust if the board is still powered
+#for any reason.
 
 mount -o remount,rw /dev/mmcblk1p3 /  || true
 mkdir -p /proc
@@ -17,6 +17,16 @@ mount -t sysfs sysfs /sys
 PATH=$PATH:/bin:/sbin:/usr/bin:/usr/sbin
 DEVICE=/dev/mmcblk0
 
+# This runs as init, so udev is never started -- and udev is what loads the driver
+# module for an i2c client, off the MODALIAS in its uevent.  The kernel creates the
+# clients from the device tree either way, so without this the identity EEPROM and
+# the ADC beside it sit on the bus with no driver bound and no /sys attributes:
+# indistinguishable, from sysfs alone, from an MSPM0 that was never programmed.
+# Both are modules in the FPP kernel (CONFIG_EEPROM_AT24=m, CONFIG_AD7291=m).
+for mod in at24 ad7291; do
+    modprobe ${mod} 2>/dev/null || true
+done
+
 mount -t vfat /dev/mmcblk1p1 /boot/firmware
 mount  -t tmpfs /tmp
 
@@ -40,7 +50,16 @@ fail() {
         echo 120 > "$led/delay_on" 2>/dev/null
         echo 120 > "$led/delay_off" 2>/dev/null
     done
-    exit 1
+    # This script IS init, so exiting is a kernel panic ("Attempted to kill init"),
+    # and with no panic= on the command line the board just wedges -- no reboot, and
+    # nothing left to ask questions of.  Hand the serial console a shell instead: the
+    # LEDs keep blinking from the kernel's timer trigger either way, so the board
+    # still reads as failed to anyone who only has the lights.
+    echo ""
+    echo "Dropping to a shell on the console.  The board stays unflashed."
+    exec /bin/sh -i < /dev/console > /dev/console 2>&1
+    # If /dev/console is not usable, hang rather than panic.
+    while true; do sleep 3600; done
 }
 
 echo "---------------------------------------"
@@ -79,17 +98,44 @@ rm -f /mnt/fpp_expand_rootfs
 umount /mnt
 
 # Done.  A sweep means working and a synchronised blink means failed, so darkness is
-# the only remaining state -- and unlike "powered off" it survives the shutdown below
-# failing, which in this environment it usually does.
+# the only remaining state -- and it is what remains readable if the power off below
+# does not take, since a board that never powered down still has to look finished.
 for led in /sys/class/leds/*usr[0-9]; do
     [ -e "$led/trigger" ] || continue
     echo none > "$led/trigger" 2>/dev/null
     echo 0 > "$led/brightness" 2>/dev/null
 done
 
+# Shut down.  Note what is NOT available here: /sbin/{shutdown,halt,poweroff,reboot}
+# are all symlinks to systemctl, and this script is PID 1, so there is no systemd for
+# any of them to talk to.  sysrq is the only route out.
 echo 1 > /proc/sys/kernel/sysrq
-echo s > /proc/sysrq-trigger
-echo u > /proc/sysrq-trigger
-echo o > /proc/sysrq-trigger
+
+# sysrq 'o' hands off to orderly_poweroff(), which first runs poweroff_cmd as a
+# usermode helper -- /sbin/poweroff, i.e. systemctl again -- and only forces a real
+# kernel_power_off() once that fails.  Point it at something that cannot exist so it
+# fails immediately instead of grinding through that.
+echo /nonexistent-force-kernel-poweroff > /proc/sys/kernel/poweroff_cmd 2>/dev/null || true
+
+echo s > /proc/sysrq-trigger   # sync
+echo u > /proc/sysrq-trigger   # remount everything read-only
+echo o > /proc/sysrq-trigger   # power off
+
+# 'o' is asynchronous -- it queues work and the write returns straight away -- so the
+# power off is still being set up when this line is reached.  Waiting here is not
+# politeness: this script IS init, so running off the end is "Attempted to kill
+# init", a kernel panic that beats the shutdown to the finish and lands on a board
+# that flashed perfectly.
+#
+# The power off itself is real on this hardware.  The TPS65219 PMIC at i2c 0x30 is
+# marked system-power-controller in the device tree, so the tps65219 driver registers
+# a SYS_OFF_MODE_POWER_OFF handler and the kernel can actually cut the rails -- there
+# is no psci node, but none is needed, the PMIC is the handler.  So this loop should
+# never get more than a few seconds in.  It is the backstop for the case where the
+# handler does not fire, where a parked init with everything synced and read-only,
+# and the LEDs dark, is still a correct and readable end state.
+while true; do
+    sleep 3600
+done
 
 

capes/drivers/bb64/check_pb2_eeprom.sh

@@ -39,6 +39,12 @@
 # not ACK there even on a healthy board, so its silence proves nothing.  Whether the
 # emulated devices bound is the only signal that means anything.
 #
+# But "did not bind" only means something once the driver exists to bind.  at24 and
+# ad7291 are modules, loaded by udev off each client's MODALIAS -- and the boot-time
+# flasher runs as init with no udev, where an entirely healthy board presents the
+# unprogrammed-MSPM0 signature exactly.  Hence the modprobe below, and the separate
+# verdict for "the driver is not there" ahead of any verdict about the board.
+#
 # Usage:  check_pb2_eeprom.sh [--quiet]
 #
 # Exit codes:
@@ -85,6 +91,18 @@ case "${MODEL}" in
         ;;
 esac
 
+# udev is what loads the driver module for an i2c client, off the MODALIAS in its
+# uevent.  The boot-time flasher runs this script from init= with no udev at all,
+# and at24/ad7291 are both modules -- so on that path the clients exist with no
+# driver bound, which from sysfs is indistinguishable from an MSPM0 that never came
+# up.  Load them here so the verdict below is about the board and not about the
+# environment the script was called from.  A no-op when they are already loaded,
+# built in, or when running against fixtures.
+if [ -z "${PB2_EEPROM}${PB2_I2CDEV}${PB2_ADCDEV}" ] && command -v modprobe >/dev/null 2>&1; then
+    modprobe at24 2>/dev/null || true
+    modprobe ad7291 2>/dev/null || true
+fi
+
 # The EEPROM has to be present before anything else can be decided.
 i=0
 while [ ! -f "${EEPROM}" ] && [ "${i}" -lt "${EEPROM_WAIT}" ]; do
@@ -94,6 +112,20 @@ done
 if [ ! -f "${EEPROM}" ]; then
     # Both of these end the flash, but they point at different repairs, and the
     # message is the only thing whoever picks the board up gets to work from.
+    #
+    # Before any of them: if the at24 driver is not even registered, nothing could
+    # have bound to 0x50 whatever the hardware did, and every verdict below would be
+    # an accusation against a board that was never asked.  That is a broken image or
+    # a missing module, not a broken board.
+    if [ -z "${PB2_EEPROM}${PB2_I2CDEV}${PB2_ADCDEV}" ] && [ ! -d /sys/bus/i2c/drivers/at24 ]; then
+        fatal "the at24 driver is not loaded, so nothing can bind to the EEPROM at 0x50.
+
+  This says nothing about the board -- the driver that would read it is missing.
+  It is a module in the FPP kernel and is normally loaded by udev; check that
+  /lib/modules/$(uname -r) matches the running kernel.
+
+  Re-run this once at24 is loaded before judging the hardware."
+    fi
     if [ -d "${I2CDEV}" ]; then
         # The client exists but at24 did not bind, so 0x50 did not ACK its probe
         # read.  On a PocketBeagle2 that EEPROM is emulated by the on-board