At the moment FuChunks are sometimes mutable, and sometimes immutable, and it's
all a bit too low level for comfort.
Before we can do any kind of optimisation or verification we need plugins to
stop reading directly from the C structure. The aim here is to make FuChunk
optionally mutable without making assumptions about the memory model, and also
to be able to introspect it for the docs.
This bootloader is *weird* -- the chip ID is the first two bytes of the serial
number and the data is offset and encoded in UTF-8, not UTF-16.
The sector information is also wrong. Gah!
The docs for `fwupd_device_get_children()` make it very clear that only the
parent should be assigned. Also add a warning to `fwupd_device_add_child()`
explaining it is for internal daemon use only.
Some systems remove the BootXXXX entry we add (so we can run fwupdx64.efi) and
thus the firmware update does not run. Most commonly this failure is seen with
Lenovo systems that call the helpful option 'Boot Order Lock'.
Hopefully when we depend on the new kernel bios interface sysfs API in we can
check in ->prepare(), not after reboot, but until that we can mark the update
failure as transient as the user can actually fix the problem themselves.
Fixes https://github.com/fwupd/fwupd/issues/2801
We forgot to include FwupdClientDownloadFlags when adding the original method
fwupd_client_install_release() -- and we want to use additional download flags
for operations in the future.
The metadata might want to pass more than one location URI to the client, for
instance if the file is available from more than one HTTP mirror.
Use the noun of location to match the AppStream <artifact> naming; this is the
last place where LVFS AppStream diverges from the official specification and
it would be good to bring fwupd back into line -- although the LVFS will have
to write both elements for a very long time.
See https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html
Also: we're not changing the format of the `Uri` GVariant key to preserve both
forward and backwards compatibility of the library. We can remove it when we
next break API.
If we're creating the child device using `Children=FuFooDevice|FOO&I2C_01` in
the quirk file then there's not actually anywhere to call FuDevice->setup()
on the child.
The logical place to do it is when we setup the parent, which is a NOP if
already called for the child. We also don't need to convert the child instance
IDs as it's already being handled during the child setup.
Tested-By: Ricky Wu <ricky_wu@realtek.com>
In fwupd 1.5.1 and before, we allowed ESP on external device.
From 56d816a5, (Fall back to FAT32 internal partitions for detecting
ESP, 2020-11-11), we started to only consider internal devices only.
While it would be desirable to only consider internal devices for
fallback esp partition, there're some setup that put ESP on external
device, e.g. full disk encryption with /boot on a USB.
Let's allow external ESP again.
This plugin supports reading the keyboard firmware version at runtime and
rebooting the keyboard to USB DFU mode. Tested with firmware uploaded to
embargo-system76.
When this is done, include:
* Including the hash
* Including anything that is not ABI stable in plugins yet
Suggested-by: Simon McVittie <smcv@debian.org>
Each -dev package needs to depend on all dependencies' -dev packages
that are required when linking against the included library with
pkg-config.
Closes: #980691, #980684
This allows much better compression (-60%) than gziping them individually and
also allows us to build the capsule UX images as part of the build stage.
Also add more popular screen resolutions for laptops you can buy in 2021.
The coreboot plugin never actually gained the ability to write. As it stands a
coreboot system now adds *two* system-firmware devices (from both flashrom and
coreboot) which isn't ideal.
Just allow flashrom to enumerate quirked devices and add coreboot-specific
metadata as required. If we require some kind of cbfs parsing then we can do
that in FuFlashromDevice->prepare_firmware().
Although we could reconstruct the PCR0 value on the LVFS from the (already
included) event log, it's much more scalable if the client just provides the
data that we want to filter by.
I was asked the other day how many machines would support a /dev/mem mmap'd
update mechanism, and I had to say that I didn't know. We use direct port IO in
the SuperIO plugin too, and it would be good to know how quickly we need to
port this to something else.
It's unusual, but if BIOS lock enable is enabled (so we cannot *change* the
value of BIOSWE) but the BIOS is already WE then we can write to the hardware
just fine.
