No helpful warnings when Tessel is in DFU mode

[tcr]

We get an error when running Tessel commands with a Tessel in DFU mode. See: #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 and t2 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 expected t2 restore to flash OpenwWRT, possibly.

[johnnyman727]

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.

[rwaldron]

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

[tcr]

@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.

[tcr]

And also, should t2 restore reflash the SAMD21 firmware as well? Why not?

[rwaldron]

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.

[tcr]

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:

• My OpenWRT partition is screwed up. — Run t2 restore.
• My Firmware on the SAMD21 is screwed up. — Manually download a firmware file from builds.tessel.io. Install 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.

[tcr]

Okay, so here's what I propose I try. A PR that does the following:

1. A PR that warns the user to take the device out of DFU mode and to try the command again.
2. 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.

If I can't accomplish number 2) then I'd concede it's not worth the cost of integrating into the CLI. ;)

[rwaldron]

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.

[johnnyman727]

A PR that warns the user to take the device out of DFU mode and to try the command again.

👍

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. 👍