At the moment there are commands to convert one file format to another, but not
to 'merge' or alter them. Some firmware files are containers which can store
multiple images, each with optional id, idx and addresses.
This would allow us to, for instance, create a DfuSe file with two different
raw files that are flashed to different addresses on the SPI flash. It would
also allow us to create very small complicated container formats for fuzzing.
This can be used by writing a `firmware.builder.xml` file like:
<?xml version="1.0" encoding="UTF-8"?>
<firmware gtype="FuBcm57xxFirmware">
<version>1.2.3</version>
<image>
<version>4.5.6</version>
<id>header</id>
<idx>456</idx>
<addr>0x456</addr>
<filename>header.bin</filename>
</image>
<image>
<version>7.8.9</version>
<id>payload</id>
<idx>789</idx>
<addr>0x789</addr>
<data>aGVsbG8=</data>
</image>
</firmware>
...and then using something like:
# fwupdtool firmware-convert firmware.builder.xml firmware.dfu builder dfu
This was a new file format to help out an OEM, but they didn't actually use it.
If we do need it in the future, it would some back as a src/ helper, not in
plugins/dfu.
We don't support any hardware that actually uses this proposed standard, and
nowadays there is much better public-key encryption people can easily use.
The libxmlb library is much faster to query, and does not require the daemon
to parse the XML metadata at startup. It's a zero-copy mmap design that is more
modern and less clunky.
RSS has reduced from 3Mb (peak 3.61Mb) to 1Mb (peak 1.07Mb) and the startup
time has gone from 280ms to 250ms.
Apparently the linker complains when dlopen'ing a plugin that's linked against
the libfwupdprivate library the daemon is using. This only seems to happen when
using distro packages...
Five plugins (soon to be 7) are linking to the DFU plugin just for this simple
segment-aware chunking functionality. Move this into common code to make
building simpler.
Previously, the various install paths were obtained using get_option
as needed.
This patch unifies the directory selection inside the top-level meson
file as requested in https://github.com/hughsie/colord/pull/62.
This is slightly more verbose than desired as we also have to include the quirk
information when running the dfu-tool, which does not have an already set-up
FuQuirks object as it has no plugin.
The hardware does not support the DFU specification enough for a metadata table
to be embedded, so there's no way to reliably detect the 'devo' cipher, thus
making the support useless.
Automake and autoconf are impossible to fully understand and Meson now provides
everything we need for a much smaller, faster, and more understandable build.
See http://mesonbuild.com/ for more information.
