Lenovo Thinkpad X201 reports

[ghost]

System

Lenovo Thinkpad X201 with MX25L6445E chip; has an SSD with GRUB2 and minimal Debian Jessie (both installed via a Debian Jessie AMD64 netinstall DVD).

Results

• Stock BIOS: boots fine.
• Stock BIOS, neutralised: doesn't boot boots fine after a delay of <1 minute.
• Coreboot with SeaBIOS payload, based on descriptor & ME regions from stock BIOS: boots fine.
• Coreboot with SeaBIOS payload, based on descriptor & ME regions from neutralised BIOS: doesn't boot.

[ghost]

I'll investigate further and update this issue accordingly.

[ghost]

Stock BIOS

Boots fine. Goes to GRUB2 menu.

$ sudo intelmetool -s
Bad news, you have a `Mobile 5 Series Chipset LPC Interface Controller` so you have ME hardware on board and you can't control or disable it, continuing...

MEI not hidden on PCI, checking if visible
MEI found: [8086:3b64] 5 Series/3400 Series Chipset HECI Controller

ME Status   : 0x245
ME Status 2 : 0x60000000

ME: FW Partition Table      : OK
ME: Bringup Loader Failure  : NO
ME: Firmware Init Complete  : YES
ME: Manufacturing Mode      : NO
ME: Boot Options Present    : NO
ME: Update In Progress      : NO
ME: Current Working State   : Normal
ME: Current Operation State : M0 with UMA
ME: Current Operation Mode  : Normal
ME: Error Code              : No Error
ME: Progress Phase          : Host Communication
ME: Power Management Event  : Clean Moff->Mx wake
ME: Progress Phase State    : Host communication established

ME: Extend SHA-256: d0d3eacdf232e0887f64691c56feb9351f81dbf99033a16922d9407e1049d1e1

ME: timeout waiting for data: expected 8, available 0
ME: GET FW VERSION message failed
ME: timeout waiting for data: expected 5, available 0
ME: GET FWCAPS message failed

Stock BIOS, neutralised

Boots, after a delay that initially made me think the laptop was bricked (I did not time it, but would guess it was somewhere between 15-60 seconds). Goes to GRUB2 menu.

$ sudo intelmetool -s
Bad news, you have a `Mobile 5 Series Chipset LPC Interface Controller` so you have ME hardware on board and you can't control or disable it, continuing...

MEI not hidden on PCI, checking if visible
MEI found: [8086:3b64] 5 Series/3400 Series Chipset HECI Controller

ME Status   : 0x3042
ME Status 2 : 0x16320000

ME: FW Partition Table      : OK
ME: Bringup Loader Failure  : NO
ME: Firmware Init Complete  : NO
ME: Manufacturing Mode      : NO
ME: Boot Options Present    : NO
ME: Update In Progress      : NO
ME: Current Working State   : Recovery
ME: Current Operation State : M0 with UMA
ME: Current Operation Mode  : Normal
ME: Error Code              : Image Failure
ME: Progress Phase          : BUP Phase
ME: Power Management Event  : Pseudo-global reset
ME: Progress Phase State    : M0 kernel load

ME: Extend SHA-256: 0cd7b8a91f2e366259fe012cfdadf5f8e7f0f9dd37e1d28b6840c91a26881a1f

ME: has a broken implementation on your board with this BIOS
ME: failed to become ready
ME: failed to become ready
ME: GET FW VERSION message failed
ME: failed to become ready
ME: failed to become ready
ME: GET FWCAPS message failed

Coreboot with SeaBIOS

Boots fine, though with no menus (skips SeaBIOS menu and skips GRUB2 menu).

