Thinkpad L540 No backlight on LG or Samsung screen but works with AUO

Hello,
As stated in the subject, I have L540 with broken screen. Original one is AUO B156XTN02.6, eDP 30pin: https://www.panelook.com/B156XTN02.6_AUO_15.6_LCM_overview_20812.html
I replaced it with LP156WD1-TPB1: https://www.panelook.com/LP156WD1-TPB1_LG Display_15.6_LCM_overview_12288.html
The thing is that backlight is not working. I can barely see the picture once I use flashlight. The screen is surely working and tested on other laptop (non-Lenovo one).
I then borrowed LTN156KT01-001: https://www.panelook.com/LTN156KT01-001_Samsung_15.6_LCM_overview_15657.html
to check if maybe this would be compatible but still no luck (no backlight either).
I thought the backlight fuse might be burnt, but before checking it, I had connected an old AUO B156HTN03.4 just to try (it's slim design and mount points are not compatible with my version of L540). To my surprise, it worked! Backlight went on and picture was clear.
So, looks like the fuse is ok. I studied datasheets for both AUO and LG parts and they seem to be pin-compatible. I replaced the signal cable with brand new 04X4890 but the result is still the same. What could be the issue here? Does Lenovo disable backlight for non-AUO screens?

 

Have you tried using the Fn key to set various brightness settings?

These models use different PWM ranges:

Code:

                min     max
B156XTN02.6     200     10,000  Hz
 ""             1       100     %
LP156WD1-TPB1   9,500   10,500  Hz
 ""             6       100     %
LTN156KT01      5,000   100,000 Hz
 ""             0       100     %
B156HTN03.4     200     10,000  Hz
 ""             5       100     %

You would expect 10 KHz to be supported by all four panels, but it doesn't work quite like that. A certain frequency is translated to a specific on-off combination that then results in the effective 'dimming' (which it really isn't). Now, not all intermediate frequencies between the minimum and maximum values correspond to one of the on-off options; otherwise you'd be Fn'ing for quite a while before you'd notice some dimming taking place. Therefor the steps between the 200-10K of the AUOs may not line up neatly with those of the LG or Samsung.

Normally this wouldn't be an issue since the videocard, whether iGPU or dGPU, ought to be able to handle all ranges. But Lenovos are different in that they use whitelisting for various components in order to effectuate vendor lock-in. WLAN cards are the most well-known, but they also do the same thing with panels and batteries. Extracting the latest bios for this model shows the following panels included in the whitelist:

1. LEN40A0 - B140XTN03.3
2. LEN40A0 - HB140WX1-401
3. LEN40A0 - LP140WH2-TPT1
4. LEN40A0 - LTN140AT30-401
5. LEN40A0 - N140BGE-E33
6. LEN40A1 - B140RTN02.3
7. LEN40A1 - LP140WD2-TPB1
8. LEN40A1 - N140FGE-EA2
9. LEN40B0 - B156XTN02.6
10. LEN40B0 - LP156WH4-TPP1
11. LEN40B0 - N156BGE-E11
12. LEN40B4 - B156HTN03.4
13. LEN40B4 - N156HGE-EA1
14. LEN40B4 - N156HGE-EA2

