Intel TXEI v3.1.50.2222 Drivers & Software
Intel CSTXE System Tools v3 r5
Intel TXEI Driver v1731.4.0.1199 (Windows 8 & Windows 10) INF for manual installation
Intel TXEI v1731.4.0.1199 Drivers & Software
Note: TXEI v4 drivers are usable with Gemini Lake systems.
Note: TXEI v4 driver versions start with the year & week of release (example: 1731 ā 31st week of 2017).
Hi!
First of all thank you for this amizing forum. I was able to upgrade nearly all of my devices to the latest firmware (TXE and ME).
Only one Tablet/Slim Notebook is resiting all of my efforts for a firmwareupgrade. Itās is using an old 1.0 version and Iām a little bit concernd that itās not safe.
Therefore I have some questions.
According to TXEInfoWin the āLocal Firmware Upgradeā is disabled. In the BIOS-Menu I canāt find anything regarding āTXEā. No āallow BIOS upgradeā or whatsoever. The only option which comes near is āSecure Bootā.
Is the ālocal firmware upgradeabilityā somehow related to secure boot? So only a ācredibleā OS can change the firmeware?
Is there a way to switch the āLocal Firmware Upgradeā option in the TXE to enabled?
In the first post of this thread there is mentioned a āUpgradeabilityā for TXE 1.x to as high as 1.2 using the FPT.
Is there a guide how to achieve this?
The device is quite old so there is no newer bios or any other support from the manufacturer. Only some quite old device drivers.
wkr
ADT
@ a-dead-trousers:
It has nothing to do with Secure Boot. Local Firmware Update (FWUpdate) can be sometimes disabled from the BIOS but that doesnāt mean that the OEM left the setting available for the users to adjust. Either way, you cannot use FWUpdate to update TXE 1.0 firmware to 1.1 or 1.2. A custom reflash of the entire TXE region (EXTR) was required for that generation. With FWUpdate you can just update to the latest 1.0 firmware only. In your case, that option is disabled as well. If your system happens to have read/write access to the TXE region of the SPI chip, you can upgrade via Flash Programming Tool. Run āfptw -d spi.binā command. Does it complete successfully or do you see CPU/BIOS Access Error or similar? If it completes successfully, you can follow the CleanUp Guide and at step 4 select the latest TXE 1.2 firmware. If it fails, you have no read/write access to the TXE region. Maybe we can enable some potentially hidden BIOS option though which will allow temporary read/write access there, provided that you can boot in an EFI shell. In that case, you can dump the BIOS region only by āfptw -bios -d bios.binā and then compress & attach it here.
Ok, thanks. I will try your suggestions next weekend when Iāve got some spare time (holidays and so on 
)
@plutomaniac
Now I found some time. As you predicted the SPI chip is not accessible using Flash Programming Tool. The command "fptw -d spi.bin" results in "Error 26: The host CPU does not have read access to the target flash area. To enable read access for this operation you must modify the descriptor settings to give host access to this region.". Therefore I tried to dump the bios with "fptw -bios -d bios.bin" and was able to do so even without an EFI shell. I hope thatsĀ“s ok and nothing of value is missing.
BIOS.zip (1.57 MB)
The EFI shell is required for the next step (setup_var manipulation), if a hidden BIOS option exists and actually works. I found a few interesting BIOS options which I assume are hidden from the menus.
TXE (Default = Enabled) ā 0x16C
TXE HMRFPO (HMRFPO = Host ME Region Flash Protection Override, Default = Disabled) ā 0x170
TXE Firmware Update (use of FWUpdate, Default = Disabled) ā 0x171
TXE EOP Message (for testing, EOP = End of Post, Default = Enabled) ā 0x16D
We are interested in āTXE HMRFOā to allow Read/Write access to the TXE region and thus upgrade to 1.2 firmware. We are also interested in āTXE Firmware Updateā which will allow FWUpdate usage, if required.
Follow these steps but at step 3, change the variable to the one you want. For example āsetup_var 0x170 0x01ā to enable HMRFPO. You should then be able to dump the SPI chip.
No success.
Right after the reboot both values (0x170 and 0x171) are back to being 0x00 instead of 0x01.
This is was GRUB said:
Looking vor Setup variableā¦
var name: Setup, var size 12, var guid: a04a27f4-df00-4d42 - b5-52-39-51-13-02-11-3d
ā GUID matches expected GUID
successfully obtained āSetupā variable from VSS (got 700 (0x2bc) bytes).
offset 0x170 is: 0x00
setting offset 0x170 to 0x01
I tried the command multiple times to confirm that it is set to 0x01 but after a reboot itās back at 0x00.
Try the attached tool with command ā/UnlockTXEā. If that works, it also has command āEnableTXEFWUā.
BootMode v2.2.rar (86.7 KB)
Although quite scary (the pc suddenly shutting down) it worked and I was able to dump the SPI chip.
Then I followed your cleanup guide and Iāve got the outimage.bin but what to do with it? Your guide is missing the āhow to actually flash the new biosā part.
I tried with Flash Programming Tool but this gives me "Error 286: Unable to write data to flash with SPI lock enabled."
To check this I tried to flash an older bios from the vendor (using InsydeFlash) but this also fails during boot. So I think I have to enable one more small thing using BootMode or another tool.
So the tool works for your machine, good, youāre lucky. You can flash via Flash Programming Tool. Command āfptw -f outimage.binā followed by āfptw -gresetā is enough in your case. As for SPI lock, it is possible that āUnlockTXEā deals only with the TXE region of the SPI chip so, with only that option enabled, one would have to prepare an Engine (TXE) region only image at the CleanUp Guide. Since I see there are some other options at BootMode such as āEnableBIOSLockā and āInFactoryModeā, try the former one, it will probably work afterwards.
A quick update:
I succeeded to disable the BIOS lock and to flash the new image. But now the laptop wonāt boot anymore, so I asume I did something TERRIBLY wrong. Currently Iām searching for a way to flash the original BIOS without an actually working BIOS. The chip is soldered to the motherboard and the device is quite old so I donāt want to go through the hassle of disasamble everything just to find out I made it worse during the process.
I found a guide where itās mentioned that you can use a FAT formatted USB drive containing the BIOS and a special button combination to flash the bios in a kind of emergency mode. Unfortunately the guide only mentions HP, Acer and Asus devices but not Lenovo. You donāt happen to know something about Lenovo, do you?
From the test I made with that tool on Lenovo T410 laptop with all commands I try:
/InFactoryMode - Set machine in factory mode
/DisableBIOSLock - Disable BIOS Lock
/UnlockTXE - Set the Flash Descriptor Override strap
/EnableTXEFWU - Enable TXE FW local update
All comands are reported as SUCCESSFUL but it canāt disable ME lock region for me to be able to program DESC unlocked or dump ME region.
Maybe you program BIOS with the full flash dump ME+GBE+BIOSā¦ or with TXE firmware ?
@ a-dead-trousers:
Can you upload your original and modded dumps to see what possibly went wrong?
From some older Lenovo system with TXE firmware. It worked for a-dead-trousers (similar?) system but it doesnāt mean anything for other models. Donāt get your hopes up, this is for specific cases.
@plutomaniac
Do you have something / know if it is possible to unlock flash descriptor for old Lenovo T410 without external intervention to chips ?
thx
@plutomaniac
Here are my two files. Had to find a way to backup the harddrive first. Through USB to SATA bridge I wasnāt able to read the GPT format.
outimage.zip (2.22 MB)
spi.zip (2.18 MB)
The cleaned/updated SPI image (outimage.bin) is proper, you did everything correctly. So either something went wrong during flashing or thereās some security measure in place. Since Intel BootGuard was not a thing at Bay Trail systems, I donāt think it could be something else. Did the flashing complete properly?
Have you tried removing all power from the machine (AC + Battery) for a few minutes (press the power button a few times while the system is off)? If that does not help, try removing and re-inserting the memory modules (make sure you put them back correctly) in case the problem is bad BIOS cache.
Flashing did not show any problems at all and everything you mentioned to solve the problem I already did. Except removing the memory modules because they are also soldered to the motherboard. Even the CMOS battery is soldered but at least not so well, so I was able to remove it. The system was without any source of power for nearly half an hour and that didnāt help either. So Iām also convinced, that there must be some sort of (hardware?) security measure. Anyway, thanks for the assurance that I didnāt do something wrong (except of trying to change the firmware in the first place). At least I can stop doubting myself and enjoy the christmas holidays.
Merry christmas and relaxing holidays to you.