$ sudo intelmetool -s
( Really fast-scrolling lines. At first, something like this: )
[   84.735846] mei_me 0000:00:16.0: no destination client found 0x80140007
( And then: )
** 536 printk messages dropped ** [  274.637567] mei_me 0000:00:16.0: no destination client found 0x80140007
( Ctrl+C did not work to stop this. Had to restart. Size of x201_coreboot_intelmetool.log was 0 bytes afterwards. )
$ sudo intelmetool -s > x201_coreboot_intelmetool.log
( Same thing. )
$ sudo intelmetool -s 2&>1 >> x201_coreboot_intelmetool.log
$ cat x201_coreboot_intelmetool.log
Bad news, you have a `Mobile 5 Series Chipset LPC Interface Controller` so you have ME hardware on board and you can't control or disable it, continuing...

MEI not hidden on PCI, checking if visible
MEI found: [8086:3b64] 5 Series/3400 Series Chipset HECI Controller

ME Status   : 0x255
ME Status 2 : 0x61000000

ME: FW Partition Table      : OK
ME: Bringup Loader Failure  : NO
ME: Firmware Init Complete  : YES
ME: Manufacturing Mode      : YES
ME: Boot Options Present    : NO
ME: Update In Progress      : NO
ME: Current Working State   : Normal
ME: Current Operation State : M0 with UMA
ME: Current Operation Mode  : Normal
ME: Error Code              : No Error
ME: Progress Phase          : Host Communication
ME: Power Management Event  : Moff->Mx wake after an error
ME: Progress Phase State    : Host communication established

ME: Extend SHA-256: d0d3eacdf232e0887f64691c56feb9351f81dbf99033a16922d9407e1049d1e1

ME: response is missing data
ME: invalid response, group 255 ?= 132, command 2 ?= 0, is_response 0
ME: not enough room in response buffer: 8 != 6
ME: Firmware Version 0.996.511.0 (code) 0.0.0.0 (recovery) 0.0.0.0 (fitc)

ME Capability: Full Network manageability                 : ON
ME Capability: Regular Network manageability              : OFF
ME Capability: Manageability                              : ON
ME Capability: Small business technology                  : OFF
ME Capability: Level III manageability                    : OFF
ME Capability: IntelR Anti-Theft (AT)                     : ON
ME Capability: IntelR Capability Licensing Service (CLS)  : ON
ME Capability: IntelR Power Sharing Technology (MPC)      : ON
ME Capability: ICC Over Clocking                          : ON
ME Capability: Protected Audio Video Path (PAVP)          : ON
ME Capability: IPV6                                       : ON
ME Capability: KVM Remote Control (KVM)                   : ON
ME Capability: Outbreak Containment Heuristic (OCH)       : OFF
ME Capability: Virtual LAN (VLAN)                         : OFF
ME Capability: TLS                                        : ON
ME Capability: Wireless LAN (WLAN)                        : OFF

Coreboot with SeaBIOS, neutralised

Doesn't boot.

[corna]

Currently coreboot doesn't work with me_cleaner unfortunately, probably due to this.
The fix should be easy (just add a timeout) but unfortunately I don't have a Nehalem PC, so I can't do it.

If you want you can try to add the timeout in the Nehalem raminit (src/northbridge/intel/nehalem/raminit.c) and see if that fixes it.

[ghost]

@corna wrote:

Currently coreboot doesn't work with me_cleaner unfortunately, probably due to this.
The fix should be easy (just add a timeout) but unfortunately I don't have a Nehalem PC, so I can't do it.

If you want you can try to add the timeout in the Nehalem raminit (src/northbridge/intel/nehalem/raminit.c) and see if that fixes it.

Thanks for the explanation!

I am a total noob at C programming, so I am not sure how to add a suitable timeout. I would welcome your suggestions or patches on that front, and would potentially be willing to test them on my X201. I have also asked for help on the Coreboot mailing list.

Also, I understand that the i5-520M in this X201 is of Westmere architecture, not Nehalem. Not sure if that makes a different w.r.t. the raminit.

[mfp20]

@sampablokuper

