Microsoft description about the Status is:
The Status field of the BGRT describes whether the image is currently
displayed on the screen. This is not applicable to the firmware update
display capsule.
Many thanks to Steven Chang for identifying this issue.
Fixes: https://github.com/hughsie/fwupd/issues/935
Do not unset the quirks when closing the device, the _NO_DFU_RUNTIME quirk is
needed when re-opening the device during detach.
Fixes https://github.com/hughsie/fwupd/issues/927
On any devices that normally would require checking for AC also
check that at least one battery on the system has at least 30% to
perform an update.
Fixes: #925
Some SKUs of board 4 and later have silicon that will not work with anything
but EC19 or later. So once flashed up to EC19 prohibit downgrades below that
to keep from bricking devices.
This will perform updates with all currently present metadata.
It is "intended" for usage with local metadata repositories referring
to local files.
fwupdtool however does also support fetching a file from the web
and if the metadata refers to the file on the web it should also work
for that.
This is probably fall out from a previous code re-shuffling.
The EC version is already set elsewhere, and in many cases `self->ec_version`
is `NULL` at this time.
Board 4 was manufactured with package version 89.16.01.00 and this
will prevent properly upgrading between releases. Reset this version
to 00.00.00.00 if detected on this board.
I forgot to include the protocol column when migrating to v3, so create a v4
which ignores the sqlite error if the column already exists.
Fixes https://github.com/hughsie/fwupd/issues/909
It seems uuid_parse() doesn't check the string length before unwrapping the
string into a struct. Fixes:
Conditional jump or move depends on uninitialised value(s)
at 0x4E0C358: uuid_is_null (isnull.c:44)
Some firmware has a different on-device checksum to the hash of the firmware
file itself. This may be because:
* The content is not a binary file, e.g. Intel HEX or SREC
* Only part of the firmware is flashed, e.g. ignoring the bootloader section
* The device checksum is calculated using another method entirely, e.g. PCR0
It's also made complicated as there may be more than one 'correct' device
checksum in some cases, but nothing that a union query can't solve.
We can't actually access the UEFI ROM from userspace, but the PCR0 is a hash
built from the ROM itself. We could use this value to ensure the firmware has
been written correctly, and that the PCR0 matches the expected value specified
in the metadata.
Future metadata from the LVFS will set the protocol the firmware is expected to
use. As vendors love to re-use common terms like DFU for incompatible protocols,
namespace them with the controlling company ID with an approximate reverse DNS
namespace.
This also allows more than one plugin to define support for the same protocol,
for instance rts54hid+rts54hub and synapticsmst+dell-dock.
This solves issues with implementations that require 4k alignment
of pages in BIOS which is seen on certain architectures.
The UEFI spec prescribes that the "minimum" size is the size of
the EFI header but that this may be increased up to larger sizes
due to extended header entries.
