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)
`----
sysfs paths don't have strong guarantees about semantics, so attempting
to parse an I2C bus number out of a sysfs path of some device is likely
to be fragile. Instead take advantage of the device layout to find the
I2C bus an LSPCON is on without trying to parse it out of paths.
The bus the device is on is a sibling device of type i2c-dev, so by
locating an i2c-dev device that is a sibling of the detected LSPCON
device, the /dev path of the bus can be found robustly.
Support for specifying an I2C bus by path rather than number is also
required in flashrom, implemented at
https://review.coreboot.org/c/flashrom/+/51967
Signed-off-by: Peter Marheine <pmarheine@chromium.org>
The dependencies to generate the "updating..." splash screen are non-trivial, and
pointless in headless systems. Add an option to disable the generation entirely.
This prevents problems when cross compiling. Using help2man is now also of
limited use; if we can just tell the user to use --help we do not need to keep
the manual in sync.
It also allows us to drop the several other supporting files that we use when
the help2man output isn't actually that useful.
Fixes https://github.com/fwupd/fwupd/issues/3025
