This refactors the code as it was getting very confusing; before FuSmbios was
reading both SMBIOS and the kernel-provided DT -- and various things were
injecting overrides in three different place. To properly support FDT remove
one layer of indirection.
This also lets us use the compatible strings to enable plugins specifying the
flag _REQUIRE_HWID -- which means we only load the plugin if it's got a chance
of working. e.g.
[aspeed,ast2500]
This will eventually allow us to reconstruct a SBoM using a UEFI file volume.
This can be used like this `fwupdtool firmware-parse efi/fwupdx64.efi pefile`
to produce:
<firmware gtype="FuPefileFirmware">
<data size="0xef59">MZ.</data>
<firmware>
<id>.text</id>
<offset>0x2d0</offset>
<size>0x7bab</size>
<data size="0x7bab">H...QRH.=....H.5</data>
</firmware>
...
<firmware gtype="FuCoswidFirmware">
<id>fwupd-efi:fwupdx64</id>
<idx>0x7</idx>
<version>1.4</version>
<offset>0xc4e0</offset>
<size>0xce</size>
<data size="0xce">..een-US</data>
<version_scheme>semver</version_scheme>
<product>fwupdx64</product>
<summary>EFI helpers to install system firmware</summary>
<colloquial_version>1.3-7-g881a508</colloquial_version>
<link>
<href>https://spdx.org/licenses/LGPL-2.0.html</href>
<rel>license</rel>
</link>
<entity>
<name>Richard Hughes</name>
<regid>hughsie.com</regid>
<role>maintainer</role>
<role>tag-creator</role>
</entity>
</firmware>
</firmware>
Only build libfwupdplugin source files once; we were only using one
non-exported symbol and so move that to the exported map so we can just link
the library in the self tests.
This drops the requirement on us being so strict on a particular ABI version,
and also more strongly discourages out of tree plugin development.
We should still strive to keep API stable, and as such keep a symbol map still.
Use rpath instead for the static plugins, and set the plugin install directory
to just fwupd-$ABI$ as we're storing more than just plugins here now.
Saving the quirks in the GResource section worked well, but it made the build
system very complicated and also meant the .data section was duplicated in
both `fwupd` and `fwupdtool` -- negating a lot of the hard-fought savings.
Simplify this feature so that we just `cat` all the quirk files together, then
gzip them into a single file. This means that at startup fwupd only needs to
check the mtime of one file, and weirdly it's actually faster to load a smaller
compressed file from disk that it is to load multiple uncompressed files.
This feature adds support for platform capability BOS descriptors which allows
the device itself to ship quirk data.
Use `sudo fwupdtool get-devices --save-backends=FILENAME` to save fake backend
devices to a file. This allows easy creation of self tests that do not require
physical hardware.
This is being used for other products, e.g. USB4 docks.
If non-Intel firmware is being used (e.g. ASMedia) then the explicit
calls to `fu_intel_thunderbolt_nvm_new()` can be changed to something
like `fu_firmware_new_from_gtypes()` with all the formats listed.
These are currently used interchangeably since there was indecisiveness
which to use as the feature was being developed.
As outward facing it will be named with "settings", change all uses
in the code to match this.
Semantically it is the desire of the security attribute, not the bios
attribute, i.e. you could imagine that a specific attribute would have
to be *foo or bar or baz* for HSI-1 and *only foo* for HSI-2
Also make it easier to add possible BIOS attribute target values in
plugin code.
tristate features will automatically disable if dependencies marked
as required are missing.
Packagers can manually override using `auto_features`.
Link: https://mesonbuild.com/Build-options.html#features
This allows us to override the location we load data files from, which
allows us to do more kinds of installed tests in the future.
Also, move the global data/tests content into the place that it is used
as it was getting impossible to manage.
Now two plugins are using hardcoded SPI constants for various CFI chips,
and it makes sense to have some common quirk data that can be used by
both.
Add a FuSpiChip helper object that can be used by FuDevice subclasses
to get the specific SPI commands to use for each flash ID.
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.
