This allows for proper locking between executions of fwupdtool in
Chromium OS minijail environment. It is needed after commit
9cf5f8f7ff was introduced.
Change-Id: I37b33c8d1fbe97ec9baddc5f77ea94e2f4ff1fa4
The code currently assumes that the firmware sections are in sorted
order (e.g. using images_cnt as the current index). This seems to
be the case with real firmware images, but is not actually guaranteed
by anything. Rewriting the code to use the actual index from the WA
header is a little difficult so just assert this condition for now.
The value of `self->firmware_index` is not valid until we call
`fu_wac_device_ensure_firmware_index`. Because of this, we would always
request the firmware for index 0. If that slot is currently active then
our attempt to program it will fail since the pages are write-protected.
Annoyingly the only signs that something has gone wrong are that the
flash completes almost instantly and the firmware version never changes.
To fix this we re-order our usage of the variable to be after it
becomes valid. We also add a noisy failure message that is triggered
if no blocks are written.
Fixes: 7afd7cba0d ("Use FuFirmware as a container for firmware images")
Version numbers used by Wacom firmware are typically coded as packed BCD
numbers. The minor version numbers are typically rendered with leading
zeros in the wild, though it appears fwupd doesn't follow this same
visual convention.
Some example versions:
* { 0x00, 0x05 } --> 0.05 (Wacom rendering) / 0.5 (fwupd rendering)
* { 0x01, 0x01 } --> 1.01 (Wacom rendering) / 1.1 (fwupd rendering)
* { 0x01, 0x23 } --> 1.23 (Wacom rendering) / 1.23 (fwupd rendering)
Fixes: 872ec1b68f (Add an experimental plugin to update some new Wacom tablets)
The call to g_proxy_resolver_get_default() is (transfer none) and so unref'ing
it causes GLib to get very upset. Also, move it to be per-FwupdClient rather
than per-request as it can be expensive to call in the PAC-runner case.
Reverts small part of 99832622e1.
EFI_APP_LOCATION conf var (or FWUPD_EFIAPPDIR env var) is needed for
fu_common_get_path (FU_KIND_PATH_EFIAPPDIR)
to function properly
For some users typing 'fwupdmgr update' just deploys all updates to all hardware,
and that might come as a shock. Ask the user to confirm all actions explicitly
and show the update notes in a warning box rather than plain text on the console.
While the flag bytes in Flash on the PS175 indicate which partition it is
desired the device boot, the device may actually boot something else
because it performs some kind of integrity check on firmware images before
booting them. If the image specified by the flag bytes fails validation,
the device instead boots partition 3 which should be treated as read-only.
The device provides a register on I2C that indicates which partition is
actually running, so probe that register rather than assuming the device
is running the image that the flag bytes specify.
Signed-off-by: Peter Marheine <pmarheine@chromium.org>
Having a mutable global flash layout makes it difficult to reason about which
flash regions will be affected by any given flashrom operation. Make copies of
the layout from a template instead, and default-exclude regions from
operations.
If the device is on battery power, the device will have at least one inhibit
and be in FWUPD_DEVICE_FLAG_UPDATABLE_HIDDEN state.
It's still supported, and it's misleading to suggest there are no updates
available. Just check both flags.
Fixes the 3rd half (sic) of https://github.com/fwupd/fwupd/issues/3156
