Giters

pimoroni / keybow-firmware

Keybow Firmware for the Raspberry Pi Zero

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Example code offering editor/hooks for persistance (working; but also feature request)

jakobi opened this issue · comments

commented

This is a feature request to add an editor to the 2020nov firmware image, and some hooks to permit persistance of modified files.

An example implemention is attached to this issue.

Thanx,
Peter

References:

commented

Post scriptum: sw/hw feature requests, severity "nice-to-have":

  1. enabling the rpi zero to offer some directory as usb-gadget/usb-mass-storage :). I actually saw two nerves-based projects tearing off the rpi zero with a pico just to kind of "easier gain this capability". At least one with a nice pcb to map the pico into the pi's gpio pinout :).

  2. I had to use HDMI for debugging boot up: a suitable HDMI cutout in the keybow acrylics would have been nice, similar to micro-USB. W/o this cutout I was forced to unscrew the acrylics to connect the monitor to watch bootup of the keybow.

commented 
1. enabling the rpi zero to offer some directory as usb-gadget/usb-mass-storage :). I actually saw two nerves-based projects tearing off the rpi zero with a pico just to kind of "easier gain this capability". At least one with a nice pcb to map the pico into the pi's gpio pinout :).

I spent countless hours trying to get Mass Storage to work in PiratePython. I wanted it to mount on both the users computer and the Linux system... which is not something filesystems are designed to do. It was (and still is) dicey and prone to errors.

Maybe it's possible to mount an alternate initrd and run an alternate config on boot that mounts /boot as Mass Storage when a key is held down, but otherwise just mounts internally.

We could mount a regular file as virtual storage, but it's still very tricky to sync changes and - iirc - only possible from host->device since there's no protocol to inform the host about changes to a mounted filesystem.

I think I see where you're going with your feature request/proof of concept and it aligns with something I was thinking today while trying to wrap my head around the Keybow firmware for probably the tenth time. It would be nice if the underlying system was pretty generic, and all the key components were modular. Of course I'm almost describing Tiny Core Linux at this point, but I always felt that went a little far in the other direction.

So hooks, I think, are a nice balance between the two. A stable, complete and working system that - if you want - offers the hooks to enable customization.

The init might just as well look for a file called "startup.sh" or "hook.sh" and then everything other than mounting/unmounting boot and exec'ing /sbin/init could be moved to there, making even the WiFi/SSH setup customizable.

I think I can tweak the rpi-ramdisk build process to set the correct permissions on /etc/rc.local, too.

Edit: and add a busybox-static install as a package.

commented

Gadgetoid/rpi-ramdisk@8faee71

The TLDR is that this creates /boot/startup and any .sh files placed in that directory will be run by the preinit script.

Judging by the cmdline.txt it looks like it was intended for /dev/mmcblk0p1 to be mounted as USB mass storage, but this does not appear to be working:

[   22.121387] Mass Storage Function, version: 2009/09/11
[   22.121449] LUN: removable file: (no medium)
[   22.121729] lun0: unable to open backing file: /dev/mmcblk0p1
[   22.122449] printk: console [ttyGS-1] disabled
[   22.122656] g_multi 20980000.usb: failed to start g_multi: -2

Presumably because it doesn't exist until created by mknod /dev/mmcblk0p1 b 179 1

commented

Wrt changing files on the keybow:

  • sshfs does work with the wifi firmware. Even editing a file on the host, then ssh root@keybowip pkill keybow should work.

For my own purpose, this should be enough to permit transient and persistant changes, in combination with xbindkeys/xdotool also on-the-fly modifications such as app-specific config changes.

Windows should offer the same using e.g. autokeys with FUSE/SSHFS by way of WSL or https://github.com/billziss-gh/sshfs-win

Adding Mass storage on the keybow

I've had a short look at mass storage, and failed with g_mass_storage. Using the lower tier module libcomposite (configuration via sysfs) did export a file as usb storage device to my linux PC.

See scriptlet, adapted from https://unix.stackexchange.com/questions/388304/no-udc-shows-up-for-usb-mass-storage-gadget-with-configfs

CONTAINERFS.sh.txt

Detecting writes from host on the keybow should work as well (slowly, using the time stamp of the backing file, called CONTAINERFS below): To trigger a keybow daemon restart could be a tad slow, with d0 maybe 30sec, and my linux PC usually waiting a minute or for actual completed sync.

A not quite-bash sketch could be this one:

while true do
: check the backing file timestamp
d=time - stat (formtime) CONTAINERFS;
d>2*d0 || { restarting=0; continue; }
d<d0 || { restarting=0; continue; }
restarting!=1 || continue;
restarting=1;
mount -oro,loop CONTAINERFS /mnt1;
cp /mnt1/lua-of-interest to lua-in-use-dir;
umount -fl /mnt1;
: do we need to expressly drop memory/vmcase -ve??
done

The opposite direction is probably worse as you wrote wrt piratepython; at least we already have a communication channel by way of lua and can send HID events, so this might do the trick: say injecting keypresses to notify something on the host to dismount, then sleep locally?, mount locally, change, dismount, notify host again to remount...