A UF2 device exposes a VFAT block device (sometimes called a Mass
Storage Device) which has a virtual file called `INFO_UF2.TXT` where
metadata can be read. It may also have a the current firmware exported
as a file called `CURRENT.UF2` which is in a 512 byte-block UF2 format.
Writing any file to the MSD will cause the firmware to be written.
Sometimes the device will restart and the volume will be unmounted
and then mounted again. In some cases the volume may not “come back”
until the user manually puts the device back in programming mode.
Match the block devices using the VID*PID, UUID or label, and then
create a UF2 device which can be used to flash firmware.
Note: We only read metadata from allow-listed IDs to avoid causing
regressions on non-UF2 volumes. To get the UUID and label you can
use commands like:
udisksctl info -b /dev/sda1
The plugin is using Nordic Semiconductor HID config channel to perform
devices update directly atteched via USB and BLE.
Current implementation supports FW images compatible with the nRF Secure
Immutable Bootloader.
This version has been tested with nRF52840-DK board.
Signed-off-by: Denis Pynkin <denis.pynkin@collabora.com>
Signed-off-by: Ricardo Cañuelo <ricardo.canuelo@collabora.com>
Signed-off-by: Richard Hughes <richard@hughsie.com>
The vendor does not intend on uploading firmware for this EOL device.
For the Solo V2 the vendor wants to use a different flashing protocol,
so all this is just dead code now.
We were calling g_module_symbol() 2703 times, which is actually more
expensive than you'd think.
It also means the plugins are actually what we tell people they are:
A set of vfuncs that get run. The reality before that they were dlsym'd
functions that get called at pretty random times.
To use this use `sudo systemctl edit fwupd.service` and set
`Environment="FWUPD_SYSFSFWDIR=/usr/share/installed-tests/fwupd"`
Fixes https://github.com/fwupd/fwupd/issues/3441
We only had to pile everything into the src/fuzzing/firmware directory
because honggfuzz could not cope with more than one input path.
This way each plugin is self contained and easy to copy.
Also, install the fuzzing builder objects as this fixes the installed
tests when srcdir does not exist.
Based on a patch by Jan Tojnar <jtojnar@gmail.com>, many thanks.
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.
There's no actual hardware to test this against yet, but this is how I
would lay out a plugin if there was.
We still need to work out a generic encapsulation for the offer and
payload (for each component and bank) so this can work with LVFS and
fwupd.
This avoids having to hardcode profile targets in multiple places
and also fixes the confusing entry points into scripts both by
arguments and environment variables.
It also makes the setup script a lot more debuggable and scalable.
OS detection is a lot more robust, where it will try to use pip to
set up the distro python package, and if pip is missing try to install
it.
If OS detection fails now, a user can use --os on contrib/setup for
specifying it.
This allows us to do a few things:
* Remove the runtime dep on Python 3, which is tricky for ChromeOS
* Test composite devices more efficiently, only writing once per test
* Automatically upload signed reports for successful device tests.