The LEN1234 is the universal plug-and-play id and should make it uniquely identifiable (note there's six different ones that go by 'LEN40A0' ), but Lenovo does not actually make panels. The AUOs (B...) would be AUO1234 and LG (LP...) LGD1234 and so on. What Lenovo does in order to accomplish their lock-in is ordering their batches from the lcd manufacturers with the specific instruction to change their regular id to the LEN**** you see in the bios. Dell does something similar btw, except using the free text string instead of changing the actual PnP id. However, what Dell then doesn't do is block brightness control on non-Dell branded panels, whereas Lenovo's treatment is quite a bit harsher, as you've found out:
w550s/t550 LCD screen replacement - brightness set at max.

In most instances you'd be looking at a fixed brightness. From your description it now seems that the particular default setting isn't supported by either the LG or Samsung.

If you have a programmer then we could make a modified bios that supports both panels, replacing two of the 14" models. Flashing via software appeared to be blocked (modding breaks the security checks), but hardware programming will have no troubles there. Do make a backup of the eeprom first and disable TPM, if applicable.

We also need the identifiers (edids) from the LG and Samsung. The system has booted with both attached, so you can find copies of them in the registry. Exporting everything under this key should have that bit covered:

Alternatively, you could cut your losses and order another screen, this time a 'genuine' Lenovo. In the process supporting their nefarious business practices, of course .

 

Hi, thank you for this and sorry for the late response.
Adjusting the backlight via keyboard gives a little hope - the screen is either completely black or barely visible (it's like binary setting).
There's no way I'd support vendor lock-in, so let's proceed with BIOS mod. Exact L540 model: 20AU-A03YFR
Since I already returned LG panel, only Samsung one remains. The identifier appears to be

Code:

SEC544B

I have Raspberry Pi 4 with SO-8 clip. Together with Linux and flashrom, it will all act as a poor man's flash programming tool.

This is what I've pulled out from the registry
(HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\DISPLAY branch):

Code:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\DISPLAY\SEC544B]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\DISPLAY\SEC544B\1&8713bca&0&UID0]
"DeviceDesc"="@monitor.inf,%pnpmonitor.devicedesc%;Generic PnP Monitor"
"Capabilities"=dword:000000e4
"Address"=dword:00000000
"ConfigFlags"=dword:00000000
"ContainerID"="{15f69233-9723-56bf-97c9-86d252e42894}"
"HardwareID"=hex(7):4d,00,4f,00,4e,00,49,00,54,00,4f,00,52,00,5c,00,53,00,45,\
  00,43,00,35,00,34,00,34,00,42,00,00,00,00,00
"CompatibleIDs"=hex(7):2a,00,50,00,4e,00,50,00,30,00,39,00,46,00,46,00,00,00,\
  00,00
"ClassGUID"="{4d36e96e-e325-11ce-bfc1-08002be10318}"
"Service"="monitor"
"Driver"="{4d36e96e-e325-11ce-bfc1-08002be10318}\\0004"
"Mfg"="@monitor.inf,%generic%;(Standard monitor types)"

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\DISPLAY\SEC544B\1&8713bca&0&UID0\Device Parameters]
"EDID"=hex:00,ff,ff,ff,ff,ff,ff,00,4c,a3,4b,54,00,00,00,00,00,14,01,00,95,22,\
  13,78,0a,c8,95,9e,57,54,92,26,0f,50,54,00,00,00,01,01,01,01,01,01,01,01,01,\
  01,01,01,01,01,01,01,1c,2a,40,4c,61,84,1e,30,30,20,25,00,58,c2,10,00,00,1a,\
  13,1c,40,4c,61,84,1e,30,30,20,25,00,58,c2,10,00,00,1a,00,00,00,fe,00,36,54,\
  33,31,43,80,31,35,36,4b,54,0a,20,00,00,00,00,00,00,41,01,1e,00,00,00,00,09,\
  01,0a,20,20,00,c9

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\DISPLAY\SEC544B\1&8713bca&0&UID0\Device Parameters\WDF]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\DISPLAY\SEC544B\4&2ed6fb1e&0&UID265988]
"DeviceDesc"="@monitor.inf,%pnpmonitor.devicedesc%;Generic PnP Monitor"
"Capabilities"=dword:000000e0
"Address"=dword:00000400
"ConfigFlags"=dword:00000000
"ContainerID"="{00000000-0000-0000-ffff-ffffffffffff}"
"HardwareID"=hex(7):4d,00,4f,00,4e,00,49,00,54,00,4f,00,52,00,5c,00,53,00,45,\
  00,43,00,35,00,34,00,34,00,42,00,00,00,00,00
"CompatibleIDs"=hex(7):2a,00,50,00,4e,00,50,00,30,00,39,00,46,00,46,00,00,00,\
  00,00
