synaptics-mst: Do not allow updating a device with no customer ID

[hughsie]

This is typically when the OEM is using the reference hardware design.

Prevent updates, as there might be a new bug introduced in the reference
firmware that only manifests on one OEM's product. It's up to the OEM to do the
testing and validation.

We need something to tie it back to a physical device model if it's using a
reference firmware and we want to update it.

Type of pull request:

• New plugin (Please include new plugin checklist)
• Code fix
• Feature
• Documentation

[superm1]

@joevt would it be possible for you to retest with this branch to see if it's sufficient (and/or master if it's merged before you get to test).

[joevt]

I tried the new master.

git clone https://github.com/fwupd/fwupd.git
cd fwupd
./contrib/ci/generate_dependencies.py -o ubuntu | sudo xargs apt install -y

One of the build instructions is like this:

Any missing build time dependencies will be mentioned while running:

# meson.

It looks like the instructions want me to enter meson . but that's an error since you cannot pass the source directory . to meson. I think this statement is referring to the later line meson build, so it would be better written as:

Any missing build time dependencies will be mentioned while running meson (see below).

I did the following:

apt build-dep fwupd
meson build
ninja -C build
sudo ninja -C build install
sudo ldconfig

I followed the next instructions

By default everything is placed into /usr/local and most systems won't know how to manage dbus services from /usr/local.

Create /etc/dbus-1/system-local.conf with following contents

but I don't know how to determine if my system needs that.

Then I did

systemctl reload dbus.service
sudo fwupdtool --version 
sudo fwupdmgr --version 

The version of the client for fwupdtool and fwupdmgr is newer but the version of the daemon doesn't change until a restart.
Previously there was a version for efivars but now efivars is not mentioned in the list of versions.

