Possible LCD Firmware corrupted due to NVIDIA & EVGA Precision X? Help!

[aarpcard]

I recently bought two GTX 970m's to replace the 7970m CFX setup in my p-377sm-a. I got the first card in the mail and installed it without any problems. It was essentially plug and play. The only problem was the throttling due to the TDP limit imposed by the vbios.

I decided to flash Prema's custom GTX 970m vbios which is supposed to take care of that issue.

I flashed the card, restarted my computer, and all I get is a black screen. The computer boots into windows fine, but the internal display is black. I plug the computer into an external monitor via HDMI, and it works. For some reason, after the flash windows stopped detecting the internal display.

At this point I decide to flash back to the original vbios to try and fix the issue. The flash was successful, but still a dead internal display. Next I try putting my 7970m's back into the computer and guess what, still a black internal display. WTF?

I reinstall the GTX 970m, and flash it to a different vbios. Upon restarting, the computer won't post. The vbios flash got corrupted somehow.

I put a 7970m back in the primary slot, and put the GTX 970m in the slave slot, upon booting, windows doesn't even detect the GTX 970m and nvflash is just as useless.

I take the GTX 970m out of the computer, and desolder the eeprom chip which stores the vbios. The only issue is the chip is sinking a TON of heat and it's very hard to get off. I finally get it off but the chip is destroyed. It turns out NVIDIA put a thermal well underneath the eeprom chip. Why the **** would you put a thermal well under a eeprom chip? It doesn't get hot - it doesn't need cooling! As a result, the chip sinks so much heat, that it's nearly impossible to remove it without destroying it.

So now I'm screwed . . . or maybe not. I have about 4 dead 6990m's lying around that all suffered from warped PCB breaking the solderjoints under the gpu itself.

I look at the eeprom's on those cards and compare them to the eeprom I took off of the GTX 970m. Different part number different chip.

However, according to the datasheets, they seem to be pin compatible. At this point I have nothing to loose, so I unsolder a few of the AMD 6990m eeproms (AMD didn't stupidly put a thermal well under the eeproms).

I pop the AMD chip into my flasher and flash Prema's GTX 970m vbios to the AMD eeprom to it. Everything seems fine and I proceed to solder the AMD eeprom to the GTX 970m.

Voila. It works!

Praise be to the eeprom gods.

TLDR: Fixed a bricked GTX 970m by soldering an AMD eeprom to it.

BUT:

I still have the issue of the internal display not being recognized by windows - not even turning on in the bios. Did the original vbios flash somehow corrupt the display firmware? If so, how did this happen? Prema, can you weigh in on this please?

Does anyone have any suggestions for either reflashing my display firmware or otherwise fixing the issue?

[Guest]

Sounds like you are using Windows 10...NVIDIA driver writes into LCDs eeprom and bricks it. Has nothing to do with vBIOS but the fact that the vBIOS flash triggered an disable-enable of NVIDIA driver, which allowed it to do its evil magic.

Welcome to the club of bricked W10 LCDs...there is an endless thread about this here:

http://forum.notebookreview.com/threads/windows-10-nvidia-whql-drivers-are-killing-alienware-and-clevo-lcd-panels.779449/

You need to use Linux in order to reflash the LCD:

https://mega.nz/#!GlcAESRT!KVSvAvhXMIsTPzleP3c9QksKKZFHKENNuP9lRL6N_mY

 

ALL CREDIT for putting everything together, writing instructions, gather the edids and test the thing on multiple platforms and lcds and combine it all into the live-distro package goes to brother t456 and not me!

[aarpcard]

Thanks for the fast reply man!

Forgot to mention, I'm using Windows 7 Professional 64bit.

I knew about the bricked LCD issue with Windows 10 prior to flashing, but didn't think it'd be an issue because I'm on 7. Is the same issue even possible on windows 7? I'll look into flashing it via linux.

[Guest]

If you ever used W10 (or have W10 preparation updates installed in W7/8.1) and/or are using EVGA Precision X in combination with the latest NVIDIA driver, then your system is a potential LCD bricking candidate.

NVIDIA driver will write an updated EDID table to screens eeprom and messes up the checksum while doing so.

As for re-flashing the screen:

All instructions are in the "EDID" folder that comes with the brother t456 Live-Distro. Use the correct EDID dump for your exact screen model.

-----------------------------------------------------------------------------------

Open a terminal window where you unzipped edid-rw and run:

sudo ./edid-rw 0 | edid-decode

sudo ./edid-rw 1 | edid-decode

sudo ./edid-rw 2 | edid-decode

 

 

etc....

 

 

until you see one of them returning the EDID information of your screen. (keep a dump for us).

 

 

Once you find it use:

chmod a+x write-edid.sh

 

(to set run permission)

 

 

and:

 

sudo ./write-edid.sh x screen.bin

 

 

 

Where "x" has to be replaced with the i2c bus number (1,2,3...) where you found the screen and "screen.bin" with the name of the working EDID file of your screen, which should be renamed and placed in the "write-edid" folder.

[aarpcard]

Never used Win 10 on this machine - however I was using Precision X =P

[Guest]

Sorry to hear you're a victim as well. EVGA Precision X seems to be one of the culprits. Perhaps the latest version or two. I've used it for years without issues. One of the threads @Prema posted a link to has instructions for flashing your LCD EDID in Linux. I bet I flashed my M18xR2 LCD at least 50 times in the past month before I figured out EVGA Precision X was a contributing factor. You can also use a programmer (which I have) but using Linux is much easier if you can get the machine to boot. Alienware fails to boot with 8 beeps if it cannot enumerate the display at POST.

@aarpcard did you have all of the latest Windows Updates applied to your Windows 7 installation? My Alienware 18 suffered the same fate on Windows 10 as my M18xR2 without EVGA Precision X installed on the Alienware 18, and some other Alienware and Clevo owners have had their LCD panels corrupted without EVGA Precision X. As best we can tell, Windows 10 and Window 10 readiness updates are the underlying cause, although EVGA Precision X is definitely playing hell with these NVIDIA-powered machines.1

Here is my first post on the Linux flashing process: LINK

Here is my first post using the USB programmer for flashing: LINK

@t456 gets all the credit... he was a huge help.

[aarpcard]

Thanks for all the helpful info guys - I'll keep you posted.

The latest updates to my OS were installed on 7/31/15 - so definitely not the MOST recent, but maybe recent enough?

Also I'm expecting my second GTX 970m to arrive tomorrow. Should I hold off on reflashing the display panel until I get the second card and flash it with prema's vbios, so the display doesn't get bricked a second time? Or would uninstalling Precision X be good enough?

[Guest]

Mr.Fox system stopped bricking on W7 after he got rid of EVGA Precision X.

[Guest]

Thanks for all the helpful info guys - I'll keep you posted.

The latest updates to my OS were installed on 7/31/15 - so definitely not the MOST recent, but maybe recent enough?

Also I'm expecting my second GTX 970m to arrive tomorrow. Should I hold off on reflashing the display panel until I get the second card and flash it with prema's vbios, so the display doesn't get bricked a second time? Or would uninstalling Precision X be good enough?

I think uninstalling Precision X and re-flashing the LCD should be enough. If you use a version of Precison X from earlier in the year (Q1 should be old enough) it should be OK. I never had any issues with it before, and I have been using it for a couple of years or more.

[aarpcard]

Just finished flashing with Linux. It works! Thanks a bunch, both of you!

Attached is a dump of the terminal window. I had the N173HGE-L11 panel, so I used the CMO1720_GTF_AUO_old.bin file and it worked.

This whole issue is really insane - I think there could be grounds for legal action somewhere. I'll keep you posted on if it reoccurs - especially when I flash the second card tomorrow, although I have uninstalled Precision X.

dump.txt

[aarpcard]

Just flashed my second card with Precision X uninstalled. No issues so far.

[AlBo007]

Hey Guys,

I even got my N173HGE-L11 running with flashing CMO1720_GTF_AUO_old.bin on it.

But I noticed that i am not able to adjust the brightness anymore. Maybe someone solved that litte problem.

[io____]

Hi where can I find the EDID bin file for glossy display of P150HM AUO B156HW1 v0 ?

Thanks

Simone

EDIT: I think I can get it from here

​B156HW01 V.0.pdf

it can be retrieved from the table at the bottom of the document.. but how to make into a .bin file?

S.

EDIT 2: I managed to get a proper EDID and reflash the display.. what a nightmare ..

[Guest]

Glad you guys all got it working again. I have also been made aware of a guy who never used EVGA Precision X but bricked it while playing with MSI Afterburner.

So best is to stick with NVIDIA Inspector until NVIDIA gets this g-sync pass through access filtered in their driver.

Also ZM/DM system user have to flash their screens in another system as the Linux App doesn't support their hardware, yet.

For backing up your current EDID (.bin) I would suggest to use this software:

http://www.entechtaiwan.com/<wbr>files/mi_setup.exe

[Tonrac]

where to download the correct edid ?

[Guest]

where to download the correct edid ?

All files are in the "EDID" folder that comes with the Live-Distro.

[@t0mX]

Sorry for unearthing this, but If you have not installed W10 yet and intend to, what are the choices? I haven't read anything yet (maybe I missed it) for systems that are not bricked yet:

1) Don't try your luck with W10 yet, it's not safe (as of december 2015)

