-
Solved: LG 27UL500w LCD Monitor SPI Flash corruppted - Flash dump required
Posted by DL4JY on 05 Apr, 2024 18:00 -
Hello,
I have a LG 27UL500w 4k 27" Monitor - three years old. It stopped working and the buzzer is giving some kind of humming noise.
It seems that the SPI Flash got corruppted. The problem is now how get the original content of the flash IC . I am probably able to write the flash via HDMI I2C - if not, definitely with a programmer.
Can somebody help out, please ?
many thanks
Juergen
-
Hello ladies & gentlemen, Hello Dave
to elaborate a bit on the VGA,DVI,HDMI I2C Interface.
Especially with Realtek/LG in view. And how to get a dump of the SPI Flash.
The Video busses have a dedicated communication line für I2c - SDA & SCL.
Through this you are in a position to access the internal SPI flash (Gigadevice 25q32) with special commands through the Realtek integrated circuit (here: RTD2595) . This is true for read and write.
You can acess the internal Flash - as said - via HDMI. I used an Raspberry 3+ (RPI) to do this.
The software required is minimal - once you found it. :-)
See https://github.com/floppes/RTD266xFlash
as reference.
This is what I have done to virgin RPI installation:
steps in detail required:
sudo nano /boot/config.txt
add there:
dtparam=i2c2_iknowwhatimdoing
dtoverlay=vc4-kms-v3d
Ctrl-o to write the config back to SD.
check that you can see your monitor via I2C.
i2cdetect -y 2
standard is I2Cbus No. 2 for the HDMI monitor on the RPI.
now get the python script to read/write & erase the SPI flash IC over HDMI.
git clone https://github.com/floppes/RTD266xFlash.git
cd RTD266xFlash/RTD266xPy
Voila ready:
this reads the 25q32 which has 256 x 16384 banks & 32 MBit = 4 Mbyte.
takes ca. 15 minutes to run
python rtd266x_flash.py -i 2 -r 4194304 -f LGdump.bin
After this you have on the SD-Card of the RPI the dumped firmware of your LG Monitor.
Save it - sometimes SPI can get bad. I had that after a master/slave power socket started to oscillate with ca. 10Hz.
Upload of the file can be done via
python rtd266x_flash.py -i 2 -w -f LGdump.bin
This is all and not from me - just collected.
BTW, if somebody has after this procedure accidentally a usable LG27UL500W dump for me ... ?
Vielen Dank
& best regards,
Juergen
-
I can't help, but can you upload your flash dump? There may be a checksum which validates the contents.
-
Some dumps I got from here.
It seem to be a common fault, it might work after flashing, but better replace the flash IC!
-
Many thanks,
actually the dump all have different checksums and they are not accepted by the RPI Flasher.
This reminds me a bit of my corruppted Flash. There I got with every read procedure another checksum.
I will look into more details tomorrow.
best regards,
Juergen -
Yes, I had to replace the flash, as the original is not programable anymore.
I tested with an 27ul650 - but there is something different, now it beeps after power on and does as if it is an monitor but shows no picture.
thanks again,
Juergen -
I merged those 4 bad dumps by bitwise AND-ing their contents. The assumption is that bad bits flip from 0 to 1 (1 = erased state). Perhaps you'll get lucky.
-
actually the dump all have different checksums and they are not accepted by the RPI Flasher.
This reminds me a bit of my corruppted Flash. There I got with every read procedure another checksum.
Did you save those reads? If so, then it may be possible to build a "hybrid" flash image by combining all your dumps.
As for the RPI flasher (Raspberry PI?), I can't see why it would refuse to accept your dumps. The RPI has no way of knowing whether the checksum is wrong, or whether there is any checksum at all. -
thanks. I will try tomorrow. The point is, I am using the Python script to read and write. This makes a CRC check before upload on each block. My incircuit programmer can't programm in the videoboard. and Desoldering plus soldering again is a bit of work. But finally I may have to do it again.
cherio -
Those other dumps report differences in a small area of the SPI flash. If your flash has problems in a different area, and if the contents are from the same firmware version, then it may be possible to build a functional Frankenstein.
If you upload your 27ul650 dump, that may be a useful point of reference, at least for calculating the checksum, if it exists.Code: [Select]C:\>fc /b dumpmerg.bin dump.bin
Comparing files dumpmerg.bin and DUMP.BIN
003FC0D7: 01 05
003FC0E7: 00 40
003FF865: A2 A3
C:\>fc /b dumpmerg.bin dump1.bin
Comparing files dumpmerg.bin and DUMP1.BIN
003FC034: 32 B2
003FC062: 64 6C
003FC0C3: 00 04
003FC0D1: 00 20
003FC0D7: 01 05
003FC0E7: 00 40
003FC833: F3 FB
003FF095: 32 72
003FF0E2: 02 12
003FF177: 64 74
003FF20A: 00 08
003FF253: 32 36
003FF260: 32 B2
C:\>fc /b dumpmerg.bin dump2.bin
Comparing files dumpmerg.bin and DUMP2.BIN
003FC062: 64 6C
003FC0A9: 01 81
003FC0C3: 00 04
003FC0E7: 00 40
003FF260: 32 B2
C:\>fc /b dumpmerg.bin dump3.bin
Comparing files dumpmerg.bin and DUMP3.BIN
003FC03F: 32 3A
003FC041: 32 33
003FF20A: 00 08
003FF260: 32 B2
I notice that the range from 0 to 0x6350 has the same content as 0x10000 - 0x16350, 0x20000 - 0x26350 ... 0x190000 - 0x196350. That is, this same large block of data is repeated 26 times. This seems very wasteful (0x6351 x 26 = 661050 bytes).
The last 0x100 bytes of every 0x10000-byte block appear to be filled with 0xFF (up to offset 0x200000).
The range 0x3FC000 - 0x3FC0FF contains a block of data, possibly configuration information (0x64 = 100, 0x32 = 50). Very similar, possibly identical, blocks occur at 0x3FF000 - 0x3FF0FF, 0x3FF100 - 0x3FF1FF, 0x3F200 - 0x3FF2FF.Code: [Select]Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
003FC000 00 00 02 00 00 00 00 00 00 00 00 00 0C 0C 0C 0C
003FC010 0C 0C 00 00 00 00 00 00 0D 0D 0D 0D 0D 0D 64 32
003FC020 32 32 64 32 32 32 64 32 32 32 64 32 32 32 64 32
003FC030 32 32 64 32 32 32 64 32 32 32 64 32 32 32 64 32
003FC040 32 32 64 32 32 32 64 33 32 32 64 32 32 32 64 32
003FC050 32 32 64 32 32 32 64 32 32 32 64 32 32 32 64 32
003FC060 32 32 64 32 32 32 46 46 23 64 64 64 23 1B 64 64
003FC070 64 64 64 2D 32 32 3C E4 64 64 64 64 64 64 1B 64
003FC080 64 64 64 64 46 46 46 46 46 32 32 32 02 03 03 02
003FC090 32 32 46 64 41 32 01 01 01 01 01 01 17 17 18 37
003FC0A0 17 17 00 00 00 00 00 00 00 01 00 00 00 32 80 80
003FC0B0 80 03 03 0E 32 32 32 32 B2 32 32 32 32 32 32 32
003FC0C0 32 32 32 00 01 00 00 01 01 03 03 03 03 00 0A 00
003FC0D0 00 00 02 03 00 00 01 01 00 00 00 00 01 00 00 02
003FC0E0 02 00 02 03 00 00 00 00 00 00 00 00 01 00 40 00
003FC0F0 10 00 00 00 00 00 00 01 01 01 01 04 00 00 A9 74
These areas are affected by bad bits. I suspect that the final 16-bit word in each block is some kind checksum.
There is a also this 0x90-byte block which has similar copies (not intended to be identical) at 0x3FF800 - 0x3FF88F and 0x3FF890 - 03FF91F.Code: [Select]Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
003FC800 B6 41 96 B6 B8 AC BA B3 C1 B9 19 CB EE E2 F1 02
003FC810 F0 E8 E9 41 D1 E0 F1 01 F0 E8 F1 07 F0 E5 ED F1
003FC820 11 01 02 0C 0B F4 79 F3 CC F0 41 F4 70 F2 74 C2
003FC830 0B F4 78 F3 CC F0 41 F4 6F F2 74 C2 0A F1 A5 A8
003FC840 E3 E5 F0 41 F2 CA C2 09 F4 A3 CA F0 41 F5 7F F4
003FC850 B8 10 F1 53 62 5A 60 F0 41 F5 C1 C9 F1 61 F6 38
003FC860 F1 4E 00 FF 86 A2 FF 86 B4 FF 86 C3 FF 86 D4 FF
003FC870 86 E8 FF 86 FB FF 87 07 FF 87 1C FF 87 2E FF 87
003FC880 40 FF 87 50 FF 87 69 FF 87 7A FF 87 94 FF 59 74 -
I have read that sometimes heating bad flash can at least temporarily give a good read; this is in the context of NAND flash for mass storage, but maybe the same physical processes are responsible and could apply to your case.
-
First of all, I want to thank you for the time invested.
Unfortunately are all the files not passing the upload program's CRC check.
However, I hope to have soon access to a 27UL500 - and be able to dump the flash with my Raspberry Pi (RPI) via the HDMI cable.
Regarding the content of the files - it could be that not all of the memory is used - and that these dumps would work, even though the CRC is failing.
For the time being, I will wait for the download and try then this to upload.
best regards,
Juergen
-
If someone is looking for the datasheet ...
https://datasheetspdf.com/pdf-down/R/T/D/RTD2525-Realtek.pdfQuoteCRC function = X^24 + X^7 + X^2 + X + 1
Edit: Wrong chip (should be RTD2595, not RTD2525/2545/2555), but maybe the CRC algorithm is the same.
-
For the time being, I will wait for the download and try then this to upload.
Yes, I agree. I would be very keen to examine a working flash dump.
ISTM that the firmware is incredibly stupid in the way that it wastes so much space. It would be much smarter to devote just a tiny bit of that wasted space to ECC bytes so that errors could be transparently corrected, and then those deteriorating blocks could be refreshed with the corrected data. Moreover, there is more than enough free space to back up the code regions, so I'm baffled as to why only half of the code has redundant copies. And why did the programmer choose to make 26 of these copies???
It makes no sense to me at all. -
A very cheap ch341 can program 25Qxx just fine, why bother with something else via realtek cpu ? Maybe that's the problem.
Also I am sure that are ways to program directly the spi flash if you wish with raspberry pi ( never tried tough ). Simpler ways are best. Of course, the flash chip must be desodered or use a new chip not mounted on the board. -
I have worked out the checksum for each of those data blocks.
The last byte is always 0x74, so this must be a marker byte.
The penultimate byte is an 8-bit checksum which is calculated by XOR-ing all the previous bytes.Code: [Select]Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
003FF200 00 00 02 00 00 00 00 00 00 00 00 00 0C 0C 0C 0C
003FF210 0C 0C 00 00 00 00 00 00 0D 0D 0D 0D 0D 0D 64 32
003FF220 32 32 64 32 32 32 64 32 32 32 64 32 32 32 64 32
003FF230 32 32 64 32 32 32 64 32 32 32 64 32 32 32 64 32
003FF240 32 32 64 32 32 32 64 32 32 32 64 32 32 32 64 32
003FF250 32 32 64 32 32 32 64 32 32 32 64 32 32 32 64 32
003FF260 32 32 64 32 32 32 46 46 23 64 64 64 23 1B 64 64
003FF270 64 64 64 2D 32 32 3C 64 64 64 64 64 64 64 1B 64
003FF280 64 64 64 64 46 46 46 46 46 32 32 32 02 03 03 02
003FF290 32 32 46 64 41 32 01 01 01 01 01 01 17 17 18 17
003FF2A0 17 17 00 00 00 00 00 00 00 01 00 00 00 32 80 80
003FF2B0 80 03 03 0E 32 32 32 32 32 32 32 32 32 32 32 32
003FF2C0 32 32 32 00 00 00 00 01 01 03 03 03 03 00 0A 00
003FF2D0 00 00 02 03 00 00 01 01 00 00 00 00 01 00 00 02
003FF2E0 00 02 02 03 00 00 00 00 00 00 00 00 01 00 00 00
003FF2F0 11 00 00 00 00 00 00 01 01 01 01 04 FF FF A9 74
^^ ==
XOR8 checksum byte 0x74 = marker byte
Several blocks in the merged dump still have errors. The table shows the expected and actual checksums of each block.Code: [Select]range act / exp
------------- -----------
3FC000_FE.bin - 0xC8 0xA9 bad
3FC800_8E.bin - 0x59 0x59 good
3FF000_FE.bin - 0xA3 0xA9 bad
3FF100_FE.bin - 0xA8 0xA8 good
3FF200_FE.bin - 0xA9 0xA9 good
3FF800_8E.bin - 0x4B 0x59 bad
3FF890_8E.bin - 0x37 0x37 good
I think these blocks can be repaired. Let me know if you would like me to try.
I have attached my checksum calculator tool and my bitwise AND-ing tool. Both run inside a Windows DOS box.
-
I think these blocks can be repaired. Let me know if you would like me to try.
Done. -
Hello,
thanks for the support again. I flashed another SPI IC - and soldered it into the board, which switches on backlight, it beeps short - the LED is on , but no picture -
I will give it another shot in a few days, but currently it is bothering me too much. :-)
BTW, using the RPI was only because it is very handy to just go and read the flash just only with the HDMI cable. Non-destructive.
Later I did it with desoldering and so on - but the PCB is not becoming better by every desoldering/soldering.
saludos
-
I flashed another SPI IC - ,,,
Could we see the dump? So far you haven't uploaded anything. -
I do see a kind of problem downloading via Python & HDMI from a good monitor - as I can not desolder the flash.
Four times downloaded - for times a different CRC checksums :-(
I am still investigating.
bare with me.
best regards,
Jürgen
-
All,
first of all I succeeded finally.
The method was using an RPI , HDMI and lift write protect PIN3 of the flash and connect via pullup to 3.3V. So I was able to write back. The python script seems not to do the software write enable right.
Why it didn't work with an external flasher and the same bin file - I don't know and I can't explain. Eventually the reason I decided to go for the lifted Pin of the IC was that I was tired of soldering/desoldering.
However, what I found out, is that the monitor is writing always something back to the flash - in the upper region at 3ff000 and up.
That is the reason why the CRC of the files is different every time you read it. Maybe a hour counter ?
Thanks again
cheerio
Juergen