Next, I tested the commands. Today I received a firmware update file from Delock tech support for my Delock 87737 (but they wouldn't give me an updater).

# Delock firmware
sudo fwupdtool parse-firmware FL_4L_MST_56_T6_5.04.132(1).fullrom -v 
# HP firmware
sudo fwupdtool parse-firmware Panamera_firmware.fullrom -v 

For each command, there's a 25 second delay before this message:

failed to setup backend blues: Error calling StartServiceByName for org.bluez: failed to activate service 'org.bluez': timed out (service_start_timeout=25000ms)

I select the new synaptics-mst firmware type and get the following for Delock:

FuSynapticsMstFirmware:
BoardId:                0x2
  FuFirmwareImage:
  Data:                 0x80000

and the following for HP:

FuSynapticsMstFirmware:
BoardId:                0x351
  FuFirmwareImage:
  Data:                 0x80000

I'm not sure if the indenting makes sense. Is there no way to parse other info from the firmware file such as chip id or version?

Then I tried this: sudo fwupd get-devices -v
With all three MST hubs chained together (Intel -> HP -> CalDigit -> Delock), I only get info for the HP.
The other two are ignored because it thinks they are the same as the first:

05:45:35:0538 FuDeviceList         ignoring device 47a0754f6a2c9a7eb5f2883e4b78834a64451577 [synaptics_mst:(null)] existing device 7c2dd454e6f29453896a4824e8234317d237f8c5 [synaptics_mst:(null)] already exists
05:45:35:0540 FuPlugin             backend_device_added(synaptics_mst)
05:45:35:0541 FuDevice             using d7bfd19a68de57bb7de8a0cc8f7b97680677abc4 for PCI_SLOT_NAME=0000:00:02.0:drm_dp_aux6
05:45:46:0128 FuPluginSynapticsMST no cascade device found: failed to enable remote control: failure writing data register: failed to lseek to 0x4c0 on layer:0, rad:0x0
05:45:46:0128 FuPluginSynapticsMST no cascade device found: failed to enable remote control: failure writing data register: failed to lseek to 0x4c0 on layer:0, rad:0x1
05:45:46:0128 FuPluginSynapticsMST no cascade device found: failed to enable remote control: failure writing data register: failed to lseek to 0x4c0 on layer:0, rad:0x2
05:45:46:0132 FuPlugin             emit added from synaptics_mst: d7bfd19a68de57bb7de8a0cc8f7b97680677abc4
05:45:46:0133 FuPlugin             fu_plugin_device_registered(pci_bcr)
05:45:46:0133 FuPlugin             fu_plugin_device_registered(dell_dock)
05:45:46:0133 FuPlugin             fu_plugin_device_registered(thunderbolt)
05:45:46:0133 FuPlugin             fu_plugin_device_registered(msr)
05:45:46:0133 FuPlugin             fu_plugin_device_registered(uefi_capsule)
05:45:46:0133 FuDeviceList         ignoring device d7bfd19a68de57bb7de8a0cc8f7b97680677abc4 [synaptics_mst:(null)] existing device 7c2dd454e6f29453896a4824e8234317d237f8c5 [synaptics_mst:(null)] already exists

The HP has info like before in #1665
The board id of the HP in the result output is 849 (matches the 0x351 value from firmware-parse).

I disconnected the HP so now I just have Intel -> CalDigit -> Delock. Now I see the info the for CalDigit and not for the Delock (because it's ignored like before). The CalDigit has info like before. I see a new message cannot update as customerID is unset.

Then I disconnected the CalDigit and I just have the Delock connected. The Delock has info like before. I see a new message cannot update as customerID is unset but I would like to try to update. Is there a command line flag or quirk flag to override this? I understand that without a customer id, you can't do an automatic firmware update but a user should be able to do it by manually pointing to the device and firmware file. Nevermind. The following worked:
sudo fwupdtool install-blob FL_4L_MST_56_T6_5.04.132(1).fullrom
but I had to reconnect the device manually for it to reappear. The firmware was updated to 5.04.132 according to fwupdtool. Now I need to find out if it still works - In Windows, it causes AMD to hang and Intel to disable displays so maybe there's something wrong.

I also tried the fwupdmgr command. It usually takes a couple attempts to work (problem starting the daemon). This didn't happen before. fwupdmgr doesn't have the 25 second delay that fwupdtool does.

[superm1]

It looks like the instructions want me to enter meson . but that's an error since you cannot pass the source directory . to meson. I think this statement is referring to the later line meson build, so it would be better written as:

I made a modification to make it clearer, but it's a wiki please change it if you think it's still unclear as an outsider.

failed to setup backend blues: Error calling StartServiceByName for org.bluez: failed to activate service 'org.bluez': timed out (service_start_timeout=25000ms)

@hughsie this looks like a problem with the new bluez backend. Any thoughts on it?

I'm not sure if the indenting makes sense. Is there no way to parse other info from the firmware file such as chip id or version?

Yeah I think it's possible to add parsing for some of those other things and probably a good idea.

The other two are ignored because it thinks they are the same as the first:

I think that the fix we're putting into 1.5.8 (the release after the next release coming out) I'd anticipate this will be resolved by #2919

I also tried the fwupdmgr command. It usually takes a couple attempts to work (problem starting the daemon). This didn't happen before. fwupdmgr doesn't have the 25 second delay that fwupdtool does.

I think we have a bug with the bluez backend as mentioned above, hopefully should sort it before 1.5.7 release.

[hughsie]

this looks like a problem with the new bluez backend. Any thoughts on it

I've disabled it by default in #2928 -- it's a bit too risky to have for a bugfix release. I did try to reproduce by disabling the bluez service and by setting the service name to xxx.bluez but it failed gracefully. I assume the bluez service is trying to start but gets stuck at coldplug.

Yeah I think it's possible to add parsing for some of those other things and probably a good idea.

If you can get the offsets from Synaptics then sounds like a plan.

[superm1]

If you can get the offsets from Synaptics then sounds like a plan.

Here's the version offset: https://github.com/fwupd/fwupd/blob/master/plugins/dell-dock/dell-dock.quirk#L96 but it looks like the board ID offset isn't publicly documented.

[superm1]

Here's the version offset: https://github.com/fwupd/fwupd/blob/master/plugins/dell-dock/dell-dock.quirk#L96 but it looks like the board ID offset isn't publicly documented.

I checked and we'll need Synaptics to comment on how to find the offset for chip ID if we're going to do this. The offsets for version string are different between tesla, leaf and panamera so it can't be hardcoded in the parser unless the parser can determine the targeted chip ID.

[hughsie]

If we can get the chip ID from the firmware blob then I think it makes a lot of sense.

[superm1]

I would expect it can be obtained form the blob, but there isn't any documentation or code that indicates where the offset is for it.

[joevt]

I would expect it can be obtained form the blob, but there isn't any documentation or code that indicates where the offset is for it.

Maybe the chip ID is a hardware thing that cannot be changed with firmware? I couldn't find it in the firmwares I have (by searching for bytes that might represent 5333 in the HP firmware and 5330 in the Delock firmware). Well, one way to find out if the chip ID is in the firmware is to flash the 5333 firmware on the 5330 chip and seeing if the chip ID changes (I might do that if my Delock continues to not work - I'll first try to get the original firmware I had from Delock).

I did notice that the firmwares are both 512K, the first 128K is duplicated in the next 128K except the first and last byte of the last 16 bytes (the first of those bytes is 00 in the first 128K and 01 in the next), and the first 128 bytes is an EDID with Synaptics as the vendor (EDID from HP and Delock firmwares are identical). The version (3 bytes) is in the first 128K at two locations (0x6D5 and 0x18400), and therefore in the next 128K in the same two locations. The board ID (2 bytes) is in the first 128K at 0x10E and in the next 128K at the same location. The next/second/last 256K is identical between the HP and Delock firmwares.

I suppose a sample of two firmwares is not enough to say that the location of the board ID won't change.

UPDATE: I received from Delock a new version (5.04.135) of the firmware for my Delock 87737 MST Hub. I was able to apply it using fwpdtool. Now the Delock 87737 supports DSC like the MST hubs in the HP Thunderbolt Dock G2 and CalDigit SOHO. DSC allows connecting three 4K 60Hz 8bpc RGB displays to the hub.

[superm1]

Maybe the chip ID is a hardware thing that cannot be changed with firmware

True - that's entirely possible that it's read from some strapping during startup.

did notice that the firmwares are both 512K, the first 128K is duplicated in the next 128K except the first and last byte of the last 16 bytes (the first of those bytes is 00 in the first 128K and 01 in the next), and the first 128 bytes is an EDID with Synaptics as the vendor (EDID from HP and Delock firmwares are identical). The version (3 bytes) is in the first 128K at two locations (0x6D5 and 0x18400), and therefore in the next 128K in the same two locations. The board ID (2 bytes) is in the first 128K at 0x10E and in the next 128K at the same location. The next/second/last 256K is identical between the HP and Delock firmwares.

Yes, there are two banks on Panamera (5XXX) that you are seeing. When flashing firmware you'll swap between those first 128K and second 128K to flash and make active. The 3rd region is the ESM and is shared no matter which one you're booted into.