Created attachment 191641 [details]
'shar' archive for port
New port 'misc/raspberrypi-gpioshutdown' provides a kernel module 'gpioshutdown' that effectively 'shuts down' I/O pins at the point where the operating system is halted, by re-configuring them as input pins with no pullup/pulldown. This is similar to the "powerup" state, and somewhat duplicates what Linux does already.
Additionally, it provides 2 'sysctl' variables "kern.gpioshutdown.led_gpio" and "kern.gpioshutdown.led_gpio_set" by which you can optionally define the GPIO pin of an LED that you want kept as an output (instead of changing it to an input), and its 'on' polarity (0 or 1), which will be set to an 'on' state before sync'ing the disks, and then to an 'off' when it's safe to power off. (This is a workaround due to some odd behavior from the led driver, that seems to be easier to implement than any other idea I had)
It also includes an rc.d script "gpioshutdown" to generically configure a Raspberry Pi to use the power LED [or in the case of Model 1, the "ok" LED] as a shutdown indicator.
By loading this kernel module, all output GPIO pins (other than the one identified by the sysctl variable) are effectively placed into a high impedance state once it is safe to turn off the device. An external hardware 'power control' device (or an indicator LED) could then be used to determine that it is safe to power off after shutdown, specifically for a headless system. Many such external devices (such as the ATXRaspi) exist already. This kernel driver, or one like it, would be necessary for these external power control boards to be compatible with FreeBSD.
Additionally this port attempts to correct the issues brought up in problem report 211979. Additionally, it is marked for armv6 architecture only, and is specifically targeted for the Raspberry Pi (and named a such).
IMHO this should be ONLY_FOR_ARCHS= armv6 armv7
thanks, but I don't have an armv7 device to test it with. I understand that you can build for armv7 in '-CURRENT' but it's not released yet. However, by the time 12 has an RC I'll probably be testing this port with an appropriate device.
again, thanks for that info.