"ClassGUID"="{4d36e96e-e325-11ce-bfc1-08002be10318}"
"Service"="monitor"
"Driver"="{4d36e96e-e325-11ce-bfc1-08002be10318}\\0003"
"Mfg"="@monitor.inf,%generic%;(Standard monitor types)"

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\DISPLAY\SEC544B\4&2ed6fb1e&0&UID265988\Device Parameters]
"EDID"=hex:00,ff,ff,ff,ff,ff,ff,00,4c,a3,4b,54,00,00,00,00,00,14,01,00,95,22,\
  13,78,0a,c8,95,9e,57,54,92,26,0f,50,54,00,00,00,01,01,01,01,01,01,01,01,01,\
  01,01,01,01,01,01,01,1c,2a,40,4c,61,84,1e,30,30,20,25,00,58,c2,10,00,00,1a,\
  13,1c,40,4c,61,84,1e,30,30,20,25,00,58,c2,10,00,00,1a,00,00,00,fe,00,36,54,\
  33,31,43,80,31,35,36,4b,54,0a,20,00,00,00,00,00,00,41,01,1e,00,00,00,00,09,\
  01,0a,20,20,00,c9

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\DISPLAY\SEC544B\4&2ed6fb1e&0&UID265988\Device Parameters\WDF]

 

Excellent !

Ok, first step is always a full backup of the eeprom.

Neat; didn't have that one yet. It's just copy/paste of the hex values, save as binary and you have your edid:
SEC544B - LTN156KT01-001.bin

Without a copy from the bios eeprom I just downloaded one from the Lenovo site. Unfortunately, they only seem to host the latest v1.93, hope that's ok since many brands are now pushing all kinds of
'security' updates that are merely so at an ephemeral sense yet at the expense of real performance. If you want an older version or you current one then hunt for Lenovo's update exe's or make a dump of the current system's bios.

Anyway, extracted the v1.93 and replaced one of the 14" LEN's with the Samsung:
Lenovo ThinkPad L540 - bios v1.93 (stock and edid mod).7z

The uncompressed bios image is 4MB and that means a 32MBit eeprom. It should be labeled *25*32*** on the chip. You have to verify that this is indeed so since the Intel ME firmware also has to be stored somewhere and it might be on the very same chip. In that case the eeprom could be 48, 64 or 128 MBit instead and we'd need to do some hex-editing before we have a proper binary to flash.

Sequence of events:

• Read out the eeprom, save as '...1.bin'.
• Read out the eeprom, save as '...2.bin'.
• Hex-compare both; they have to match 100%.
• Erase/blank eeprom.
• Read out and verify it's all FF's.
• Write the binary with the edid mod.
• 'Reset to defaults' once booted.

 

