This one's from a discussion in Discord, where a user messed up their SSH password and locked themselves out of their board, and didn't have the physical equipment needed to reflash.
It might be a good idea to have the new firmware's power-on procedure check KEY1 (the on-board key) once at boot, and if held at the time, boot to some type of failsafe-mode that somehow ignores any custom settings changes the user may have applied since their last successful firmware flash. This lets them fix the configuration mistake, and they can then reboot as normal.
I am not really sure of the best way to implement "somehow ignore any custom settings," but we might want to consider having our rootfs be read-only (squashfs?) with a writable overlayfs. This is a technique used by other embedded Linux projects: In addition to having some good space savings, we get the option of not mounting the writable overlay (containing the potentially wrecked config) when failsafe mode is desired. It is essentially a "reset to factory defaults" for just one boot.
Another option to consider would be including a small initramfs that checks KEY1 and continues the boot only if KEY1 is not held. If KEY1 is held, the initramfs instead drops into a lightweight root shell, from which the user may mount and repair their rootfs.
This one's from a discussion in Discord, where a user messed up their SSH password and locked themselves out of their board, and didn't have the physical equipment needed to reflash.
It might be a good idea to have the new firmware's power-on procedure check KEY1 (the on-board key) once at boot, and if held at the time, boot to some type of failsafe-mode that somehow ignores any custom settings changes the user may have applied since their last successful firmware flash. This lets them fix the configuration mistake, and they can then reboot as normal.
I am not really sure of the best way to implement "somehow ignore any custom settings," but we might want to consider having our rootfs be read-only (squashfs?) with a writable overlayfs. This is a technique used by other embedded Linux projects: In addition to having some good space savings, we get the option of not mounting the writable overlay (containing the potentially wrecked config) when failsafe mode is desired. It is essentially a "reset to factory defaults" for just one boot.
Another option to consider would be including a small initramfs that checks KEY1 and continues the boot only if KEY1 is not held. If KEY1 is held, the initramfs instead drops into a lightweight root shell, from which the user may mount and repair their rootfs.