Start a Conversation

Unsolved

This post is more than 5 years old

A

7496

September 9th, 2018 05:00

Thunderbolt NVM update on XPS 9370 with Ubuntu 18.04 fails

Hello,

 

I have an update in my Ubuntu 18.04  software center.

The laptop is the Dell XPS 9370 with native Ubuntu OS.

The update is:"Thunderbolt NVM for XPS 9370 0.00 > 33.00" .

 

When I trigger the update it fails as the device ID is not found.

 

Any ideas?

September 17th, 2018 03:00

I have the same issue! It's really annoying!

September 19th, 2018 18:00

You can force the update...

https://github.com/dell/thunderbolt-nvm-linux


@auserdude wrote:

Hello,

 

I have an update in my Ubuntu 18.04  software center.

The laptop is the Dell XPS 9370 with native Ubuntu OS.

The update is:"Thunderbolt NVM for XPS 9370 0.00 > 33.00" .

 

When I trigger the update it fails as the device ID is not found.

 

Any ideas?


 

1 Message

September 22nd, 2018 14:00

same problem here, 

 

could you post a more detailed solution than the github page, it's not that straight forward

33 Posts

September 24th, 2018 13:00

Within a few minutes of installing 18.04.1 on a trial basis, I got a popup advising me that this update was available. I clicked on the install button and after a couple minutes it reported that it did not succeed due to a timeout.

There are a number of things that puzzle me about this.

  1. What is a Thunderbolt NVM?
  2. I also have windows installed and occasionally boot it to stay current with windows updates. This is the Windows factory install with all Dell S/W intact. The Dell S/W offered to update my BIOS. Why not this?
  3. After reboot there seems to be no more indication that this update remains to be installed. How can I check the Thunderbolt NVM version?

Thanks!

5 Posts

September 26th, 2018 07:00

The Thunderbolt NVM is the thunderbolt controller's Non Volatile Memory.

Even though it appears to fail when updating from Ubuntu, it does actually update the NVM.

After rebooting, what is effectively broken is Ubuntu's ability to detect  the successful installation of the NVM. Thus it will report "installed version 00".

If you enter "fwupdmgr get-devices" in a terminal, you will see that the Thunderbolt NVM has indeed been updated.

September 28th, 2018 08:00

This is an error with fwupd failing to read the firmware version.  It's fixed in newer versions of fwupd (In 1.1.x series 1.1.1 and later and 1.0.x series 1.0.9 and later)

This is the fix:

https://github.com/hughsie/fwupd/commit/25d51d14297713b4817ef9644f83e07e71344b0a#diff-edc76f94c53c98db018838b204de6704

There is this bug filed in Ubuntu 18.04 to update to the new fwupd that fixes the issue:

https://bugs.launchpad.net/ubuntu/+source/fwupd/+bug/1791999

 

Alternatively you can switch to the snap to get a newer version.

https://snapcraft.io/fwupd

 

1 Rookie

 • 

41 Posts

January 20th, 2019 21:00

You can forcibly update the NVM firmware on Linux with the information found here:

https://www.kernel.org/doc/html/latest/admin-guide/thunderbolt.html

But you have to be *absolutely* sure that the firmware update file you are applying is meant for your exact system.

There are no checks or safeguards and if you get it wrong, you will brick the controller. The only means of recovering the Thunderbolt functionality if it bricks will be to use a ROM programmer device on the Winbond flash chip next to the Thunderbolt controller on the motherboard of the laptop.

For those who live life on the edge, the Dell 9575 controller NVM36 firmware is compatible (I used it for a few months on the Dell 9370) but that one comes in a package full of miscellaneous NVM binaries so identifying the one that is meant for that laptop is difficult, and I would not recommend it without first confirming the hash with myself. And you'd need to accept it at your own risk.

The Dell 9380 NVM40 firmware is also compatible with the Dell 9370 (no brick) and enables native PCI enumeration by the operating system. However, because the BIOS has not been updated to fully support it, you need to do a Device Manager hardware rescan in Windows to hot add devices, and in Linux "echo 1 | sudo tee /sys/bus/pci/rescan".

But those are exceptions and I have bricked many devices by cross-flashing (luckily I know how to recover them using a ROM programmer. So probably stick to the official images.

January 21st, 2019 05:00

During the SW controller flash process the controller is supposed to verify that a given binary is for the intended machine.  EG you shouldn't be able to run a 9380 binary on a controller in a 9370 machine.

Flashing via a flash appliance is of course another story though.

 

The binaries do contain machine specific tuning, and I wouldn't recommend running a binary intended for a different machine.

No Events found!

Top