I've been reading the page on your Open Source support (well done, btw, on acknowledging your GPL responsibilities and even putting the toolchain up. That's great to see):
It left me with one or two questions which aren't wholly expounded upon though:
What happens when the secure boot lock is disabled? In addition to scrubbing the HDCP and DTCP keys, does it enable a full console anywhere? Otherwise, how would one actually put newly compiled binaries on the BrightSign's filesystem?
Thanks!
I agree that there isn't enough documentation on this topic. I work for a partner company and we have some documentation they've sent us, but unfortunately that's covered by a non-disclosure agreement. (I'm not sure why, to be honest, but that's what they decided.) That being said, my own independent findings are explicitly not covered by the NDA, and there are a few such things I've figured out which are of direct relevance to your question:
1. If you go to the "SECURE>" prompt again after using it to disable secure boot, it will say "BOLT>" instead, and many more commands will be available. You can use these commands to do things like write to Flash and boot from external media. I'd be careful with the former however; if you accidentally erase the BOLT bootloader your device will most likely be a brick. (Update: I can now confirm this from experience. Note that it might be possible to recover it using the internal "Broadband Studio" header, but there is no public documentation on how to do this; I don't even have access to it under the NDA. The hardware manual does show the location of the port, however.)
2. Typing "exit" at the "BrightSign>" prompt will exit the BrightSign application. Normally the device will just reboot when you do this (making it effectively the same as the "reboot" command) but if secure boot is disabled, it will instead drop you to a Linux shell as root. (Tip: you can return to the BrightSign application without rebooting by typing "brightsign" at the shell.)
3. BSFW update files are simple 'ar' archives containing shell scripts that install filesystem images. Normally the device won't touch them unless they've been signed, but disabling secure boot will remove this requirement. It still expects a SHA256 hash check to pass, and I'm not sure what exactly it is that's being hashed, but it will at least output the correct hash to the serial console if the check fails, so that's how you can determine the hash.
I hope this helps. :)
