Closed conorpp closed 5 years ago
dont merge yet
should be good now
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 ?
Yes I can make these changes
Thanks!
This isn't working for me yet. Setup: fresh key, flashed hacker bundle.
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)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).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.
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.
Merge?
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.
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.