We load the Thunderbolt controller firmware to see if the controller is in
native mode, as this changes the GUID. If the controller is asleep the firmware
is not cached by the kernel and it can take more than 4 seconds to read out
504kB of firmware.
We only need the first two 64-byte chunks, so only read what is required.
This speeds up fwupd starting substantially, and also means we don't have to
allocate a giant chunk of heap memory just to inspect one byte.
Fixes: https://github.com/hughsie/fwupd/issues/848
Since the multi controller entry is part of the DROM and its place is
not fixed, it is possible (however unlikely) that the locations between
controller and the image are different. One scenario is that the new
image has typo in device or vendor name string fixed which could cause
the offset to be different.
To handle this case properly we need to read multi controller locations
of both controller and image separately, read their values and then
compare them against each other.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
During review it was pointed out that the return value of
read_drom_entry_location () should be documented because it also returns
TRUE when an entry was not found from the DROM. Caller needs to look for
the location->offset in that case. Add a comment explaining this.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Alpine Ridge and Alpine Ridge LP also include flash size field so follow
Titan Ridge and validate those as well.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
This reverts commit ed7acc7819.
As pointed out by @YehezkelShB during review the Titan Ridge IDs 0x15E8
and 0x15EB are for the NHI (the host controller). Windows SDK tool uses
them to keep track of different controllers but in Linux we don't need
them and can use the already existing bridge IDs.
There is no harm to have them listed but to avoid possible confusion in
future remove them.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Titan Ridge devices may contain multiple controllers so we need to make
sure the supplied NVM image multi controller number matches the
controller in question. This is pretty much same than we had for Alpine
Ridge (X of N) but the difference is that this multi controller
information is found in DROM instead and the location is not fixed.
For this reason we implement a generic DROM entry parser and use it to
dynamically fill in correct location of multi controller entry based on
the controller active firmware.
In addition to that we add a check for the NVM flash size just like we
do for Titan Ridge host.
Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Titan Ridge has same set of bits than Alpine Ridge telling whether the
Thunderbolt controller is in native or legacy mode. Add validation for
that.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
We need to make sure the Thunderbolt controller and the NVM image agree
with the expected flash memory size.
Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Add 0x15E8 and 0x15EB Titan Ridge IDs that were previously missed.
Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Thunderbolt devices typically have a discrete PD (power delivery)
controller and firmware for that controller is part of the NVM image. To
make sure the supplied NVM image provides the necessary PD firmware we
implement a check that compares existence of both PD pointers and fails
the validation if they differ.
Since the PD pointer is part of ARC_PARAMS section we need to populate
that section offset also for hosts (following DROM section).
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Kernel v4.15 added support for native enumeration of Thunderbolt
topology. The enumeration mode affects both the BIOS and TBT FW
operation so they must agree on it. Platforms may support both modes,
native and "legacy" (or "BIOS-assist").
This change makes sure the new image is compatible with the current
controller mode (otherwise the BIOS and TBT FW will not be alligned on
it at least until next boot) and also adds a new GUID generation logic
for a controller in "native" mode so LVFS could contain 2 images, one for
the "legacy" mode and one for "native".
Signed-off-by: Yehezkel Bernat <yehezkel.bernat@intel.com>
