rewrite option bytes on detach if needed

solokeys / solo1-cli

Solo 1 library and CLI in Python

https://pypi.org/project/solo-python

Apache License 2.0

185 stars 69 forks source link

rewrite option bytes on detach if needed #8

Closed conorpp closed 5 years ago

conorpp commented 5 years ago

Sometimes Solo can get stuck in the DFU unless the option bytes get re-written. Previously just the detach command was used, and the solo firmware would adjust the option bytes on boot, but it seems the detach command isn't reliable.

Now prior to detach-dfu, the option bytes are checked and adjusted if needed.

conorpp commented 5 years ago

dont merge yet

conorpp commented 5 years ago

should be good now

nickray commented 5 years ago

I think this should be a method of the DFU object, everything in below solo/cli should just call out to client or dfu, otherwise the Solo library is incomplete. Any reason it can't be an optional argument of dfu.detach? (Same for enter_bootloader_or_die actually.)

Other niggles (I can also merge and then change): Can you put op |= 1 << 27 etc. in solo.enums? Or that could be solo.constants, and include things like 0x1FFF7800.

Can the busy wait on dfu.state() have a small sleep ?

conorpp commented 5 years ago

Yes I can make these changes

nickray commented 5 years ago

Thanks!

This isn't working for me yet. Setup: fresh key, flashed hacker bundle.

on solo program aux leave-dfu, it does a sys.exit(1) inside dfu.set_addr with argument 0x1FFF7800 (during the self.dev.ctrl_transfer actually)
if i powercycle the key, it does sys.exit(1) inside write_option_bytes (rewriting them), during the self.write_page call (inside the while loop over get_status of block_on_state). The key seems to end up in normal state though (it verifies).

conorpp commented 5 years ago

I noticed it would silently exit as well sometimes for the set_addr call, but rebooting key would fix it. I didn't notice it was exiting early for write_option_bytes as well. Seems to be a problem in pyusb, I'll try experimenting some.

conorpp commented 5 years ago

I found there was inconsistency when programming "fresh" keys vs already-programmed keys. I'm not really sure why, and it seems the underlying usblib backend is a bit dodgy.

But I experimented some and now it seems to work reliably for both virgin and non-virgin keys.

conorpp commented 5 years ago

Merge?

nickray commented 5 years ago

No, it doesn't work yet. If you don't mind, I'll do a force push to turn the merge into a rebase, and then we can iterate until everything works. Mainly, --detach flag doesn't work, while leave-dfu does seem to.