Coreboot with SeaBIOS
Boots fine, though with no menus (skips SeaBIOS menu and skips GRUB2 menu).

You probably didn't add the VGA rom to your coreboot build. Must use bios_extract or UEFITool to get the vga rom out of the original bios, then add it to coreboot. Have a look here.

Coreboot with SeaBIOS, neutralised
Doesn't boot.

Did you fix it?

Also, I understand that the i5-520M in this X201 is of Westmere architecture, not Nehalem. Not sure if that makes a different w.r.t. the raminit.

It is the "flop" of the same arch: same logic, smaller production process. That can actually be the reason why we (your X201 and my T410) need a timeout in raminit. Reducing distances change the timings all around...

@corna

Fixed?

I can't easily flash and test because T410 chip is covered by an hard surface; I had to dismantle the whole laptop. And then desolder the chip because my programmer couldn't turn on the chip without desoldering; probably some copper tracks are too long or go figure what else. Anyway, the chip is clipped on the table and I MUST flash coreboot in it before resoldering onto the mobo, in order to disable the flash lock ...

[mfp20]

@corna

I added a timeout to the two functions with the "FIXME: add timeout" comment. Patch nehalem_raminit_timeout_for_neutralized_me.diff.txt

Notes:

• I don't know how much timeout 0x7ff is (micros? millis? secs? no mask?). I just copied from the EC initialization code.
• There is a "return 1" commented out after the timeout check. I don't know if the read32/write32 calls after the while loop must occur anyway. If not, just remove the comment in front of "return 1".
• coreboot builds fine but I can't run me_clean because I must flash the chip, solder it back, then rebuild the laptop. I prefer to keep the ME and run coreboot in order to be able to in-system program without dismantle the laptop again.

@sampablokuper
It looks like the bios chip is easily accessible on your X201. Please apply my patch, build a "coreboot+neutralized" config, test it and report. Thanks.

[ghost]

@mfp20

Thanks for all this. It might be a while before I find more time to experiment with the X201, sorry.

I think you are right about graphics being an issue. See the thread Lenovo Thinkpad X201: cannot boot encrypted Debian w/Coreboot & GRUB2. I hope to report back, here or on the mailing list, or both, when I have had a chance to test further.

As for the timeout patch, thanks for drafting that. GNUtoo also made a similar patch recently. To reduce duplication of effort among Coreboot volunteers, you may wish to read and participate in the thread [coreboot] [PATCH] nb/intel/nehalem/raminit.c: Add timeouts when waiting for heci, on the Coreboot mailing list.

Thanks again.

[mfp20]

@sampablokuper

Np. I gave up the T410 about 2 years ago by entering the coreboot's IRC channel and finding there a swedish guy bothering for me to study a book on BIOSes instead of helping me to add the T410 to the coreboot buildchain (aka Gunny vs Sweedy).

