Resetting the CMOS before a write when switching branch will cause a lock on\
reboot which requires hard power off.
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
It's actually quite hard to build a front-end for fwupd at the moment
as you're never sure when the progress bar is going to zip back to 0%
and start all over again. Some plugins go 0..100% for write, others
go 0..100% for erase, then again for write, then *again* for verify.
By creating a helper object we can easily split up the progress of the
specific task, e.g. write_firmware().
We can encode at the plugin level "the erase takes 50% of the time, the
write takes 40% and the read takes 10%". This means we can have a
progressbar which goes up just once at a consistent speed.
Reset the CMOS based on a private flag. Tested on coreboot using an
offset of 123. Required when a CMOS layout or default option has
changed as the resulting flash will have 0's for the modified option.
As we are only writing to the BIOS region, we only need to backup the BIOS
region. The will avoid the error "failed to back up original firmware" if
regions such as the ME can't be read.
There are now multiple plugins using drm_dp_aux_dev interface which
may potentially be combined with an amdgpu. Prevent exercising this
interface with any plugin using DP aux unless a new enough kernel is
installed.
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.
sysfs paths don't have strong guarantees about semantics, so attempting
to parse an I2C bus number out of a sysfs path of some device is likely
to be fragile. Instead take advantage of the device layout to find the
I2C bus an LSPCON is on without trying to parse it out of paths.
The bus the device is on is a sibling device of type i2c-dev, so by
locating an i2c-dev device that is a sibling of the detected LSPCON
device, the /dev path of the bus can be found robustly.
Support for specifying an I2C bus by path rather than number is also
required in flashrom, implemented at
https://review.coreboot.org/c/flashrom/+/51967
Signed-off-by: Peter Marheine <pmarheine@chromium.org>
Created lspcon-i2c-spi flashrom device that uses udev to detect i2c
devices that can be updated with the lspcon-i2c-spi flashrom programmer.
This change implements the logic from crrev.com/c/2792124 adapted to the
upstream flashrom plugin.
This change allows other device types to derive from common flashrom
code in the flashrom-device type.
Change-Id: Ic963fd586e0a73153c54889fce50055753a1bf5c
There is a lot of code in fwupd that just assigns a shared object type to
a FuPlugin, and then for each device on that plugin assigns that same shared
object to each FuDevice.
Rather than proxy several kinds of information stores over two different levels
of abstraction create a 'context' which contains the shared *system* state
between the daemon, the plugins and the daemon.
This will allow us to hold other per-machine state in the future, for instance
the system battery level or AC state.
The best way of not getting something wrong is to not require it in the first
place...
All plugins now use DeviceInstanceId-style quirk matches and we can just drop
the prefix in all files. We were treating HwId=, Guid= and DeviceInstanceId= in
exactly the same way -- they're just converted to GUIDs when building the silo!
At the moment plugins are doing this a few different ways; either looping
through the HwIds manually (e.g. flashrom) or setting a custom flag that is
checked in fu_plugin_setup (e.g. uefi-recovery).
Define a standard 'Plugin' HwId quirk to simplify plugins.
Devices may want to support more than one protocol, and for some devices
(e.g. Unifying peripherals stuck in bootloader mode) you might not even be able
to query for the correct protocol anyway.
It is far too easy to forget to set FWUPD_DEVICE_FLAG_NO_GUID_MATCHING for new
plugins, and without it it all works really well *until* a user has two devices
of the same type installed at the same time and then one 'disappears' for hard
to explain reasons. Typically we only need it for replug anyway!
Explicitly opt-in to this rarely-required behaviour, with the default to just
use the physical and logical IDs. Also document the update behavior for each
plugin to explain why the flag is being used.
This allows you to have two identical Unifying plugged in without one of them
being hidden from the user, at the same time allowing a HIDRAW<->USB transition
when going to and from bootloader and runtime modes.
This removes the workaround added in 99eb3f06b6.
Fixes https://github.com/fwupd/fwupd/issues/2915
