Otherwise the following build error happens:
../fwupd-1.6.0/plugins/analogix/fu-analogix-device.c:54:10: error: ‘G_USB_DEVICE_DIRECTION_HOST_TO_DEVICE’ undeclared (first use in this function)
54 | G_USB_DEVICE_DIRECTION_HOST_TO_DEVICE,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../fwupd-1.6.0/plugins/analogix/fu-analogix-device.c:54:10: note: each undeclared identifier is reported only once for each function it appears in
../fwupd-1.6.0/plugins/analogix/fu-analogix-device.c:55:10: error: ‘G_USB_DEVICE_REQUEST_TYPE_VENDOR’ undeclared (first use in this function)
55 | G_USB_DEVICE_REQUEST_TYPE_VENDOR,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../fwupd-1.6.0/plugins/analogix/fu-analogix-device.c:56:10: error: ‘G_USB_DEVICE_RECIPIENT_DEVICE’ undeclared (first use in this function)
56 | G_USB_DEVICE_RECIPIENT_DEVICE,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../fwupd-1.6.0/plugins/analogix/fu-analogix-device.c: In function ‘fu_analogix_device_receive’:
../fwupd-1.6.0/plugins/analogix/fu-analogix-device.c:96:10: error: ‘G_USB_DEVICE_DIRECTION_DEVICE_TO_HOST’ undeclared (first use in this function)
96 | G_USB_DEVICE_DIRECTION_DEVICE_TO_HOST,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../fwupd-1.6.0/plugins/analogix/fu-analogix-device.c:97:10: error: ‘G_USB_DEVICE_REQUEST_TYPE_VENDOR’ undeclared (first use in this function)
97 | G_USB_DEVICE_REQUEST_TYPE_VENDOR,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../fwupd-1.6.0/plugins/analogix/fu-analogix-device.c:98:10: error: ‘G_USB_DEVICE_RECIPIENT_DEVICE’ undeclared (first use in this function)
98 | G_USB_DEVICE_RECIPIENT_DEVICE,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
and more...
On Alterlake and newer hardware the Platform Health Assessment Record
data can be used by the IHV to debug why a specific capsule update
failed. Any custom firmware loaded by the OEM can be identified and
used to further debug the root cause.
The code currently assumes that the firmware sections are in sorted
order (e.g. using images_cnt as the current index). This seems to
be the case with real firmware images, but is not actually guaranteed
by anything. Rewriting the code to use the actual index from the WA
header is a little difficult so just assert this condition for now.
The value of `self->firmware_index` is not valid until we call
`fu_wac_device_ensure_firmware_index`. Because of this, we would always
request the firmware for index 0. If that slot is currently active then
our attempt to program it will fail since the pages are write-protected.
Annoyingly the only signs that something has gone wrong are that the
flash completes almost instantly and the firmware version never changes.
To fix this we re-order our usage of the variable to be after it
becomes valid. We also add a noisy failure message that is triggered
if no blocks are written.
Fixes: 7afd7cba0d ("Use FuFirmware as a container for firmware images")
Version numbers used by Wacom firmware are typically coded as packed BCD
numbers. The minor version numbers are typically rendered with leading
zeros in the wild, though it appears fwupd doesn't follow this same
visual convention.
Some example versions:
* { 0x00, 0x05 } --> 0.05 (Wacom rendering) / 0.5 (fwupd rendering)
* { 0x01, 0x01 } --> 1.01 (Wacom rendering) / 1.1 (fwupd rendering)
* { 0x01, 0x23 } --> 1.23 (Wacom rendering) / 1.23 (fwupd rendering)
Fixes: 872ec1b68f (Add an experimental plugin to update some new Wacom tablets)
While the flag bytes in Flash on the PS175 indicate which partition it is
desired the device boot, the device may actually boot something else
because it performs some kind of integrity check on firmware images before
booting them. If the image specified by the flag bytes fails validation,
the device instead boots partition 3 which should be treated as read-only.
The device provides a register on I2C that indicates which partition is
actually running, so probe that register rather than assuming the device
is running the image that the flag bytes specify.
Signed-off-by: Peter Marheine <pmarheine@chromium.org>
Having a mutable global flash layout makes it difficult to reason about which
flash regions will be affected by any given flashrom operation. Make copies of
the layout from a template instead, and default-exclude regions from
operations.
fu_dfu_tool_get_default_device returns a newly create FuDfuDevice
'device'; but since it is marked as g_autoptr, it is destroyed when
leaving the scope and the caller receives garbage.
So steal the pointer before leaving the scope.
,----
| ==697985== Invalid read of size 8
| ==697985== at 0x4B50F49: g_type_check_instance_is_fundamentally_a (gtype.c:4080)
| ==697985== by 0x4B3A988: g_object_unref (gobject.c:3421)
| ==697985== by 0x406CF3: glib_autoptr_clear_GObject (gobject-autocleanups.h:27)
| ==697985== by 0x406DD5: glib_autoptr_clear_FwupdDevice (gusb-autocleanups.h:17)
| ==697985== by 0x406E9C: glib_autoptr_clear_FuDevice (fu-device.h:18)
| ==697985== by 0x406EE3: glib_autoptr_clear_FuUsbDevice (fu-usb-device.h:22)
| ==697985== by 0x406F6A: glib_autoptr_clear_FuDfuDevice (fu-dfu-device.h:19)
| ==697985== by 0x406F88: glib_autoptr_cleanup_FuDfuDevice (fu-dfu-device.h:19)
| ==697985== by 0x40898D: fu_dfu_tool_read (fu-dfu-tool.c:577)
| ==697985== by 0x407518: fu_dfu_tool_run (fu-dfu-tool.c:162)
| ==697985== by 0x4097E0: main (fu-dfu-tool.c:959)
| ==697985== Address 0x67fbfe0 is 640 bytes inside a block of size 672 free'd
| ==697985== at 0x48430E4: free (vg_replace_malloc.c:755)
| ==697985== by 0x4BD124C: g_free (gmem.c:199)
| ==697985== by 0x4BEB76F: g_slice_free1 (gslice.c:1180)
| ==697985== by 0x4B4FDBB: g_type_free_instance (gtype.c:1993)
| ==697985== by 0x406CF3: glib_autoptr_clear_GObject (gobject-autocleanups.h:27)
| ==697985== by 0x406DD5: glib_autoptr_clear_FwupdDevice (gusb-autocleanups.h:17)
| ==697985== by 0x406E9C: glib_autoptr_clear_FuDevice (fu-device.h:18)
| ==697985== by 0x406EE3: glib_autoptr_clear_FuUsbDevice (fu-usb-device.h:22)
| ==697985== by 0x406F6A: glib_autoptr_clear_FuDfuDevice (fu-dfu-device.h:19)
| ==697985== by 0x406F88: glib_autoptr_cleanup_FuDfuDevice (fu-dfu-device.h:19)
| ==697985== by 0x407762: fu_dfu_tool_get_default_device (fu-dfu-tool.c:191)
| ==697985== by 0x408736: fu_dfu_tool_read (fu-dfu-tool.c:592)
| ==697985== Block was alloc'd at
| ==697985== at 0x484086F: malloc (vg_replace_malloc.c:380)
| ==697985== by 0x4BD4938: g_malloc (gmem.c:106)
| ==697985== by 0x4BEC1F4: g_slice_alloc (gslice.c:1069)
| ==697985== by 0x4BEC85D: g_slice_alloc0 (gslice.c:1095)
| ==697985== by 0x4B5511A: g_type_create_instance (gtype.c:1893)
| ==697985== by 0x4B3CB8C: g_object_new_internal (gobject.c:1939)
| ==697985== by 0x4B3E107: g_object_new_valist (gobject.c:2282)
| ==697985== by 0x4B3E63C: g_object_new (gobject.c:1782)
| ==697985== by 0x40B0CF: fu_dfu_device_new (fu-dfu-device.c:571)
| ==697985== by 0x407723: fu_dfu_tool_get_default_device (fu-dfu-tool.c:230)
| ==697985== by 0x408736: fu_dfu_tool_read (fu-dfu-tool.c:592)
| ==697985== by 0x407518: fu_dfu_tool_run (fu-dfu-tool.c:162)
`----