This guy from the thread you pointed me: good developer, bloody annoying when socializing (note: I got drunk with him at an hacker camp in 2009; I'm not talking for chat misunderstandings only).
He could not imagine I got sued 3 times for nothing, almost jailed, hammered for 6 years by militaries to silently shelve my case, running around 4 continents to not get killed, and I was fucking desperately trying to access a clean machine after my TAILS usb memories disappeared two times. I am lucky to be alive.
Religious approach to heroism makes believers keep their asses comfy while heroes get killed on the road. Breivik in Norway made a better job: at least Ed Snowden don't have to meet idiots from Norway too.

I took that laptop back in my hands just because you were struggling; I don't need it. But if you don't need it too, I go back to my stuff. I don't really care to fight against windmills, tech giants and other carnivores.
I got my coreboot's tickets account enabled yesterday, I attach my patch there and then a small step forward has been done anyway. BTW, from the email you pointed out looks like the write32 in the second function can be skipped on timeout as far as 0x7ff is enough time for the inside-defect to init, and RATs to eat your brain...

Last but not the least: the boot behaviour you (and the guy in the email you linked) have described, is exactly the one you get when you don't have the VGA option rom in the flash. In such case both grub fail to enable the display, and you must wait for the linux kernel to do it. Windows too would fail. Seabios works fine if you enabled native init at conf time; for text only display.
If you extract the video bios and embed it in coreboot, everything works fine instead. I can't get mine (T410) yet; bios_extract doesn't work and UEFITool isn't usefull because it is a legacy BIOS system.

Please, report when you'll find the time to work on this issue.

cheers

Edit: holy crap. Denis "GNUtoo" is another engineer! He looks at the datasheet before doing something!

The DEFECT we are trying to fix, is BY DESIGN. No books say that as far as the books authors are the designers, and the copyright is enforced.

[ghost]

@mfp20

I got my coreboot's tickets account enabled yesterday, I attach my patch there and then a small step forward has been done anyway.

Thanks for this, and sorry not to be able to do anything on the X201 right now. As I say, I hope to come back to it when time allows.

Also, please can we keep this thread to technical matters relating to booting the X201 (and other Nehalem/Westmere-based Thinkpads, insofar as they provide insight into the X201) with a neutralized Management Engine? Thanks.

[Chriss-Kyyti]

Thinkpad X201: Stock BIOS, neutralised: doesn't boot boots fine after a delay of <1 minute.

Can you please confirm, is the fan control working? If Intel ME is completly disabled through it's own setup utility the X201 laptop fan will not work and the laptop will overheat

[ghost]

@kyytl wrote:

Can you please confirm, is the fan control working?

I don't currently have access to that X201. Will try to remember to check next time I do have access to it.

If Intel ME is completly disabled through it's own setup utility the X201 laptop fan will not work and the laptop will overheat

Interesting. Would you mind explaining how you reached that conclusion? Thanks!

[Chriss-Kyyti]

It's well documented behaviour. Use Google or: https://forums.lenovo.com/t5/ThinkPad-X-Series-Laptops/X201-severely-crippled-after-disabling-Intel-AMT-AT-in-BIOS/td-p/811249

My own tests:
Thinkpad X201s i7-620 LM
Thinkpad X201s i7-640 LM
Thinkpad X201 Core i5 540M
Thinkpad X201 Core i5 560M
Thinkpad X201 i7 *** et al.

[Chriss-Kyyti]

Also please check: #27

"At some future date, will me_cleaner be able to remove just the potentially malicious parts of the Intel Management Engine?

I’m curious because currently me_cleaner removes the entire Intel Management Engine, which includes useful and (in my opinion) necessary things like fan control and thermal management. I would like to be able to remove the malicious part of Intel Management Engine without having to give up useful stuff (mentioned above), and also without the high risk of bricking my next laptop (currently using Late 2011 13” MacBook Pro). ..."

[Chriss-Kyyti]

And please notice that if you just disable Intel ME in the stock BIOS setup you produce that +-1 minute delay to the boot. Basically the computer will then quite soon be FUBAR because you have just disabled the thermal control and fan operations.

[ghost]

@kyyti wrote:

https://forums.lenovo.com/t5/ThinkPad-X-Series-Laptops/X201-severely-crippled-after-disabling-Intel-AMT-AT-in-BIOS/td-p/811249

Thanks for this. Wow. Turning off AMT using the stock BIOS interface potentially damages the laptop?! That's pretty shoddy on Lenovo's part. Looks like that was c. 2012-2014. And none of the BIOS updates up to 2014 (which seems to be the most recent one) fixed this. At least, it's not mentioned in the README.

Do you know if Lenovo has addressed or acknowledged this at all? I haven't found any evidence of their having done so.

My own tests:
Thinkpad X201s i7-620 LM
Thinkpad X201s i7-640 LM
Thinkpad X201 Core i5 540M
Thinkpad X201 Core i5 560M
Thinkpad X201 i7 *** et al.

Which tests did you perform on these machines, and what were the results?

[Chriss-Kyyti]

Not AMT, Intel ME. AMT is just part of it. ME includes some of the core functions of the laptop. Please read the documentation. There is nothing to fix with BIOS updates as thermal management and fan controls are just some of the intended functions of Intel ME. It's like removing the motor of an automobile and crying to Toyota that the car does not work. And nevertheless, Thinkpad X201 is already so called legacy system. This whole me_cleaner fix wouldn't interest us if X201 series were on the Lenovo upgrade list for the Intel AMT vulnerability but it is not as it is already a legacy (non updated) system.

"... currently me_cleaner removes the entire Intel Management Engine, which includes useful and (in my opinion) # necessary things like fan control and thermal management. I would like to be able to remove the malicious part of Intel Management Engine without having to give up useful stuff "

[ilikenwf]

@sampablokuper @kyyti I have a T410 (same platform, different formfactor) that I'm experimenting with, and have found that instead of using me_cleaner to strip anything, that ONLY toggling the soft disable bit will disable the ME but allow the machine to boot.

Stripping still prevents boot (hangs), but just soft disable works, with the exception of needing to blacklist intel_ips on some (all?) distros to prevent logspam.

I suspect this issue to be similar to one @kakaroto encountered working on the Purism laptops, in that one or more partitions is likely required to remain to boot the machine. I forget which one, but it is used to store configuration data for the network controller(s).

[mparnelldmp]

I have a work and a non-work github account here, so the above and I are one and the same...

I suspect more research is required regarding the necessity of some of the modules with the various Thinkpads out there, and some other models as well.

[corna]

@ilikenwf OEM firmware or coreboot?

[mparnelldmp]

Coreboot :)

