richardk

Just to summarize:
 
1. Use dtc to de-compile the existing rockchip-spi-spidev.dtbo to .dts:
    dtc -I dtb -O dts /boot/dtb/rockchip/overlay/rockchip-spi-spidev.dtbo -o rockchip-spi-spidev.dts
2. Edit the resulting rockchip-spi-spidev.dts and change instances of ff1c to ff19, and 3399 to 3328
3. (optional?) remove references to spi1, spi2, spi3
4. Compile rockchip-spi-spidev.dts back to dtbo
    dtc -I dts -O dtb rockchip-spi-spidev.dts -o /boot/dtb/rockchip/overlay/rockchip-spi-spidev.dtbo
5. Extract rockchip-fixup.script from /boot/dtb/rockchip/overlay/rockchip-fixup.scr
    (just use a text editor, and delete everything before "# overlays fixup script")
6. Edit rockchip-fixup.script and change instances of ff1c to ff19
7. Recompose rockchip-fixup.scr
   mkimage -A arm -T script -C none -d rockchip-fixup.script /boot/dtb/rockchip/overlay/rockchip-fixup.scr
 
Now, you can use armbian-config to add spidev, and reboot.
 

SUCCESS.   I've got it booting the second partition.  
 
Lessons:
 
armbianEnv.txt really wants UUID=.  If you make a new partition, make sure to match UUIDs.
 
Edit boot.cmd; find:
   echo "Boot script loaded from ${devtype} ${devnum}"
 
Before that line, add:
   setenv partnum "2"
   setenv devnum "${devnum}:${partnum}"
 
That's how it's working.
 
I thought I could adjust so that it took partnum=2 from armbianEnv.txt (and move the new setenv devnum down after armbianEbv.tct is loaded).  I don't know why that didn't work; I might have messed something else up.
 
Anyway, I'm good to go.
 

Okay, make sure to set BOOT flag on the second partition.
 
Adding setenv rootdev "/dev/mmcblk0p2" to armbianEnv.txt to the second partition's /boot/armbianEnv.txt doesn't work.
 
Moving on...
 

Furthermore... these i2cset commands work:
 
i2cset -f -y 1 0x18 0x52 3 # turn off both LEDs
i2cset -f -y 1 0x18 0x52 2 # turn off white, turn on red
i2cset -f -y 1 0x18 0x52 1 # turn off red, turn on white
i2cset -f -y 1 0x18 0x52 0 # turn on both red and white
 

Well, duh.   Thanks.
 

Beaglebone Black (et al) are already in pretty good hands, as beagleboard.org (seems like a project of Texas Instruments employees) does well supporting their own stuff.  If you want up-to-the-minute modern kernels, best by far is Robert C Nelson's work: https://www.digikey.com/eewiki/display/linuxonarm/BeagleBone .  (I support a commercial project with a Beaglebone Black inside, and I'm very pleased with the resources available.)
 

In Python:
  o = open("/sys/class/gpio/export", "w"); o.write("198");  o.close()
  o = open("/sys/class/gpio/gpio198/direction", "w"); o.write("out"); o.close()
  o = open("/sys/class/gpio/gpio198/value", "w"); o.write("1"); o.close()
 

Just FYI, this is what I would use for UDOO Quad:   http://eewiki.net/display/linuxonarm/UDOO
 
...but, only if you're not afraid of command line and kernel building.  Robert C Nelson does good work keeping his kit current.
 

For my daughter: Generating sounds in a "Ghostbusters" proton pack, two of them in fact.     A Python script reads /dev/ttyS2 to receive instructions from an Arduino connected to buttons/switches, and mixes/plays powerup, powerdown, idle,  and fire sound effects.