chore(core): enable reboot-to-bootloader without experimental features

[grdddj]

Fixes #2316:

• not needing experimental features to trigger reboot-to-bootloader functionality

[matejcik]

changelog-wise, this is a "new" feature. so please move this to added and modify the text accordingly

[grdddj]

Done in the force-push

[STew790]

QA STATUS
I can use trezorctl device reboot-to-bootloader without enabling the experimental features and the device correctly shows the prompt but after the reboot the device boots to normal state and not to bootloader. If I hold my finger over the screen though, it boots to bootloader. Is this the correct behaviour? cc @matejcik probably

Info:

• Suite version: desktop 23.3.1 (8f0a5a67bd1cd0cf95724ee1468ee6ad70aead60)
• Browser: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) TrezorSuite/23.3.1 Chrome/104.0.5112.124 Electron/20.3.12 Safari/537.36
• OS: Linux x86_64
• Screen: 1920x1080
• Device: model T 2.5.4 Universal (revision 557e297)
• Transport: BridgeTransport 2.0.32

[Hannsek]

Can we change the copy on that screen? 😅

[Hannsek]

@STew790 You'll need to wait a bit longer, we are waiting for another pr to merge.

Answer to myself: Yes, we can change it. 😄

[Hannsek]

After releasing this, when users will want to update fw, they click on "update fw" in suite and they will see this screen. Is that right @grdddj? Do we need the confirmation from the user?

[grdddj]

After releasing this, when users will want to update fw, they click on "update fw" in suite and they will see this screen. Is that right @grdddj? Do we need the confirmation from the user?

No idea, I do not know anything about reboot-to-bootloader functionality, but your suggestion makes sense

[Hannsek]

@matejcik maybe?

[matejcik]

After releasing this, when users will want to update fw, they click on "update fw" in suite and they will see this screen. Is that right @grdddj? Do we need the confirmation from the user?

not sure what Suite does, but presumably there will be something about "confirm rebooting to bootloader on your Trezor", and Trezor will show this screen.

and yes, we need user confirmation.

[Hannsek]

Why do we need it? I don't like the fact that the process of updating takes at least 3 clicks on Trezor screen.

+ users don't know what firmware is (and they don't need to know), let alone bootloader…

[prusnak]

Why do we need it? I

Hannsek has a good point here. If every operation in the bootloader requires active user interaction, then we might as well go to bootloader with no confirmation (maybe just a countdown?), because nothing can be done there without user confirming it first. Or are there reasons I don't see?

[matejcik]

In that case i'd much rather remove the initial confirmation from bootloader side than before executing the jump. I don't have a specific argument, but dropping the user to bootloader without any interaction reeks of badness.

it would make the UX flow make more sense too, IMHO: change wording to something like "proceed to firmware installation? y/n", then jump to bootloader blue screen "waiting for host", and then install.

while we're thinking about this, we could allow interaction-less upgrade, i.e., skip the "really install firmware by SatoshiLabs version 2.99" dialog, if (a) the vendor is unchanged, and (b) it is a strict upgrade, and (c) click flag is not set in the vendor header
i.e.:

• reinstall of same version still gets a confirmation
• downgrade gets confirmation
• vendor change gets confirmation, obviously
• any operation with devel firmware gets confirmation

then you would, in firmware, click Yes on "proceed to installing firmware?", Trezor screen goes blue, waits for host, straight to progress bar -> reboot -> you're done

[Hannsek]

Hmm good idea, the less click for user the better.
What is your time estimate?

In that case, we don’t have to do the happy path in bootloader blue. So the user won’t even see that he is in boot loader. I.e. waiting for host screen and progress bar would be black.

[matejcik]

Hmm good idea, the less click for user the better. What is your time estimate?

It's pretty easy actually. Skipping the "install firmware" button when coming from firmware is a matter of two or so lines. Finding the upgrade happy path is also easy to code, but I'd like to go through the implications better, so I'd defer that to the next bootloader release (along with #2794 hopefully)

In that case, we don’t have to do the happy path in bootloader blue. So the user won’t even see that he is in boot loader. I.e. waiting for host screen and progress bar would be black.

Doable, but no point in doing it imho. The firmware upgrade process is special.

[Hannsek]

I agree. I will create another issue after thinking it through.

[bosomt]

Tested yesterday with bootloader_T2T1_qa-2.1.0.bin via trezorctl device reboot-to-bootloader and it worked as expected 🎉

I will retest with final version

[Hannsek]

Can we test this also with Suite?

[bosomt]

I think that we need to ask Suite developers to implement reboot to bootloader feature for TT.
@mroz22 right ? Do you want me to send Trezor Suite issue/feature request or its already covered?

[Hannsek]

@mroz22 is not here this week. So probably @marekrjpolak. cc @matejkriz

[matejkriz]

@bosomt Please test with Suite that nothing has changed and user is able to do the FW upgrade old way (with unplugging).

Feature request on Suite to be specified and prioritized trezor/trezor-suite#7961