Write the firmware to the usb device, first finding which section to
write to, then breaking into blocks (based on maximum pdu size),
and then into chunks, which are transferred to the device using bulk transfers.
The register specifications have been taken as a superset of the coreboot
documentation as different flags were documented in more detail on various
different platforms.
Having this new data allows us to add future tests and make the current tests
much easier to understand.
This makes perfect sense, because the 'initiator' starts the transaction and
the 'target' is the addressee of the transaction. Even the I²C spec defines the
'master' as 'initiating' the transaction.
This is the same nomenclature now used by the Glasgow project too.
This was an overloaded use of UpdateMessage that didn't make sense.
It doesn't affect the functionality of updating, just the security.
Hints about why the TPM PCR0 reconstruction failed should go
to the wiki page not the device.
We'll instead check this when the user tries to run an update. This
allows them to sign a bootloader after the daemon starts (or remove
a signed bootloader after starting)
Fixes: #2219
Trying to explain why ICL thunderbolt isn't updatable doesn't help
people. It just causes fwupdmgr and fwupdtool to show the device
front and center with a confusing message.
Instead don't populate the message and by the default device filter
it will be hidden.
See #2212 for background.
Reading the sysfs file seemed to have also eaten the `\n` as mentioned
on a bug.
```
├DW5821e Snapdragon X20 LTE:
│ Device ID: fa707b9af86ff44bc17316b6c3e5ea82aab3ce86
│ Summary: Mobile broadband device
│ Current version: T77W968.F1.0.0.4.2.GC.010
│ Vendor: Dell Inc. (USB:0x413c
│ )
│ GUIDs: 64da2d58-8d1b-5e5b-b793-f88ba5a25a8f
│ 761d6124-0002-5185-b767-9adf67bf1a5e
│ 795e079d-093b-5503-aa59-35b832480e95
│ Device Flags: • Updatable
```
This allows delaying the activation of Thunderbolt firmware until
shutdown/reboot or when the dock is unplugged.
This functionality requires features in the kernel:
https://lore.kernel.org/linux-usb/20200622143035.25327-1-mario.limonciello@dell.com/T/#t
Matrix of cases to support:
* Distro Old Linux kernel (doesn't support authenticate on disconnect)
- WD19TB: Should have `skips-restart` flag set
No flush or activate features called in `thunderbolt` plugin.
`dell_dock` plugin will activate at end of composite update
- All other devices: Shouldn't have flags set
Should authenticate in Thunderbolt plugin.
`1 > nvm_authenticate`
* Distro New Linux kernel (supports authenticate on disconnect)
- WD19TB: Should have `usable-during-update` flag set but not `skips-restart`
Should flush image to SPI in `thunderbolt` plugin
`2 > nvm_authenticate_on_disconnect`
Should configure TBT device for authenticate on disconnect
`1 > nvm_authenticate_on_disconnect`
`dell_dock` plugin will configure dock for authenticate on disconnect
- All other devices: Shouldn't have flags set
Should authenticate in `thunderbolt` plugin.
`1 > nvm_authenticate`
* ChromeOS (supports authenticate on disconnect)
- `thunerbolt.conf` will have `DelayedActivation=true`.
- WD19TB: Should have `usable-during-update` flag set but not `skips-restart`
Should flush image to SPI in `thunderbolt` plugin
`2 > nvm_authenticate_on_disconnect`
Should configure device for authenticate on disconnect
`1 > nvm_authenticate_on_disconnect`
`dell_dock` plugin will configure dock for authenticate on disconnect
- All other devices: Should have both `usable-during-update` and `skips-restart` set
Should flush image to SPI in `thunderbolt` plugin
`2 > nvm_authenticate`
Will activate upon logout/shutdown/reboot
`1 > nvm_authenticate`
This plugin is only enabled when coreboot isn't detected.
It intentionally does not check for EFI to be disabled at startup
since it can also notify the user that UEFI capsule updates are
disabled on the system even if running in UEFI mode.
Unfortunately module type has more than I previously realized.
The meanings that previously were applied fortunately worked for
the most important case (130-180W TBT) but didn't for single C, dual
C or small power (45W) cases.
Since composite_prepare was trying to read and interpret these, it
causes failures when these other ones are encountered.
I reproduced this on a 130W adapter plugged into a single C (type 0x4).
This meant the update wouldn't install since NULL was returned for the
type.
In case a new module ID is added later, also return an "unknown" for
the metadata.
