firmware-lenovo
firmware-lenovo copied to clipboard
fwupd
Thunderbolt controller firmware update - X1 Carbon gen6
Hi,
I'm one of the many owners with this laptop and I've lost HDMI output. I'm not sure when it exactly happened, but I think it was when I updated the Intel ME firmware a month or three ago. Basically, nothing happens when an external monitor is connected. I've read a lot about this particular issue on (Lenovo) forums and it seems the following firmware update can fix this issue:
https://pcsupport.lenovo.com/nl/en/products/LAPTOPS-AND-NETBOOKS/THINKPAD-X-SERIES-LAPTOPS/THINKPAD-X1-CARBON-6TH-GEN-TYPE-20KH-20KG/20KH/downloads/DS502615
The laptop has the latest BIOS update (1.57) and the latest Intel ME firmware installed as well. The thing is, my laptop is running Arch Linux solely. Could this update be made available for Linux users (fwupdmgr) as well?
@hughsie My question is: is the thunderbolt controller firmware update (as linked above) available on the LVFS platform?
Hmmm - looks like we last updated the TBT controller on the X1 Carbon 6 two years ago.. with version 43. I'll check with the FW team when (hopefully not if) the next update is - it looks like they're now up to version 47.
All that being said - I don't see why a TBT controller update would have any impact on HDMI display - unless you're connected via a TBT dock maybe? Any reason you think this particular FW update will help? I'm happy to chase an update (it should be done) but I don't think it's going to fix the root cause of your issue.
I've created internal ticket LO-1984 for tracking
@mrhpearson please see the following posts:
https://forums.lenovo.com/t5/ThinkPad-X-Series-Laptops/X1-Carbon-6th-gen-HDMI-Thunderbolt-stopped-working/m-p/5120432
https://forums.lenovo.com/t5/thinkpad-x-series-laptops/x1-carbon-6th-gen-hdmi-not-working/td-p/4091511
https://forums.lenovo.com/t5/ThinkPad-X-Series-Laptops/X1-Carbon-6th-Gen-HDMI-Not-Working-and-Thunderbolt-Missing/m-p/4326149
I have the same issue with thunderbolt not working and hdmi also having issues. I'm even unable to see thunderbolt in lspci. Windows can't see it in the device manager too and I'm unable to flash it from windows.
@LordChaos73 Are you even able to see the thunderbolt controller in lspci?
Do you know which version of FW you had on there previously? There was a critical update a while back (2019) that was published and I'm pretty sure we put those updates on LVFS. https://support.lenovo.com/ca/en/solutions/ht508988-critical-intel-thunderbolt-software-and-firmware-updates-thinkpad
My understanding was that if the FW wasn't updated it was possible to brick your TBT controller. If you already had that update then we can ignore that as a theory. If it's not working in Windows it is worth calling customer support for assistance - you may have a HW issue.
I remember about the critical update back in 2019 and I've always had the latest possible firmware installed since. Since so many X1C6 owners seem to have this issue, I'm wondering if the patch was successful in the first place. Anyway, since this was my production machine until very recently, I know everything was working fine until we had the Intel ME issues that failed to install. I think I lost HDMI output around that time. And if I remember correctly, there was also a new BIOS release at the time. I'm also not seeing my Thunderbolt controller using lspci (I've attached the output of 'sudo lspci -v'). lscpi.txt
@mrhpearson I'm not sure as I'm unable to connect to the controller in any way that I know of.
But here is a dump of the fw from the W25Q80DVSNIG x1c6_tb3.zip
Hi - can you confirm the BIOS, EC and ME FW versions please (easiest is to grab them from the BIOS setup screen - F1 during early boot). The note from the FW team says:
I checked history, there was an issue that system will lost TBT controller and fixed by one EC firmware on X1 Carbon G8 project, never hear this issue on X1 Carbon G6 project. So that is why I suggest to have a try with upgrade BIOS/EC to newest, feel sorry that cannot give specifics of which version of EC.
Not sure why they can't tell me which version of FW...(I'm pretty annoyed about it, but it gets worse)
It looks like they released a new BIOS/EC combo update on the Lenovo support site - but the EC has not been released on LVFS (the BIOS has). I'm really grumpy about that (the BIOS is updated)
Can you try the cab file that is on the Lenovo site (https://download.lenovo.com/pccbbs/mobiles/n2wul23w.zip). I did the update on mine ('fwupdmgr install N2WHT20W.cab' - I had to set 'OnlyTrusted=false' in /etc/fwupd/daemon.conf) and it looks good - but I also wasn't having TBT issues.
I don't know if the new EC will fix the issue - there is nothing in the internal release notes that references it - but it sounds like it should be tried. I'm pushing them to get the EC on LVFS ASAP.
Mark
I´m not sure the cab files you provided are the correct ones?
[levid@x1carbon6 n2wul23w]$ fwupdmgr install N2WHT20W.cab Decompressing… [ - ] No supported devices found
[levid@x1carbon6 n2wul23w]$ fwupdmgr install N2WET37W.cab Decompressing… [ \ ] No supported devices found
By the way, I downloaded the ISO of the latest BIOS and wanted to see if I could re-apply it. So I created a bootable USB stick with the latest BIOS, but I can't seem to re-apply it; the setup program states there is nothing to do. Is there any way to re-apply the BIOS update? I was hoping the ISO is carrying the EC update as well.
Sorry - those are X1Carbon 8 items...my bad. I'll look for the X1 Carbon 6 ones.
I checked and the X1 Carbon 6 versions I can find are the same you already have - so I went back to the FW team and asked for any other suggestions. Not heard back yet.
EC 1.22 is here (and under stable) https://fwupd.org/lvfs/firmware/5728
Checking the released notes on the support site it's the latest version: https://download.lenovo.com/pccbbs/mobiles/n23ul35w.txt: 1.57 (N23UL35W) 1.57 (N23ET82W) 1.22 (N23HT37W) 01 2022/08/25
Is there any hope on restoring Thunderbolt/HDMI functionality? A BIOS update maybe?
I see there's a new version of the Intel ME available - 11.8.93.4323. It's not on LVFS yet?
Howdy all -- having the exact same issue w/ the exact same bios. Any suggestions here?
I see there's a new version of the Intel ME available - 11.8.93.4323. It's not on LVFS yet?
hi @LordChaos73 still under testing... hopefully will be available by end of this month... please open separate issue for proper tracking. thank you very much
@cdrn Same issue here. I'm trying the full hardware route by buying W25Q80DVSNIG chips to replace the one on my motherboard that has gone bad, and programming them through a CH341-based programmer. Before the fix, the laptop was not shutting down properly by Windows, could only pull 15W from the charger instead of 65W, and had no HDMI output. The binary file provided by @dal00 fixed the charging issue, but nothing else. I'm not sure if that's a compatibility issue between BIOS, EC, and TB versions or there are other problems. I have BIOS 1.57 and EC 1.22, which I think is the latest. I just need to find a working binary for the TB controller.
I also have this issue (HDMI and DP not working). When I first noticed it I updated all firwmares through fwupd so I have everything on the latest version now. I have no idea if the critical fix from 2019 was applied on this computer as it is second-hand so I'm not very hopeful in my case. Does anyone know if it was rolled out automatically through Windows Update?
I'm in the process of getting an EEPROM programmer myself, because the controller does not even appear in lspci output or in Windows Device Manager.
Do you still have the original data that was on your chip before you flashed it by any chance @RAY5D ? I'd be interested in comparing it to what I have. It's interesting that after changing the chip for a new one you still seem to face some issues.
@tw0flower Sorry, I don't have any data backed up. When I used the programmer on the old chip, it read all 0xff, which I think is the "default" value for this type of storage. It will still read 0xff even after writing whatever data, so the chip is most likely dead as dust since the programmer could still read its model number, indicating a correct connection. I'm pretty sure the only thing I need now is the binary file, but that is, unexpectedly, hard to find. Can you post your data here so I can try? Thanks!
@RAY5D Ah, I misunderstood your comment. I thought you had already replaced the chip, and that some other component was writing 0xFF data all over the new chip after you flashed it.
I will post my data, but I don't think flashing it will be useful as my computer also has the HDMI/DP problem. Have you checked these binary files on the LVFS website? https://fwupd.org/lvfs/devices/com.lenovo.ThinkPadN23TF.firmware
During my desperate search for answers on this issue, I also found this blog post from a user that had a somewhat similar problem years ago on a Thinkpad P1. He apparently had to flash zeroes over the chip before being able to flash the actual firmware.
It goes without saying, I don't know much about hardware so anyone reading this please take it with a grain of salt. At this point I'm desperate and accepting the risk of bricking things.
@tw0flower I did replace the chip and flash the firmware. I also saw that post earlier, but apparently I didn't notice the part about writing 0's first and then flashing the actual firmware (oops). I'll do more testing with the binary files I found and post updates here. However one thing that confused me was that the official binary files from both Lenovo and https://fwupd.org/lvfs/devices/com.lenovo.ThinkPadN23TF.firmware are exactly 260KB while the chip is 1MB, and the dumped binary in this issue has some content after that region, so I'm not sure about what should I write after the 260KB.
@RAY5D That's what I hope I will find out if I can still extract some data from my chip. There might be some padding involved. I wonder if this information might not be available somewhere in the LVFS files? Because the flashing software must be aware of it right?
But in theory if you zero-out the chip first, then flash the firmware, this would ensure that only the firmware on the chip I think. If there is some padding involved you could also try writing it at the end of the memory by concatenating some zeroes followed by the 260kb file so that the total is 1MB. If the padding is some arbitrary value however we have to find another way.
@tw0flower OK I did some more testing. I had 2 binary files, the first one was the 260KB official release, with the extra space filled with 0's, the second one is the dumped data from this issue posted by dal00. For each test case, I filled the chip with a certain value (0x00 or 0xff), started the PC, shutdown, flashed the binary, and start again to see if it works. Here are the results:
- 0x00 fill, 260KB+0's: No HDMI, charging works, Windows couldn't shutdown properly.
- 0xff fill, 260KB+0's: No HDMI, charging works, Windows couldn't shutdown properly.
- 0x00 fill, dumped: No HDMI, charging works, Windows couldn't shutdown, sometimes freezes and goes into BSOD.
- 0xff fill, dumped: Windows did not complete boot, black screen at login, tried Manjaro, no HDMI.
The results looked overall similar to my previous attempts. Only the charging speed was fixed. However, before the tests today, I noticed that the replacement chip was dead again (wtf!?!?). I think I tried enabling assist mode in BIOS earlier, maybe that caused the early death? Anyways, I just replaced the chip again before the tests since I bought 10, and was careful to only enable assist mode while using Linux, and the chip still works for now. I don't think there is a lot left to do before we can find more binaries to compare and test with. Should I try the official binary but extended with 0xff next time?
I got my CH341 SPI today and I found a few things.
First of all @RAY5D if you only see 0xFF bytes on your chip it might be that your clamp is not properly attached. I had this issue at first, I solved it by re-attaching it until I read some data and by using flashrom instead of ch341eeprom. If the RUN led on your SPI board is not on when reading/writing it means something is wrong in your setup.
The first thing I did was to extract the firmware I had installed on my machine. Compared to the firmwares I found online, it had an offset: the first 4096 bytes were all 0xFF. What remained was similar to the firmares I found online.
My initial situation is that everything worked except plugging a second display (HDMI or via Thunderbolt). I then tried the following:
- I flashed the newest 47 firmware from the LVFS website. No changes.
- I flashed the 47 firmware with a 4096 bytes offset. Charging was not using the full power from the adapter.
- I flashed the 43 firmware from the LVFS website. Charging was working normally again but no luck with the screen.
- I went in the BIOS and reset the options to default with Windows 10 optimised settings. But unfortunately that didn't help.
So in my case:
- My problem is not caused by a hardware defect from the chip that stores the Thunderbolt firmware. I can read and write on it perfectly. I even made sure that reading after writing a file produced the exact same result.
- Changing the firmware does have an effect. I lost charging. But it had no effect on the external display.
- There was an offset on my firmware. I wasn't compatible with the 47 version. I have not tried it on the 43 version, but it made charging work again without it.
The files that I flashed on the chip are in the attached zip file. firmwares_x1cgen6.zip