This makes a lot more sense; we can parse a firmware and export the same XML
we would use in a .builder.xml file. This allows us to two two things:
* Check we can round trip from XML -> binary -> XML
* Using a .builder.xml file we can check ->write() is endian safe
This is really useful when working out HwId quirk values for remote systems.
fwupdtool export-hwids target.hwids
vim target.hwids
fwupdtool hwids target.hwids
The FWUPD_INSTALL_FLAG_FORCE flag has really unclear semantics, and ignoring a
file CRC, checksum or model ID should only be done when using fwupdtool actually
debugging a plugin or firmware parser.
Use the existing --force flag when we want a "gentle nudge" like reuploading
previously processed reports.
Conceptually we were trying to stuff subtly different actions into one vfunc:
* Read firmware from the device to update the verification checksums
* Read a firmware blob from the device for debugging
For the first action we might want to mask out the sections of the flash with
serial numbers (so the verification hashes match the ones published on the LVFS)
and for the second we want just a raw ROM file from the hardware with no
pre-processing that we can compare against an external SPI dumper.
Split out ->dump_firmware to get the raw blob, and allow plugins to also
implement ->read_firmware() if they have to mask out specific offsets or remove
specific images from the FuFirmware container.
In the common case when masking is not required, fall back to using a 'binary'
FuFirmware automatically to make most plugins simpler.
When one result is obsoleted by another, then do not show the old result by
default.
Additionally hide the HSI URLs as this was designed more for GUI clients like
gnome-firmware than CLI tools such as fwupdmgr.
The HSI specification assigns a simple text ID to the current state of firmware
security. As new vulnerabilities are found, and as protection measures are
updated, new requirements will be added to the required firmware behaviours for
each HSI value.
The HSI specification is currently incomplete and in active development, and
so the --force flag is required in all command line tools. The current ID value
will probably change on a given platform so please do not start using the result
for any kind of compliance requirements.
To debug flashing failures it's sometimes requried to get a SPI dump of the
hardware to analysis.
Add a debug-only command that lets us dump the device from the engine.
Mostly for consistency purpose. Details:
* It's confusing that internally the functions for `FwupdClient` use
`upgrade` in the name.
* The logical antonym of `downgrade` is `upgrade` not `update`
* People who don't use the tool frequently may try `get-upgrades`
This feature is turned on with the new fwupdtool option `--enable-json-state`
The intended use case is for ChromeOS to be able to save information about
devices on the system when `fwupdtool update` was run to display in the UX at
a later time.
This is intended for devices that it is not safe to immediately activate
the firmware. It may be called at a more convenient time instead.
Both fwupdmgr and fwupdtool support the feature.
- if called at runtime with fwupdmgr it uses the daemon
- during shutdown fwupdtool uses the pending.db to perform this feature.
Two new arguments added to fwupdtool: `--prepare` and `--cleanup`
They are used only with the `install-blob` command
This makes sure that devices can get rebooted in dell-dock even if using
fwupdtool to install a single blob.
Signed-off-by: Richard Hughes <richard@hughsie.com>
Now that there is actually support to load non-static information
(at least from fwupd perspective) it makes sense to support this
command in both tools.
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.
