4ade76ea90
Implement the firmware extension (fwext) upload module for
Validity/Synaptics VCSFW sensors. When the sensor reports no
firmware loaded (GET_FW_INFO returns status 0xB004), the driver
uploads the .xpfwext firmware file using the following sequence:
1. WRITE_HW_REG32 (0x08) to prepare hardware register
2. READ_HW_REG32 (0x07) to verify register state
3. Load .xpfwext file from filesystem search paths
4. For each 4KB chunk:
a. Send db_write_enable blob (encrypted auth token)
b. WRITE_FLASH (0x41) with chunk payload
c. CLEANUP (0x1A) to commit chunk
5. WRITE_FW_SIG (0x42) to upload RSA signature
6. GET_FW_INFO (0x43) to verify successful upload
7. REBOOT (0x05 0x02 0x00) to activate new firmware
Architecture: Uses the NULL-callback subsm pattern where SEND
states call vcsfw_cmd_send(self, ssm, cmd, len, NULL) and RECV
states read self->cmd_response_status/data directly. This avoids
the double-advance bug with fpi_ssm_start_subsm auto-advancing
the parent.
New files:
- validity_fwext.h: Structures, SSM state enum, API declarations
- validity_fwext.c: Upload SSM, file parser, command builders
- validity_blob_dbe_009a.inc: db_write_enable blob for 06cb:009a
- test-validity-fwext.c: 19 unit tests covering all pure functions
Modified files:
- validity.h: Add cmd_response_status field to FpiDeviceValidity
- validity.c: Add OPEN_UPLOAD_FWEXT state to open sequence
- vcsfw_protocol.c: Save status in cmd_receive_cb for RECV states
- meson.build: Add validity_fwext.c to driver sources
Test results: 34 OK, 0 Fail, 2 Skipped
|
||
|---|---|---|
| .. | ||
| aes2501 | ||
| aes3500 | ||
| egis0570 | ||
| egismoc | ||
| egismoc-05a1 | ||
| egismoc-0586 | ||
| egismoc-0587 | ||
| elan | ||
| elan-cobo | ||
| elanmoc | ||
| elanspi | ||
| focaltech_moc | ||
| fpcmoc | ||
| goodixmoc | ||
| nb1010 | ||
| realtek | ||
| realtek-5816 | ||
| synaptics | ||
| upektc_img | ||
| upektc_img-tcs1s | ||
| uru4000-4500 | ||
| uru4000-msv2 | ||
| validity | ||
| vfs0050 | ||
| vfs301 | ||
| vfs5011 | ||
| vfs7552 | ||
| capture.py | ||
| create-driver-test.py.in | ||
| driver.test.in | ||
| hwdb-check-unsupported.py | ||
| libfprint.supp | ||
| meson.build | ||
| README.md | ||
| test-device-fake.c | ||
| test-device-fake.h | ||
| test-fp-context.c | ||
| test-fp-device.c | ||
| test-fpi-assembling.c | ||
| test-fpi-device.c | ||
| test-fpi-ssm.c | ||
| test-generated-hwdb.sh | ||
| test-utils.c | ||
| test-utils.h | ||
| test-validity-fwext.c | ||
| test-validity-tls.c | ||
| test.in | ||
| umockdev-test.py | ||
| unittest_inspector.py | ||
| valgrind-python.supp | ||
| virtual-device.py | ||
| virtual-image.py | ||
umockdev Tests
umockdev tests use fingerprint devices mocked by umockdev
toolchain.
This document describes how to create test cases (for USB devices). Many of these tests are tests for image devices, where a single image is captured and stored.
Other kinds of umockdev tests can be created in a similar manner. For
match-on-chip devices you would instead create a test specific custom.py
script, capture it and store the capture to custom.pcapng.
'capture' and 'custom' Test Creation
For image devices the capture.py script will be used to capture one reference
image. If the driver is a non-image driver, then a custom.py script should be
created in advance, which will be run instead.
-
Make sure that libfprint is built with support for the device driver that you want to create a test case for.
-
From the build directory, run tests/create-driver-test.py as root. Note that if you're capturing data for a driver which already has a test case but the hardware is slightly different, you might want to pass a variant name as a command-line options, for example:
$ sudo tests/create-driver-test.py driver [variant]
-
If the capture is not successful, run the tool again to start another capture.
-
Add driver test name to
drivers_testsin themeson.build, as instructed, and change the ownership of the just-created test directory in the source. -
Check whether
meson testpasses with this new test.
Note. To avoid submitting a real fingerprint when creating a 'capture' test, the side of finger, arm, or anything else producing an image with the device can be used.
Possible Issues
Other changes may be needed to get everything working. For example the
elan driver relies on a timeout that is not reported correctly. In
this case the driver works around it by interpreting the protocol
error differently in the virtual environment (by means of
FP_DEVICE_EMULATION environment variable).