Now if only the master branch wasn't broken on the x201/T410.

Intelmetool's output shows the warning about being "nonremovable," but then can't find the ME device.

[mparnelldmp]

The only other caveat is the need to blacklist intel_ips because it spams messages about not finding the ME or it being stalled.

[kakaroto]

@corna

I suspect this issue to be similar to one @kakaroto encountered working on the Purism laptops, in that one or more partitions is likely required to remain to boot the machine. I forget which one, but it is used to store configuration data for the network controller(s).

It was the "MFS" partition. You can whitelist it if you use the dev branch, and see if it makes a difference.
However, it wasn't required to boot the machine. The machine would still boot, it would just not initialize some clocks and in my case, it means the PCIe wifi module wouldn't work. Note that this was on ME 11.0 (Skylake), so it might not even be useful/related to your issue.

[mfp20]

@ilikenwf

I did the same to my T410 a couple of months ago, I confirm your findings (disable ok, stripped down to ~80k doesn't boot). I didn't report here because I also soldered a bigger flash chip and changed the ram modules at the same time, and I'm having random reboots every 40-60 mins since then; then I hadn't spare time to keep working on that machine.

A small note, maybe useful: about two years ago I have edited coreboot's X201 memory mapping to make the T410 port. By digging into the device tree I noticed a few differences in the mappings. Those small differences might be the reason for our current issue...

Please all ( @corna ) keep posting on this thread if you make any progress on X201/T410.

[mparnelldmp]

@mfp20 I saw your commits on the gerrit, which of them is the one I should look at, the one with the larger number of added files, or just the smaller one and the gpio.h, or was it the patch file on the bug tracker? Regardless I wish someone would figure out why the master branch is broken - https://www.coreboot.org/Board:lenovo/x201

In my case my only reason for even being useful here and for coreboot is that my employer uses thinkpads, and whenever one breaks or dies and nobody else here in IT grabs it, I do and attempt to rehab the poor thing, with varying results (RIP trackpad and mouse on my T400).

Next time I take the T410 apart, I'll attempt stripping all but the MFS partition per @kakaroto, and then if that doesn't work, I'll go all trial and error on the stupid thing to see if one of those partitions is the cause.

[ilikenwf]

@kakaroto your addition was useful!

After some trial and error, I've found that you can soft disable and strip the ME on the T410, and thus very likely the x201, if you keep the EFFS partition.

As an aside, I did manage to get a fully working T410 build working, but because of the nature of the changes I just pushed them into a fork here on github.

I have an easier time chip clipping these thinkpads because I always cut out a square on the frame to allow access to the chip.

[ilikenwf]

It does appear that stripping in this manner somehow breaks system reboots/shutdowns (or causes them to take a long time to happen) and sometimes keyboard input in Seabios.

Not sure if it's an ME related issue there or if it's ACPI in Coreboot.

[mfp20]

@mparnelldmp honestly I don't remember the details. I probably duplicated all the x201 files to a new t410 directory, then grep&replace "x201" to "t410", and then adjusted the memory and I/O addresses taking the new values from my t410. The result should be many files added, but just a few changed.

@ilikenwf is the EFFS partition zeroed? I mean, those are ~900kB of ... wasted flash, or can be reused?

[ilikenwf]

@mfp20 I'm both of the accounts you pinged :)

The EFFS is not zeroed. I'm guessing it has something inside required for boot.

[kakaroto]

@ilikenwf Cool. The EFFS partition is probably the pre-ME11 equivalent of MFS.
As for your suspend/poweroff issues, I experienced the same thing but couldn't track it down. In the end, it only was happening on the prototype for the librem 13, but the suspend/shutdowns were not happening on the retail librem 13 hardware, so I didn't bother investigating further on the cause. I do remember disabling SMM mode in coreboot, hoping that the suspend/shutdowns freezes were caused by an SMI and that disabling SMM in coreboot would prevent the ME from installing the SMI (doubt it), but it didn't make a difference. I think it's the only thing I attempted before testing on retail hardware and realizing I didn't need to fix the problem
You can read about it here if you're interested: https://puri.sm/posts/deep-dive-into-intel-me-disablement/

[ilikenwf]

Thanks! I'll take a gander.

I had to order a new T410 board on eBay, though, as the one I have was built from junk and didn't have the correct heatsink on the cpu, and thus it overheated and now beyond powering on the thing appears to be dead...

[ArthurHeymans]

If when using coreboot (master seems to be broken but older versions still work) there is no huge delay on the EHCI console output with a cleaned ME, it is possible that vendor simply has very long timeouts where coreboot has infinite loops in the raminit...

shutdown/reboot requires working SMM which might simply be broken for ibexpeak in coreboot (does it work with full and valid ME region?)...

[xdel]

I am observing very interesting thing with x201 and failure which looks exactly as booting different platform with wrong MRC: in short, memory initialization may fail due to still-unclear bug when using coreboot and full ME image with HAP bit being set under certain circumstances.

How to reproduce:

• build coreboot and set HAP bit in the image, boot the board (i5-620),
• put the system in 16-bit mode, for example, boot to DOS, or stop on SeaBIOS prompt or bail out from grub with FDE,
• power the board off by pressing the button,
• voila, at next boot memory isn`t initialized at all due to memory init failure.

Re-using the original ME firmware seem to persistently fix the issue. If the HAP-enabled firmware usage is critical, you could possibly invalidate training data by putting DIMMs back and forth, using different DIMM configuratin and booting board without memory, though I`ve not reached stable 'revival' flow there yet.

Please confirm if the issue is observable somewhere else because this particular board showed memory link training(?) in the past with different dimms and coreboot at the moment when it was supposed to boot just ok - I`d be more determined to dig this down then.

//overall fixes, including wording

[xdel]

The #24 (comment) addresses 2-Gbyte PC-10600 double-sided memory module(s) and 4-Gbyte double-sided sticks PC-10600 are not working in reliable manner with x201x, so at least part of the problem could be addressed to higher frequencies on the MC`s lanes. While I still have none of solid explanation why reset from 16-bit mode triggers permanent boot failure described previously, I've partially resolved this problem for myself by disabling AMT and leaving full-fledged ME within the system due to power consumption issues and lack of hardware fan control with ME being disabled.

[ghost]

@xdel, just for clarity: what do you mean by "x201x"? For example, do you mean "x201, x201i, x201s, and x201t"? (Or have you only tested those memory configurations on a subset of that list?) Or was the "x" at the end just a typo? 😄

Thanks!

[xdel]

It goes for x201/x201t (U520, M520 and L620 variants) I do possess.

[corna]

me_cleaner + coreboot should work now correctly on the X201. There were two issues:

• Missing bounds check
• The EFFS partition must be kept, otherwise the PCIe devices don't work (done automatically if you select the "Strip down the Intel ME/TXE firmware" option in the coreboot menuconfig)

[ABN-Speed]

Confirmed working on my x201 with coreboot. Very nice work.

Seems like the same issue with me_cleaner and stock BIOS appears where fan is no longer controlled and remains off. I have used fancontrol service on Debian Buster to fix this which works beautifully. Problem with it though is that it stops controlling the fan after resume from suspend. The workaround is to restart the service, and I have found the way to do it automatically

I put this file (I named it 20_fancontrol) in your /lib/systemd/system-sleep/ folder

#!/bin/sh

case $1 in
  post)
    /usr/sbin/service fancontrol restart
    ;;