2) install an older version of nvidia drivers + modded inf for W10 with driver signature disabled

Thanks

[RODBORA]

On ‎14‎/‎10‎/‎2015 at 9:31 PM, Prema said:

Sounds like you are using Windows 10...NVIDIA driver writes into LCDs eeprom and bricks it. Has nothing to do with vBIOS but the fact that the vBIOS flash triggered an disable-enable of NVIDIA driver, which allowed it to do its evil magic.

Welcome to the club of bricked W10 LCDs...there is an endless thread about this here:

http://forum.notebookreview.com/threads/windows-10-nvidia-whql-drivers-are-killing-alienware-and-clevo-lcd-panels.779449/

You need to use Linux in order to reflash the LCD:

https://mega.nz/#!GlcAESRT!KVSvAvhXMIsTPzleP3c9QksKKZFHKENNuP9lRL6N_mY

 

Hello folks.

 

I'm registered here in the Forum to include my experience and solution with the problem described in the tittle.

 

I have a Clevo P377SM-A, with a i74810MQ + a SLI of GTX870m. I'm using it since 18 months without any importants issues. But in the last days I tried a deadly sequence of software upgrades: The installation of  Windows 10, plus, almost in the same time, for a coincidence, the new version of EVGA Precision X (5.3.10) and, too, tried the new version of MSI Afterburner (4.2). I tried too the new version od NVIDIA Driver (361.43).

 

As you can see I made exactly the installation of the specific pieces of software that start the problem of lcd firmware corruption. :-( Well, I never could expect this kind of problem just to try a world wide new SO, or a driver from a world leader manufacturer of GPUs! But after complete the sequence of installations my lcd panel went to the same problem described in this post: no backlight, no boot (and a permanent boot cicle without POST).

 

The original configuration I always used in this equipment was Windows 8.1 + EVGA Precision X version 3.04 (yes, a very a old version) used only to monitor GPU temps. After upgrade to Windows 10 and install the new NVidia drivers and/or Precision X / MSI Afterburner, the lcd died.

 

I did my research to web and I'm  very glad because I found this forum and the post from Prema: https://www.techinferno.com/index.php?/forums/topic/8612-possible-lcd-firmware-corrupted-due-to-nvidia-evga-precision-x-help/&do=findComment&comment=129487

 

I followed (with great care) all the steps, using also the pictures included in .img Linux file) and my LCD is now working again! Thanks Prema. The .img file you did is amazing, Very complete and saved my notebook from RMA.

 

