My most pressing question is: How can I, a human, determine the current state of any given kill switch?
"you can't", except, by pressing the button to toggle the state, at which point you'll need to do it again. other than, perhaps, in one or two cases, looking at dmesg or poking the right sysfs bits to see if the device is still present or missing.
How can software running on the main CPU determine the current state of any given kill switch?
Generally, "you can't", although wifi and camera would probably appear and disappear, so there is that possibility. The caveat being the wifi driver doesn't like the device disconnect, so may need some poking to get it to properly reflect the device absence/presence.
The wiki states that the "power" (kill switch) state is stored across reboots. Where is it stored?
In the EEPROM attached to the keyboard's MCU.
Since USB has no facility for privacy switches, it must also have a secondary connection to signal that a kill switch should be enabled/disabled. Where on the schematics can I find this connection?
Yup, that would be it. . The SH68F83 is a low speed (i.e. USB 1.1) microcontroller, which being used as the interface between the keyboard matrix and the PBP.
Where's the source code and build instructions for the keyboard firmware?
The source for the keyboard firmware is not available - the manufacturer would not release that, but did give pine64 updated binaries to overcome the initial issues with keyboard responsiveness. There have been efforts to reverse engineer it, and one such is this work by Jack Humbert (check out the firmware/src folder). You'll also find that elusive datasheet in the repo.
One thing in particular is that if you turn off the kill switch, wlan0 doesn't disappear; however, if the laptop is powered on with the kill switch already inactive, wlan0 never appears in the first place. I'd like to better understand why this is.
Probably related the WiFi driver not understanding how to cope with the WiFi module just suddenly dropping in or out of existence, rather than via some software instruction. That's why these commands are needed to kick it back into life if you turn it on (probably just the unbind command would refresh things if you turn it off, meaning you'd then only have to bind it when turning it back on).
"you can't", except, by pressing the button to toggle the state, at which point you'll need to do it again. other than, perhaps, in one or two cases, looking at dmesg or poking the right sysfs bits to see if the device is still present or missing.
How can software running on the main CPU determine the current state of any given kill switch?
Generally, "you can't", although wifi and camera would probably appear and disappear, so there is that possibility. The caveat being the wifi driver doesn't like the device disconnect, so may need some poking to get it to properly reflect the device absence/presence.
The wiki states that the "power" (kill switch) state is stored across reboots. Where is it stored?
In the EEPROM attached to the keyboard's MCU.
Since USB has no facility for privacy switches, it must also have a secondary connection to signal that a kill switch should be enabled/disabled. Where on the schematics can I find this connection?
Yup, that would be it. . The SH68F83 is a low speed (i.e. USB 1.1) microcontroller, which being used as the interface between the keyboard matrix and the PBP.
Where's the source code and build instructions for the keyboard firmware?
The source for the keyboard firmware is not available - the manufacturer would not release that, but did give pine64 updated binaries to overcome the initial issues with keyboard responsiveness. There have been efforts to reverse engineer it, and one such is this work by Jack Humbert (check out the firmware/src folder). You'll also find that elusive datasheet in the repo.
One thing in particular is that if you turn off the kill switch, wlan0 doesn't disappear; however, if the laptop is powered on with the kill switch already inactive, wlan0 never appears in the first place. I'd like to better understand why this is.
Probably related the WiFi driver not understanding how to cope with the WiFi module just suddenly dropping in or out of existence, rather than via some software instruction. That's why these commands are needed to kick it back into life if you turn it on (probably just the unbind command would refresh things if you turn it off, meaning you'd then only have to bind it when turning it back on).
Code:
$ echo 'fe310000.dwmmc' | sudo tee /sys/bus/platform/drivers/dwmmc_rockchip/unbind
$ echo 'fe310000.dwmmc' | sudo tee /sys/bus/platform/drivers/dwmmc_rockchip/bind