Open tcr opened 8 years ago
I think the assumption made when building those two commands was that most users wouldn't know what DFU mode is and shouldn't have to.
Both t2 restore
and t2 update
work properly from a Tessel in a standard boot state (not DFU).
I think that they could be made to work better if they could deal with a Tessel that's in DFU mode without throwing any errors.
Second best would be a warning telling the user to take the device out of DFU mode and to try the command again.
Second best would be a warning telling the user to take the device out of DFU mode and to try the command again.
I would prefer is this was the approach
@johnnyman727 Yeah, I can probably submit a PR to accomplish either of those.
Nonetheless, say I have a borked SAMD21. The bootloader still works—if I throw it into DFU mode. But we have no commands which allow you to flash it that way, but t2 update would, if we could skip the OpenWRT updating part. Is that reasonable to add? "Your T2 is in DFU mode, only updating firmware."
Right now there is no use for holding down reset to get into DFU mode, since the user can't do anything meaningful with it from the CLI.
And also, should t2 restore
reflash the SAMD21 firmware as well? Why not?
Right now there is no use for holding down reset to get into DFU mode, since the user can't do anything meaningful with it from the CLI.
I don't agree with this reasoning. The CLI's capabilities don't have an obligation to the button on the board. The on board button's "hold for DFU mode" functionality is vital for local t2-firmware development.
And also, should t2 restore reflash the SAMD21 firmware as well? Why not?
IIRC, there is no Tessel remote connection available at the end of the restore operation. This also prevented the automatic rebooting of the board at the end of t2 restore
.
I guess my real question is: what purpose does restoring the SAMD21 firmware serve, if said firmware is known to be in an optimal functioning state? That's known because the firmware is running and just provided the machinery necessary to restore OpenWRT.
I don't agree with this reasoning. The CLI's capabilities don't have an obligation to the button on the board. The on board button's "hold for DFU mode" functionality is vital for local t2-firmware development.
Fair point. I'm just saying from a user standpoint this is what we currently provide:
t2 restore
.dfu-util
. Switch into DFU mode on boot, then run the dfu-util command.It's less discoverable, unless I'm missing something. I was just trying to figure out how to bring some old T2's to life. Flashing in DFU mode doesn't have to be added to t2-cli, but we should document the dfu-util steps somewhere.
IIRC, there is no Tessel remote connection available at the end of the restore operation.
Can we switch the USB alt setting at the end of the flashing period to DFU mode? Or reverse the steps to flash firmware, then flash OpenWRT, since if my firmware is bad I would not be able to run the OpenWRT restore steps either.
Okay, so here's what I propose I try. A PR that does the following:
t2 restore
that flashes factory firmware on the SAMD21, then flashes the OpenWRT firmware, without requiring user intervention inbetween / any potential for additional issues.If I can't accomplish number 2) then I'd concede it's not worth the cost of integrating into the CLI. ;)
A change to t2 restore that flashes factory firmware on the SAMD21, then flashes the OpenWRT firmware, without requiring user intervention.
In t2 update
, the SAMD21 is updated last because doing so automatically reboots the SAMD21, which means the Tessel connection is lost.
A PR that warns the user to take the device out of DFU mode and to try the command again.
:+1:
A change to t2 restore that flashes factory firmware on the SAMD21, then flashes the OpenWRT firmware, without requiring user intervention inbetween / any potential for additional issues.
Yeah, I think this makes sense. We didn't implement it originally because we were just focusing on borked OpenWRT images. As a user, I think I would expect it to update the firmware as well. Maybe more importantly, we should try to make sure the firmware running on the SAMD21 is compatible with the version of OpenWRT which necessitates flashing the firmware as well. You should be able to switch it into dfu mode from flash mode without a problem.
Also, it would be nice to not have to use dfu-util
anymore. :+1:
We get an error when running Tessel commands with a Tessel in DFU mode. See: https://github.com/tessel/t2-cli/issues/827
This is my experience with upgrading vintage Tessels by hand. 🙃 My goal was to boot into DFU mode and flash the latest OpenWRT and latest SAMD21 firmware.
I guess I'm confused about
t2 restore
andt2 update
in general. Right now, when I plug in a T2 in DFU mode, I'm not sure what I can do with it from the command line. We have the option to physically boot it into this mode, but is there no way for the user to do anything with it?My expectation is that
t2 update
would suggest only flashing firmware if we are in DFU mode. I also expectedt2 restore
to flash OpenwWRT, possibly.