The only thing different was the result of command "sudo ./edid-rw 1 | edid-decode"  never returned the informations from my LCD EDID... At the first moments I even could find the exact specific model of my lcd panel. But I found the correct address, the correct I2C bus number of the notebook LCD using the command from the first steps described in the Instructions.txt file, wich use the command i2cdetect (I found the lcd in the bus #1). With this I find the model of my lcd: N173HGE-L11. Nice, but even with the correct bus number, the command "sudo ./edid-rw 1 | edid-decode" does NOT retrieved the informations from the lcd EDID. I decided so to try to write the new (and corrected) .bin firmware file to bus number #1, even this way, because I was sure that the bus number was #1. And it worked. :-)

 

So, the only one point in the procedure that I found different during the recovery process was this one (do not reach the informations from lcd EDID when using the command sudo ./edid-rw 1 | edid-decode. But found using i2cdetect and the write process to the correct bus number worked well.

 

So i'm very glad to found help here, AND THANK YOU PREMA. You gave me a great gift with the .img file with all informations available together in just one place. You did a amazing high high high level work finding a solution to this terrible bug from Microsoft and/or Nvidia.

 

Thanks Prema and all community.

 

RODBORA

Edited December 25, 2015 by RODBORA

[Guest]

Thanks, But ALL CREDIT for putting everything together, writing instructions, gather the edids and test the thing on multiple platforms and lcds and combine it all into the live-distro package goes to brother t456 and not me!

[Guest]

Hey guys. My Panther (P570WM) got its 60Hz LCD bricked by EVGA Precision X. I restored a Windows 10 drive image that had it installed and did not realize it until is was too late. Only had a black screen, could not access the BIOS and could not see anything at all until reaching the Windows desktop, then the registry EDID would kick in and the screen would light up. (Not good, but better than 8 beeps and no boot like Alienware.) I did not have an EDID.BIN file, but found a good EDID in the registry that I saved to a BIN file and wrote that to the display panel to fix it.

 

Booting from HDMI to the Alienware 18 screen (using HDMI input feature) I used @t456 bootable Linux tool kit to fix it. As you can see from the mess below, EVGA reprogrammed it from digital to analog display, LOL. Luckily, I was able to do a "flash in place" using this method.

 

<<<<BEFORE FLASHING>>>>
lubuntu@lubuntu:~/EDID/edid-rw$ sudo ./edid-rw 1 | edid-decode
Extracted contents:
header:          00 ff ff ff ff ff ff 00
serial number:   06 af 9d 14 00 00 00 00 01 13
version:         01 03
basic params:    00 26 15 78 0a
chroma info:     7d 45 ab 4f 38 a6 24 12 50 54
established:     00 00 00
standard:        01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01
descriptor 1:    a0 37 80 b4 70 38 32 40 6c 30 aa 00 7d d6 10 00 00 18
descriptor 2:    00 00 00 0f 00 00 00 00 00 00 00 00 00 00 00 00 00 20
descriptor 3:    00 00 00 fe 00 41 55 4f 0a 20 20 20 20 20 20 20 20 20
descriptor 4:    00 00 00 fe 00 42 31 37 33 48 57 30 31 20 56 34 20 0a
extensions:      00
checksum:        f6
Manufacturer: AUO Model 149d Serial Number 0
Made week 1 of 2009
EDID version: 1.3
Analog display, Input voltage level: 0.7/0.3 V  <<<<-LOOK HERE
Sync: <<<<-LOOK HERE
Maximum image size: 38 cm x 21 cm
Gamma: 2.20
RGB color display
First detailed timing is preferred timing
Established timings supported:
Standard timings supported:
Detailed mode: Clock 142.400 MHz, 381 mm x 214 mm
               1920 2028 2076 2100 hborder 0
               1080 1090 1100 1130 vborder 0
               -hsync -vsync
Manufacturer-specified data, tag 15
ASCII string: AUO
         ASCII string: B173HW01 V4
Checksum: 0xf6 (should be 0x76) <<<<-LOOK HERE (SHOULD NOT BE 0x76)
EDID block does NOT conform to EDID 1.3!
    Missing name descriptor
    Missing monitor ranges
EDID block does not conform at all!
    Block has broken checksum

<<<<AFTER FLASHING>>>>
lubuntu@lubuntu:~/EDID/edid-rw$ sudo ./edid-rw 1 | edid-decode
Extracted contents:
header:          00 ff ff ff ff ff ff 00
serial number:   06 af 9d 14 00 00 00 00 01 13
version:         01 03
basic params:    80 26 15 78 0a
chroma info:     7d 45 ab 4f 38 a6 24 12 50 54
established:     00 00 00
standard:        01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01
descriptor 1:    a0 37 80 b4 70 38 32 40 6c 30 aa 00 7d d6 10 00 00 18
descriptor 2:    00 00 00 0f 00 00 00 00 00 00 00 00 00 00 00 00 00 20
descriptor 3:    00 00 00 fe 00 41 55 4f 0a 20 20 20 20 20 20 20 20 20
descriptor 4:    00 00 00 fe 00 42 31 37 33 48 57 30 31 20 56 34 20 0a
extensions:      00
checksum:        f6
Manufacturer: AUO Model 149d Serial Number 0
Made week 1 of 2009
EDID version: 1.3
Digital display <<<<-LOOK HERE (CORRECTED)
Maximum image size: 38 cm x 21 cm
Gamma: 2.20
Supported color formats: RGB 4:4:4, YCrCb 4:2:2
First detailed timing is preferred timing
Established timings supported:
Standard timings supported:
Detailed mode: Clock 142.400 MHz, 381 mm x 214 mm
               1920 2028 2076 2100 hborder 0
               1080 1090 1100 1130 vborder 0
               -hsync -vsync
Manufacturer-specified data, tag 15
ASCII string: AUO
         ASCII string: B173HW01 V4
Checksum: 0xf6
EDID block does NOT conform to EDID 1.3!
    Missing name descriptor
    Missing monitor ranges
lubuntu@lubuntu:~/EDID/edid-rw$

 

@Prema - FYI - reference in case anyone you encounter runs into it. Good to know we can "steal" the registry code if we need to. I saved it using EnTech Monitor Asset Manager. I attached my EDID.BIN file for the 60Hz P570WM LCD.

I used the File > Save As feature and selected .BIN as the file type using the registry EDID. The line immediately above it (Real-time) in the screen shot had gibberish instead of the actual AUO149D LCD model name.

 

AUO149D-EDID.zip

Edited January 3, 2016 by Guest

[Guest]

@t456 has updated his Linux tool kit. Adding a reference to it here for anyone that may need it someday.

 

I am adding a backup of the P870DM-G screen's EDID here also... just in case. If I do that nobody should ever need it. If I don't, then somebody probably will need it.

 

Quote

Live and persistent Linux with edid tools (760 MB)

Changes:

• far more edids in archive (main reason for new version)
• slightly re-organised
• slightly smaller (-1% :vbbiggrin: )
• spelling (ahem :vboops: )

It's based on lubuntu, btw (try it sometime). This choice was made after excessive trial and error detailed and exhaustive prior research, seeing as it met all criteria:

• live -> no install required
• persistent -> changes stick, even after reboot
• dual boot uefi+legacy -> in case of impossibility to switch
• small -> downloadable(-ish)

 

1. Instructions to write to stick:
    
2. It can be written to a 1GB usb stick (or drive) using USB Image Tool.
3. Don't use 'apt-get update'; Linux isn't 100% perfect either and some older systems didn't seem to like this. If you can't boot it any more; rewrite the image to the stick, that's all.
4. Read, comprehend and follow the instructions below (in that order, preferably ).

Spoiler

start
01    check 'pnp id -panel nrs.txt' for the correct bin (in the 'archive' folder)
02    copy it to the 'write-edid' folder
03    open terminal (ctr+alt+T)
04    sudo bash
05    sudo sensors-detect
    Hit 'n' for all 'YES/no' questions, EXCEPT I2C/SMBus, hit 'y' for that.
    There'll be something like 'Using driver 'i2c-XYZ' <- mine was i2c-i801 (Lynx Point),
    hit 'n' for the remaining questions.
06    sudo modprobe i2c-XYZ (i2c-i801 for me)
07    sudo modprobe i2c-dev
08    sudo i2cdetect -l
result:
######################################
root@it:~# sudo i2cdetect -l
i2c-0    i2c           i915 gmbus ssc                      I2C adapter
i2c-1    i2c           i915 gmbus vga                      I2C adapter
i2c-2    i2c           i915 gmbus panel                    I2C adapter
i2c-3    i2c           i915 gmbus dpc                      I2C adapter
i2c-4    i2c           i915 gmbus dpb                      I2C adapter
i2c-5    i2c           i915 gmbus dpd                      I2C adapter
i2c-6    i2c           DPDDC-A                             I2C adapter
i2c-7    i2c           DPDDC-C                             I2C adapter
i2c-8    i2c           nouveau-0000:01:00.0-0              I2C adapter
i2c-9    i2c           nouveau-0000:01:00.0-1              I2C adapter
i2c-10    i2c           nouveau-0000:01:00.0-2              I2C adapter
i2c-11    i2c           nouveau-0000:01:00.0-5              I2C adapter
i2c-12    i2c           nouveau-0000:01:00.0-6              I2C adapter
i2c-13    i2c           nouveau-0000:01:00.0-7              I2C adapter
i2c-14    i2c           nouveau-0000:01:00.0-8              I2C adapter
i2c-15    i2c           nouveau-0000:01:00.0-9              I2C adapter
i2c-16    i2c           nouveau-0000:01:00.0-26             I2C adapter
i2c-17    i2c           nouveau-0000:01:00.0-27             I2C adapter
i2c-18    i2c           nouveau-0000:01:00.0-28             I2C adapter
i2c-19    i2c           nouveau-0000:01:00.0-29             I2C adapter
root@it:~#
######################################
    If, for whatever reason, you have restarted/rebooted AFTER running 'i2cdetect -l';
    ALWAYS RE-RUN THAT COMMAND before asssuming the edid will be on the same bus. The bus
    enumeration is usually fixed, but not always so; make CERTAIN you have the right bus.
    Those 0-19 are the list of buses, now we need to find out which bus the panel is on.
    It could be 'panel' (bus 2), but one the 'DPDDC's is also possible.
    Let's try bus 2 first. we read (-r) the bytes 0 to 127, so 128 bytes in total, and
    we check this bus 2 at address 50 <- this SHOULD contain the edid, BUT-T-T-T ...
    that is not guaranteed -> IF it is on a different address then either the read part
    or, especially, the writing part can change things that are hard to fix.
    We're not interested in the difference between 128 byte or 256 byte edids yet,
    so extracting the first 128 bytes will do for now.
09    sudo i2cdump -r 0-127 2 0x50
result:
######################################
root@it:~# sudo i2cdump -r 0-127 2 0x50
No size specified (using byte-data access)
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-2, address 0x50, mode byte
Probe range limited to 0x00-0x7f.
Continue? [Y/n] y
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
10: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
20: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
30: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
40: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
50: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
60: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
70: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
root@it:~#
######################################
    So the edid is not here. If it was the edid then you'll see the
    '00 FF FF FF FF FF FF 00' start header, even if a little corrupted.
    If you find that then you know the bus AND the address.
    Anyway, let's try bus 6 next (DPDDC-A).
09    sudo i2cdump -r 0-127 6 0x50
result:
######################################
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 00 ff ff ff ff ff ff 00 4d 10 ff 13 00 00 00 00    ........M?.?....
10: 00 17 01 04 a5 1d 11 78 06 de 50 a3 54 4c 99 26    .??????x??P?TL?&
20: 0f 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01    ?PT...??????????
30: 01 01 01 01 01 01 56 5e 00 a0 a0 a0 29 50 30 20    ??????V^.???)P0
40: 35 00 26 a5 10 00 00 18 00 00 00 10 00 00 00 00    5.&??..?...?....
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 10 00 00    .............?..
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fc    ...............?
70: 00 4c 51 31 33 33 54 31 4a 57 30 32 0a 20 00 b0    .LQ133T1JW02? .?
######################################
    Good, bus 6 it is. Now pay attention to byte 7e. Read address
    like it was excel: ROW-COLUMN. In this example 7e = 00 (zero) and
    it's in-between values 20 and b0.
    The b0 is the final byte (and checksum), if 7e = 01 (one)
    then you have an extension block and require a 256 byte edid.
    These are also availeable in the archive, but the difference is that
    you need to use 'write-edid-256.sh' instead of 'write-edid.sh'.
    Let's make an export to verify actual corruption first and
    also to help further research:
09    sudo i2cdump -r 0-127 6 0x50 > EDID/edidexport.txt
    Or, if case you have a 256 byte edid:
09    sudo i2cdump -r 0-255 6 0x50 > EDID/edidexport.txt
    Check the export by opening the .txt and copy/pasting the
    significant hex values to the Web Based EDID Reader website.
    The pasted values should be stripped of row and column id
    and the ascii characters to the right:
example:
######################################
00 ff ff ff ff ff ff 00 4d 10 ff 13 00 00 00 00
00 17 01 04 a5 1d 11 78 06 de 50 a3 54 4c 99 26
0f 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01
01 01 01 01 01 01 56 5e 00 a0 a0 a0 29 50 30 20
35 00 26 a5 10 00 00 18 00 00 00 10 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 10 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fc
00 4c 51 31 33 33 54 31 4a 57 30 32 0a 20 00 b0
######################################
    If the EDID Reader says 'checksum valid' then do not proceed
    any further; the edid is fine and, thus, something else must be wrong ...
    If it says 'checksum fail' AND you have your bus AND address by now;
    skip the stuff below and proceed to step 10.
    If, on the other hand, you received all XX on all buses then 50 is not
    the right address for you ... we need to look beyond 50:
09    sudo i2cdetect 6
result:
######################################
root@it:~# sudo i2cdetect 6
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-6.
I will probe address range 0x03-0x77.
Continue? [Y/n] y
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- 11 -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: 50 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --           
root@it:~#
######################################
    So there IS something else here besides the edid at 50 ...
    Wonder what that button does ...
    Anyway; go back to the beginning of step 9 and redo the 'read bus',
    only this time at address 11 (or whatever your results were).
######################################
10    cd EDID/edid-rw
    At this point we should have:
    - BUS (here 6)
    - ADDRESS (here 50)
    - EDID LENGTH 128 or 256 (here 128).
11    sudo ./edid-rw 6 | edid-decode
    This is just a precaution; we want to make sure edid-rw uses the
    right address, if not then we need to change its code (report this if so).
result:
######################################
root@it:~/EDID/edid-rw# sudo ./edid-rw 6 | edid-decode
Extracted contents:
header:          00 ff ff ff ff ff ff 00
serial number:   4d 10 ff 13 00 00 00 00 00 17
version:         01 04
basic params:    a5 1d 11 78 06
chroma info:     de 50 a3 54 4c 99 26 0f 50 54
established:     00 00 00
standard:        01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01
descriptor 1:    56 5e 00 a0 a0 a0 29 50 30 20 35 00 26 a5 10 00 00 18
descriptor 2:    00 00 00 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00
descriptor 3:    00 00 00 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00
descriptor 4:    00 00 00 fc 00 4c 51 31 33 33 54 31 4a 57 30 32 0a 20
extensions:      00
checksum:        b0
Manufacturer: SHP Model 13ff Serial Number 0
Made week 0 of 2013
EDID version: 1.4
Digital display
8 bits per primary color channel
DisplayPort interface
Maximum image size: 29 cm x 17 cm
Gamma: 2.20
Supported color formats: RGB 4:4:4
Default (sRGB) color space is primary color space
First detailed timing is preferred timing
Established timings supported:
Standard timings supported:
Detailed mode: Clock 241.500 MHz, 294 mm x 165 mm
               2560 2608 2640 2720 hborder 0
               1440 1443 1448 1481 vborder 0
               -hsync -vsync
Dummy block
Dummy block
Monitor name: LQ133T1JW02
Checksum: 0xb0
EDID block does NOT conform to EDID 1.3!
    Missing monitor ranges
root@it:~/EDID/edid-rw#
######################################
    Good, so we're looking at the same thing. If you've made it this far
    then we're pretty much finished.
    IF you have an edid address different from 50, then we need
    to change the write-edid.sh script accordingly (diy or report this).
    If it is the standard address 50, then proceed:
    Let's rewrite the edid (the .bin you copied to the 'write-edid' folder).
    We'll presume it's called ABCDEF.bin. The actual tool it uses is i2cset
    (docs bookmarked), but this writes byte-for-byte, whereas
    the write-edid.sh script automates that (with address=50 pre-set).
12    cd ..
13    cd write-edid
14    sudo bash ./write-edid.sh 6 ABCDEF.bin
result:
######################################
root@it:~/EDID/write-edid# sudo bash ./write-edid.sh 6 SHP13FFmod.bin
Writing byte 0x00 to bus 6, chip-adress 0x50, data-adress 0x00
Writing byte 0xFF to bus 6, chip-adress 0x50, data-adress 0x01
Writing byte 0xFF to bus 6, chip-adress 0x50, data-adress 0x02
Writing byte 0xFF to bus 6, chip-adress 0x50, data-adress 0x03
Writing byte 0xFF to bus 6, chip-adress 0x50, data-adress 0x04
Writing byte 0xFF to bus 6, chip-adress 0x50, data-adress 0x05
Writing byte 0xFF to bus 6, chip-adress 0x50, data-adress 0x06
Writing byte 0x00 to bus 6, chip-adress 0x50, data-adress 0x07
Writing byte 0x30 to bus 6, chip-adress 0x50, data-adress 0x08
Writing byte 0xE4 to bus 6, chip-adress 0x50, data-adress 0x09
Writing byte 0x6C to bus 6, chip-adress 0x50, data-adress 0x0a
Writing byte 0x04 to bus 6, chip-adress 0x50, data-adress 0x0b
Writing byte 0x00 to bus 6, chip-adress 0x50, data-adress 0x0c
Writing byte 0x00 to bus 6, chip-adress 0x50, data-adress 0x0d
Writing byte 0x00 to bus 6, chip-adress 0x50, data-adress 0x0e
Writing byte 0x00 to bus 6, chip-adress 0x50, data-adress 0x0f
Writing byte 0x00 to bus 6, chip-adress 0x50, data-adress 0x10
Writing byte 0x18 to bus 6, chip-adress 0x50, data-adress 0x11
Writing byte 0x01 to bus 6, chip-adress 0x50, data-adress 0x12
Writing byte 0x04 to bus 6, chip-adress 0x50, data-adress 0x13
Writing byte 0xA5 to bus 6, chip-adress 0x50, data-adress 0x14
Writing byte 0x1D to bus 6, chip-adress 0x50, data-adress 0x15
Writing byte 0x11 to bus 6, chip-adress 0x50, data-adress 0x16
Writing byte 0x78 to bus 6, chip-adress 0x50, data-adress 0x17
Writing byte 0x06 to bus 6, chip-adress 0x50, data-adress 0x18
Writing byte 0xDE to bus 6, chip-adress 0x50, data-adress 0x19
Writing byte 0x50 to bus 6, chip-adress 0x50, data-adress 0x1a
Writing byte 0xA3 to bus 6, chip-adress 0x50, data-adress 0x1b
Writing byte 0x54 to bus 6, chip-adress 0x50, data-adress 0x1c
Writing byte 0x4C to bus 6, chip-adress 0x50, data-adress 0x1d
Writing byte 0x99 to bus 6, chip-adress 0x50, data-adress 0x1e
Writing byte 0x26 to bus 6, chip-adress 0x50, data-adress 0x1f
Writing byte 0x0F to bus 6, chip-adress 0x50, data-adress 0x20
Writing byte 0x50 to bus 6, chip-adress 0x50, data-adress 0x21
Writing byte 0x54 to bus 6, chip-adress 0x50, data-adress 0x22
Writing byte 0x00 to bus 6, chip-adress 0x50, data-adress 0x23
Writing byte 0x00 to bus 6, chip-adress 0x50, data-adress 0x24
Writing byte 0x00 to bus 6, chip-adress 0x50, data-adress 0x25
Writing byte 0x01 to bus 6, chip-adress 0x50, data-adress 0x26
Writing byte 0x01 to bus 6, chip-adress 0x50, data-adress 0x27
Writing byte 0x01 to bus 6, chip-adress 0x50, data-adress 0x28
Writing byte 0x01 to bus 6, chip-adress 0x50, data-adress 0x29
Writing byte 0x01 to bus 6, chip-adress 0x50, data-adress 0x2a
Writing byte 0x01 to bus 6, chip-adress 0x50, data-adress 0x2b
Writing byte 0x01 to bus 6, chip-adress 0x50, data-adress 0x2c
Writing byte 0x01 to bus 6, chip-adress 0x50, data-adress 0x2d
Writing byte 0x01 to bus 6, chip-adress 0x50, data-adress 0x2e
Writing byte 0x01 to bus 6, chip-adress 0x50, data-adress 0x2f
Writing byte 0x01 to bus 6, chip-adress 0x50, data-adress 0x30
Writing byte 0x01 to bus 6, chip-adress 0x50, data-adress 0x31
Writing byte 0x01 to bus 6, chip-adress 0x50, data-adress 0x32
Writing byte 0x01 to bus 6, chip-adress 0x50, data-adress 0x33
Writing byte 0x01 to bus 6, chip-adress 0x50, data-adress 0x34
Writing byte 0x01 to bus 6, chip-adress 0x50, data-adress 0x35
Writing byte 0x2A to bus 6, chip-adress 0x50, data-adress 0x36
Writing byte 0x44 to bus 6, chip-adress 0x50, data-adress 0x37
Writing byte 0x80 to bus 6, chip-adress 0x50, data-adress 0x38
Writing byte 0xA0 to bus 6, chip-adress 0x50, data-adress 0x39
Writing byte 0x70 to bus 6, chip-adress 0x50, data-adress 0x3a
Writing byte 0x38 to bus 6, chip-adress 0x50, data-adress 0x3b
Writing byte 0x27 to bus 6, chip-adress 0x50, data-adress 0x3c
Writing byte 0x40 to bus 6, chip-adress 0x50, data-adress 0x3d
Writing byte 0x30 to bus 6, chip-adress 0x50, data-adress 0x3e
Writing byte 0x20 to bus 6, chip-adress 0x50, data-adress 0x3f
Writing byte 0x35 to bus 6, chip-adress 0x50, data-adress 0x40
Writing byte 0x00 to bus 6, chip-adress 0x50, data-adress 0x41
Writing byte 0x26 to bus 6, chip-adress 0x50, data-adress 0x42
Writing byte 0xA5 to bus 6, chip-adress 0x50, data-adress 0x43
Writing byte 0x10 to bus 6, chip-adress 0x50, data-adress 0x44
Writing byte 0x00 to bus 6, chip-adress 0x50, data-adress 0x45
Writing byte 0x00 to bus 6, chip-adress 0x50, data-adress 0x46
Writing byte 0x18 to bus 6, chip-adress 0x50, data-adress 0x47
Writing byte 0x56 to bus 6, chip-adress 0x50, data-adress 0x48
Writing byte 0x5E to bus 6, chip-adress 0x50, data-adress 0x49
Writing byte 0x00 to bus 6, chip-adress 0x50, data-adress 0x4a
Writing byte 0xA0 to bus 6, chip-adress 0x50, data-adress 0x4b
Writing byte 0xA0 to bus 6, chip-adress 0x50, data-adress 0x4c
Writing byte 0xA0 to bus 6, chip-adress 0x50, data-adress 0x4d
Writing byte 0x29 to bus 6, chip-adress 0x50, data-adress 0x4e
Writing byte 0x50 to bus 6, chip-adress 0x50, data-adress 0x4f
Writing byte 0x30 to bus 6, chip-adress 0x50, data-adress 0x50
Writing byte 0x20 to bus 6, chip-adress 0x50, data-adress 0x51
Writing byte 0x35 to bus 6, chip-adress 0x50, data-adress 0x52
Writing byte 0x00 to bus 6, chip-adress 0x50, data-adress 0x53
Writing byte 0x26 to bus 6, chip-adress 0x50, data-adress 0x54
Writing byte 0xA5 to bus 6, chip-adress 0x50, data-adress 0x55
Writing byte 0x10 to bus 6, chip-adress 0x50, data-adress 0x56
Writing byte 0x00 to bus 6, chip-adress 0x50, data-adress 0x57
Writing byte 0x00 to bus 6, chip-adress 0x50, data-adress 0x58
Writing byte 0x18 to bus 6, chip-adress 0x50, data-adress 0x59
Writing byte 0x00 to bus 6, chip-adress 0x50, data-adress 0x5a
Writing byte 0x00 to bus 6, chip-adress 0x50, data-adress 0x5b
Writing byte 0x00 to bus 6, chip-adress 0x50, data-adress 0x5c
Writing byte 0xFE to bus 6, chip-adress 0x50, data-adress 0x5d
Writing byte 0x00 to bus 6, chip-adress 0x50, data-adress 0x5e
Writing byte 0x4C to bus 6, chip-adress 0x50, data-adress 0x5f
Writing byte 0x47 to bus 6, chip-adress 0x50, data-adress 0x60
Writing byte 0x20 to bus 6, chip-adress 0x50, data-adress 0x61
Writing byte 0x44 to bus 6, chip-adress 0x50, data-adress 0x62
Writing byte 0x69 to bus 6, chip-adress 0x50, data-adress 0x63
Writing byte 0x73 to bus 6, chip-adress 0x50, data-adress 0x64
Writing byte 0x70 to bus 6, chip-adress 0x50, data-adress 0x65
Writing byte 0x6C to bus 6, chip-adress 0x50, data-adress 0x66
Writing byte 0x61 to bus 6, chip-adress 0x50, data-adress 0x67
Writing byte 0x79 to bus 6, chip-adress 0x50, data-adress 0x68
Writing byte 0x0A to bus 6, chip-adress 0x50, data-adress 0x69
Writing byte 0x20 to bus 6, chip-adress 0x50, data-adress 0x6a
Writing byte 0x20 to bus 6, chip-adress 0x50, data-adress 0x6b
Writing byte 0x00 to bus 6, chip-adress 0x50, data-adress 0x6c
Writing byte 0x00 to bus 6, chip-adress 0x50, data-adress 0x6d
Writing byte 0x00 to bus 6, chip-adress 0x50, data-adress 0x6e
Writing byte 0xFE to bus 6, chip-adress 0x50, data-adress 0x6f
Writing byte 0x00 to bus 6, chip-adress 0x50, data-adress 0x70
Writing byte 0x4C to bus 6, chip-adress 0x50, data-adress 0x71
Writing byte 0x50 to bus 6, chip-adress 0x50, data-adress 0x72
Writing byte 0x31 to bus 6, chip-adress 0x50, data-adress 0x73
Writing byte 0x37 to bus 6, chip-adress 0x50, data-adress 0x74
Writing byte 0x33 to bus 6, chip-adress 0x50, data-adress 0x75
Writing byte 0x57 to bus 6, chip-adress 0x50, data-adress 0x76
Writing byte 0x46 to bus 6, chip-adress 0x50, data-adress 0x77
Writing byte 0x34 to bus 6, chip-adress 0x50, data-adress 0x78
Writing byte 0x2D to bus 6, chip-adress 0x50, data-adress 0x79
Writing byte 0x53 to bus 6, chip-adress 0x50, data-adress 0x7a
Writing byte 0x50 to bus 6, chip-adress 0x50, data-adress 0x7b
Writing byte 0x44 to bus 6, chip-adress 0x50, data-adress 0x7c
Writing byte 0x31 to bus 6, chip-adress 0x50, data-adress 0x7d
Writing byte 0x00 to bus 6, chip-adress 0x50, data-adress 0x7e
Writing byte 0x6B to bus 6, chip-adress 0x50, data-adress 0x7f
Writing done, here is the output of i2cdump -y 6 0x50:
No size specified (using byte-data access)
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 00 ff ff ff ff ff ff 00 4d 10 ff 13 00 00 00 00    ........M?.?....
10: 00 17 01 04 a5 1d 11 78 06 de 50 a3 54 4c 99 26    .??????x??P?TL?&
20: 0f 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01    ?PT...??????????
30: 01 01 01 01 01 01 56 5e 00 a0 a0 a0 29 50 30 20    ??????V^.???)P0
40: 35 00 26 a5 10 00 00 18 00 00 00 10 00 00 00 00    5.&??..?...?....
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 10 00 00    .............?..
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fc    ...............?
70: 00 4c 51 31 33 33 54 31 4a 57 30 32 0a 20 00 b0    .LQ133T1JW02? .?
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
######################################
    So ... it's the same edid ... Seems my eeprom is already
    write-protected (unfortunately, for me; it'd be 75Hz otherwise).
    If successful then you should have a different edid than before
    and your panel is fixed.
    There's also a vcom eeprom, but let's not get into that right now.
finish

 

 

 

See folder 'home -> EDID -> archive' for the correct edids. Everything else is in the EDID folder as well, including the instructions and edid tools. Firefox has the proper websites, guides and documentation bookmarked, that way you can keep them open side-by-side to the console. There's also a few screenshots (uncommented) and an easy-extract spreadsheet. This strips the backup or ic2dump output of the row and column headers, that way you can copy/paste it to the Web Based EDID Reader and check the data.

Good luck! 

 

 

P870DM-1080P-LGD0469-LP173WF4-SPF1.zip

Edited January 3, 2016 by Guest

[Guest]

For those that have not already discovered it, ASUS GPU Tweak has voltage control for notebook GPUs, so that may be a safe alternative to EVGA Precision X if you find NVIDIA Inspector to be as cumbersome and slow to deal with as I do. Notice that I said "may be safe" because I don't know for certain whether or not whatever EVGA Precision X does to corrupted EDID is an exclusive "feature" of Precision X.

 

 

[warhammer64k]

Prema, Mr. Fox and to other people working on this thread, thank you. Mine was on bus 1, flashed via HDMI, totally worth it. You guys are geniuses.

 

SO happy right now. My troublesome LCD thanks y'all

[huatson]

i just read the whole thread, and i got exactly the same COMBO for a Killer of LCD Panels. Being said that, already got my LCD Bricked.

tried to follow the instructions about the GREAT lubuntu ditro that you guys did (!!! awesome! !!). unfortunetly for me, im a total newbie with Linux/Ubuntu.

 

so, someone please can give me support of how (if it could) unbrick my LCD (Clevo P377-SM 980M SLI). already use MonInfo in order to get the proper Bin File (CMO1720, chinesse or Tw model). 

do i need to leave the distro running ?

(dont know if its OK or not) but i got an endless list of messages (on the hdmi screen) like this:

 

DD responded, but no EDID for LVDS-1.

 

do i'm missing something else?

do i need cut some wires or something? (dont want avoid my Warranty (posible RMA still))

 

Update: Already Managed to get the CMO1720_Working.bin (by using the custom distro).

 

Very Noob Question: What i should do next ? (i believe that i need to do a some sort of re-flash to the Bios? Monitor ? using that file).

 

Update: Oficially, i am a NOOB and all their means. was missing just restart the computer. TY so much for this (even if i answer my self here it WORKED like a charm !)

gotta update my facebook profile with : "Feeling like a stoopid right now".

 

Edited March 19, 2016 by huatson
because im a stupid...

[Guest]

23 hours ago, huatson said:

i just read the whole thread, and i got exactly the same COMBO for a Killer of LCD Panels. Being said that, already got my LCD Bricked.

tried to follow the instructions about the GREAT lubuntu ditro that you guys did (!!! awesome! !!). unfortunetly for me, im a total newbie with Linux/Ubuntu.

 

so, someone please can give me support of how (if it could) unbrick my LCD (Clevo P377-SM 980M SLI). already use MonInfo in order to get the proper Bin File (CMO1720, chinesse or Tw model). 

do i need to leave the distro running ?

(dont know if its OK or not) but i got an endless list of messages (on the hdmi screen) like this:

 

DD responded, but no EDID for LVDS-1.

 

do i'm missing something else?

do i need cut some wires or something? (dont want avoid my Warranty (posible RMA still))

 

Update: Already Managed to get the CMO1720_Working.bin (by using the custom distro).

 

Very Noob Question: What i should do next ? (i believe that i need to do a some sort of re-flash to the Bios? Monitor ? using that file).

 

Update: Oficially, i am a NOOB and all their means. was missing just restart the computer. TY so much for this (even if i answer my self here it WORKED like a charm !)

gotta update my facebook profile with : "Feeling like a stoopid right now".

 

Welcome to the community. 

 

By virtue of the fact that you managed to work through the process and fix it you have demonstrated you are not stupid at all.

 

And, now you're no longer a noob... you have valuable experience and proven intelligence.