Malverous! I'm ok with flashing the latest BIOS. From what I've checked, the BIOS EEPROM in L540 is actually 8192kB large (MX25L6473E).
But here comes trouble - looks like Raspberry Pi 4 is unable to deliver required level of power to the chip while connected via SO-8 clip. All I get is 'EEPROM type 0x0 unrecognized' or sometimes even no connection message. I need to get CH341A to flash this thing (there are a couple of offers locally so hopefully I'll get one before weekend). Is the original EEPROM dump needed for this mod to proceed?

 

Yes, we'd need to know the arrangement of the different firmwares on the eeprom. Blindly flashing the 4MB would likely overwrite the Intel ME and then cause a certain brick. Most likely scenario is that you'll have to flash the 4MB bios to the second half of the chip. Once you have the dump then use a hex editor to copy/paste the binary mod starting at, probably, address 0x400000, but do check first to see if the start header is there and is similar to the binary mod. Looks like this snippet is indicating the EC version:



Mind that not all systems support In-System-Programming (ISP), so it could also mean the eeprom has to be desoldered first. And yes, reason might be the 3.3V is draining to other parts of the pcb.

A possible solution is to use the clip while the system is running. Sounds a bit crazy and you have to be careful then not to short anything with the clip, but it is certainly doable. All firmware is copied to memory during boot and the system is running from that copy, not the content on the eeprom. Added eeprom adapters to some of my systems and these allow me to pull the eeprom without desoldering and have used this sometimes to trick a bios updater tool into believing a different (older) version was installed.

Creating a full copy of the current data on the eeprom might also be accomplished with Universal BIOS Backup Toolkit, though this does not work with all eeproms. Some virus scanners don't like this file though, but the three best (imo) don't raise a flag (AVG, BitDefender and Kaspersky all offer the highest degree of intercepts with the fewest false positives).

 

I finally did read the EEPROM's contents, but only after desoldering the chip and then connecting a clip to it (Raspberry + flashrom 1.2 did manage). Did it four times and all files are the same (sha256sum matches for all). As you said, BIOS data begins exactly at 0x400000. Using hex editor, I replaced the dump's content under 0x400000 - 0x7FFFFF (to the end of the file). The resulting file has size = 8192kB , as the original dump.
One thing before flashing it back to chip: in the dump, BIOS version was 1.06 and modded version is 1.11, is it ok to flash it?

 

Sure thing; you now have a full eeprom backup and a method to flash it back.

Good luck !

 

OK, here's the summary: BIOS flashed, verified, then dumped again, compared with original - 100% match.
Soldered back to motherboard. After starting, Thinkpad gave me 4 short beeps I tried first with CMOS battery detached, then plugged it but it didn't change the outcome.
I thought that flashing went somehow wrong, so I attempted to repeat the desoldering / programming cycle, but then one of the pins broke leaving nothing to solder it back to
Currently I ordered the replacement (EN25Q64-104HIP), it appears to be cheap and compatible with MX25L6473E.

I wonder why initial flash didn't work. TPM and "Security chip" settings had been disabled before the operation. Or maybe it was the heat that killed IC in the process. Anyway, it won't hurt to try again. In the worst case, Thinkpad will be a source of parts for other Lenovos in the house.
If it's ok to post the entire dump here (no security or legal issues), then I'm happy to share what I flashed.

 

Sure, no problem in sharing.

Did you check all pins were soldered correctly with a multimeter? If it also does the '4 beep' without any eeprom on the pcb at all then it might simply have been due to one of the pins not making a good connection.

And it will run fine once you have then new chip + old dump, at a minimum.

We can also use the v1.06 dump to base the mod on; perhaps the v1.11 is incompatible with the currently-installed ME version (the Lenovo download was bios-only).

 

I too came to the conclusion that it was probably just bad soldering. I would be very grateful for preparing a mod based on original dump.
Original L540 dump: https://www.sendspace.com/file/auv2gw
SHA256: fe974d5241c510713a2968490e4f04af646d14a0260194861de155a5e7d4cd6c

Modded version (with BIOS v1.11 ) : https://www.sendspace.com/file/cupxu2
SHA256: ff1fbd1d20040c1fa2ae04b678f6cdefe167f2ed1ba3a1e70b614d7c97211fb0

Edit:
chips's still alive, I managed to read contents of the chip with broken pin (this cheap aliexpress SO-8 clip really came in handy) - and it matches the 'modded' file, so it's even more likely that sloppy soldering is to blame.

 

Sorry for the late reply; vacation.

And ok, is it working now then? Backlight and all or still waiting for the replacement chip?

If so then I'll hold off on the mod until it arrives. Suppose the v1.11 mod should suffice too.

 

It's ok. The "broken" chip kinda worked after flashing it with an old BIOS copy and soldering a cooper wire to the broken pin. By "working" I mean motherboard booting without backlight. It doesn't seem like a permanent solution though. Anyway, the replacement chip has just arrived, so I'm ready to flash it with modded v1.06.

 

One thing I noticed while looking at panels / replacements is AUO has a different pin pitch of 0.4mm vs other MFG's at 0.5mm on the panel connection side. There are a few AUO models that are more standard with 0.5mm connections though.

Might be as simple as the eDP cable from the MOBO to the panel? Could also be a Voltage difference that the mobo can't supply enough juice to power the panels properly.