This could be used, for instance, to set a property on ThunderBolt controllers
inside Dell computers saying that they support forcing the power level during
coldplug. It could also be used to set the dock type for the synapticsmst hub.
Adding this level of complexity allows us to avoid the creep of HAVE_DELL and
HAVE_LENOVO into seemingly unrelated plugins, and also allows us to have
multiple vendor plugins providing the same end result with two different
vendor-specific mechanisms.
Thunderbolt has a new kernel interface starting from version 4.13,
which simplifies updating the host controller and devices: the
kernel now exposes a sysfs interface for the non-volatile memory
as a device node. This can be used to write the new firmware blob.
Updates are then triggered also via a simple write to a sysfs
file (nvm_authenticate), which in turn is also used for error
reporting.
The plugin should be functionally, but a few items are missing:
- image verification
- safe mode handling
This should hopefully fix the error:
../../checkout/fwupd/plugins/amt/fu-plugin-amt.c:238:1: error: initializer element is not constant
uuid_le MEI_IAMTHIF = UUID_LE(0x12f80028, 0xb4b7, 0x4b2d, \
^
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This reverts commit 1a5c7f6fe5.
The warning is obviously complaining that the value cannot be evaluated
at compile time, rather than that it’s being assigned to a const storage
location.
Unfortunately it seems that the definition of UUID_LE is not const (or
not evaluatable as const by the compiler) on a Debian Jessie machine,
which causes compilation to fail with:
../../checkout/fwupd/plugins/amt/fu-plugin-amt.c:238:1: error: initializer element is not constant
const uuid_le MEI_IAMTHIF = UUID_LE(0x12f80028, 0xb4b7, 0x4b2d, \
^
Fix that by dropping the const. Sadness.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
When my SNES30 controller was in bootloader mode, it wouldn't update,
and when it was in controller mode, it tried and failed. Now, it prints
out the instructions on how to reset the device if it's in controller
mode, and if it's in bootloader mode, it successfully installs the
firmware update from the .DAT file.
Pre-filter the pending LuDeviceBootloaderRequest's after they are parsed so
that we know exactly how many packets need to be sent to the hardware.
As shown in https://github.com/hughsie/fwupd/issues/155, people get worried
if the progress bar finishes before 100% as they'll wonder if all the writing
completed successfully.
The kernel offers two interfaces for manipulation of EFI variables.
Make sure that at least one of these is available.
If another interface is added (and supported by efivar) then this
list will need to be appended as well.
This was raised as a potential problem in #100.
Before:
$ fwupdmgr install XPS_test.cab
Retrying as an offline update...
Scheduling… UEFI firmware update failed: -1
After:
$ fwupdmgr install XPS_test.cab
Retrying as an offline update...
Scheduling… UEFI firmware update failed: libfwup.c:733 get_paths(): could not find shim or fwup on ESP: No such file or directory