esac

That should keep the fan running even after suspend.

[nedson]

Confirmed working on my x201 with coreboot. Very nice work.

Seems like the same issue with me_cleaner and stock BIOS appears where fan is no longer controlled and remains off. I have used fancontrol service on Debian Buster to fix this which works beautifully. Problem with it though is that it stops controlling the fan after resume from suspend. The workaround is to restart the service, and I have found the way to do it automatically

I put this file (I named it 20_fancontrol) in your /lib/systemd/system-sleep/ folder

#!/bin/sh

case $1 in
  post)
    /usr/sbin/service fancontrol restart
    ;;
esac

That should keep the fan running even after suspend

So, the X201 is working fine with Coreboot and me_cleaner? Any outstanding issues to report other than fan? Getting setup to coreboot some x201's and would also like to apply me_cleaner.

If coreboot and me_cleaner are not possible, I am leaning towards just neutralising ME.

[ghost]

@nedson wrote:

So, the X201 is working fine with Coreboot and me_cleaner?

From the latest reports, this seems to be true. There's always a chance that this might have been due to a lucky combination of versions and/or BIOS chips, though.

Getting setup to coreboot some x201's and would also like to apply me_cleaner.

For one or more of those X201s, it would be great if you could try setting them up with Coreboot and me_cleaner, and report back, in this thread, on whether that succeeded or failed. (Be sure to have at least two consistent, clearly-named dumps of each X201's flash ROM content before you start replacing that content with anything else, just in case you need to restore them to their original states.) Hopefully it will succeed, but if not, then that would be helpful to know!

[Superbunnygirl]

@sampablokuper
I can confirm that X201s with me_cleaner & coreboot works (although it has some issues). Besides the fan issue listed above, rebooting/shutdown frequently does not work properly (the operating system will go through the shutdown process, but after it should reboot/shutoff, it just hangs). My express card also stopped working with me_cleaner+coreboot applied. Previously I had used me_cleaner alone without coreboot and it worked correctly. Combining the two broke it somehow. This really sucks because I used to make ample use my of expresscard slot.

[Stitch626]

Has anyone ever tried a small ME-FW? I mean, there are different types of ME. The x201 usually uses the big one with AMT and so on, but there are small images which doesn't support remote management (1,5 MB big?). Sure, the main goal would be to remove it entirely (or almost...) but to solve the fan issue and other ones, what about a small one?