It looks like today is going to be a blog-heavy day – I’ve got quite a few things to “get off my chest”, so forgive me if posts start crossing over one-another in the future. Time and motivation for these sorts of things seldom arrives at the same time, so I better “strike while the iron is hot”.
This week, in a trip to my uni to see my supervisors, I stopped by a colleague’s office and saw a pile of monitors of unknown status and of various vintages. There was one particular HP Compaq LA2206x sitting in the pile, the exact same monitor that sits at my university workstation. To me, this monitor was a fairly nice model – LED backlight, full HD screen, 21.5″ size with a height, angle and pivot adjustable stand. Curiously, this monitor was marked as “dead”, and after a quick test, it really didn’t want to power up even with a valid video signal. After confirming that it was destined for the scrap-heap, I decided to ask if I could take it apart, salvage some parts and figure out what was wrong.
The Bits and Pieces
After being granted permission to take it to bits, I began my work with two screwdrivers and my fingers. I had no intention of lugging the whole panel home, but I could probably handle the circuit boards. The exterior plastic fascia was completely screw-less, and a flat-blade driver and fingers were enough to take that apart. Internally, there was some aluminium tape holding bits together and a few Phillips screws. The panel was an LG TN panel, but I didn’t note down the model number. According to the approvals label, the unit appears to be OEMed by Chi Mei in China.
The first suspect of a monitor that doesn’t power up is the power supply.
A quick glance at the unit revealed no obvious faults. No smells, no charring, no signs of distress. The power supply has a module tacked onto the left side which appears to be the LCD backlight driver (LED) and another stand-up module which probably contains the main PSU controller. Everything is nicely spaced out on the board, and all the dubious Su’scon caps still visually looked okay. The PCB is dated Week 45 of 2011, with the top side having some silkscreened component label text. The power supply is an ILPI-263 V.A, with the LED drive board marked ILTR-108 V.A.
The underside has solder resist and some good silkscreened component outlines. There is ample separation between primary and secondary, with many anti-tracking slots and even a spark gap visible on the primary side inductor. All joints looked good.
Seeing no obvious failures, I probed around further at home. While I didn’t de-populate the board, I did verify that the primary side fuse, thermistor, bridge rectifier were all operating correctly, and the MOSFETs, diode rectifiers, optoisolator and secondary side fuses were all intact. There’s a good chance there is no failure in the power supply at all.
The next board in for inspection is the scaler board (marked ILIF-257 V.A). This board is dated Week 48 of 2011. This board basically houses the “brain” of the monitor, connecting with the front panel, controlling the operation of the backlight and LCD, and most importantly, taking any valid input signal and converting it to the fixed-resolution and fixed-refresh rate of the LVDS output needed to drive the TCON board and the LCD panel. The whole operation is orchestrated by a Mstar TSUMP58KHT purpose-made chip. There is also an NEC 720114 to drive the two USB hub ports.
More astute eyes will see that I have cut a trace near U110 – more on this later. But aside from the chips above, there is U104, U105, U108 and U110 which are the EDID/DisplayID EEPROMs and the firmware flash for the monitor itself. The EDID is used by a video card to identify the connected monitor and its capabilities, and is standardized by VESA. It uses an I2C protocol over the DDC bus to read out the data and configure the video card appropriately. This was needed as earlier more primitive approaches used reserved VGA lines to indicate support for certain modes, but the monitors quickly outgrew the system and earlier CRT monitors could be damaged if sent modes above their capabilities. For Displayport, a newer DisplayID system is used which is more “efficient” and extensible than the EDID system.
On the whole, the board looked okay, save for the very oxidised looking solder joints and insufficient heat near the Displayport connector anchors (bottom right). A failure of the scaler SoC or the firmware could render the monitor inoperable, even if unlikely.
The other thing I took out of it were the two USB A ports for the hub output ports. These cards are often very useful if you’re building your own USB charger or something like that – quality connectors really make a difference for higher current operation. If nothing else, this would be my consolation prize.
What I left behind were the front panel button PCB – a very basic PCB with a few small switches on it, and the LCD panel assembly with its TCON board, matrix and backlight assembly. I didn’t feel the button PCB was worth my time, and the LCD panel was too bulky. That being said, as there aren’t obvious sources of failure in these parts, it could well be possible that there were failures in the other parts that may have led to the demise of the monitor. In the worst case, it could have been a failure of the front panel button itself meaning the board never got the command to power up, a short in the LCD panel TCON board/scaler board/bad scaler IC causing the power supply to trip-out. The absolute cause of the dead monitor remains a mystery – there are no plans for reassembly.
The Fun Part: The EEPROMs/flash
With the parts above, an obvious source of fun would be to examine the EEPROMs and flash. I’ve never delved into the data stored in a monitor, so it would be nice to find out something in the process. In order to do this, I used the same CH341 and clip mechanism as used in the BIOS whitelist modifications. After all of the “fun”, I’ll probably just heat up the boards, pluck the ROMs off the board, salvage some through-hole components and junk it.
Anyway, here is the archive of all the dumped data, consisting of U104 (24C02), U105 (24C02), U108 (24C16) and U110 (MX25L2026).
U104 and U105 are both EDID ROMs. They contain the EDID data and some blank space at the end. The EDID data includes things like the model, the hardware manufacturer ID, product code, serial number, manufacture date and monitor-specific timing information. The raw EDID data is as follows:
U104: 00 FF FF FF FF FF FF 00 22 F0 47 29 01 01 01 01 31 15 01 03 80 30 1B 78 2E 95 25 A1 59 57 9F 27 0D 50 54 A1 08 00 81 C0 81 80 95 00 B3 00 D1 C0 01 01 01 01 01 01 02 3A 80 18 71 38 2D 40 58 2C 45 00 DC 0C 11 00 00 1E 00 00 00 FD 00 32 4C 18 5E 11 00 0A 20 20 20 20 20 20 00 00 00 FC 00 48 50 20 4C 41 32 32 30 36 0A 20 20 20 00 00 00 FF 00 33 43 51 31 34 39 4E 43 38 4D 0A 20 20 00 AA U105: 00 FF FF FF FF FF FF 00 22 F0 48 29 01 01 01 01 31 15 01 03 68 30 1B 78 2E 95 25 A1 59 57 9F 27 0D 50 54 A1 08 00 81 C0 81 80 95 00 B3 00 D1 C0 01 01 01 01 01 01 02 3A 80 18 71 38 2D 40 58 2C 45 00 DC 0C 11 00 00 1E 00 00 00 FD 00 32 4C 18 5E 14 00 0A 20 20 20 20 20 20 00 00 00 FC 00 48 50 20 4C 41 32 32 30 36 0A 20 20 20 00 00 00 FF 00 33 43 51 31 34 39 4E 43 38 4D 0A 20 20 00 BE
The difference between the two EDIDs are only a few bytes:
Differences: A: 47 48 [product-code] 14: 80 68 [digital input vs. analog input] 51: 11 14 [descriptor 2 (unused?)] 7F: AA BE [checksum]
Thanks to edidreader, you can decode the EDID and find out what it means. The one below is for U104 (digital DVI).
Header Information Valid Checksum: TRUE EDID Header: OK EISA ID: HWP Product Code: 2947 Serial Number: 16843009 Manufacture Date: 49/2011 EDID Version: 1.3 Number of Extensions: 0 Checksum: 0xAA Basic Display Parameters Digital Input DPMS Active-Off Display Type: RGB 4:4:4 + YCrCb 4:4:4 Standard sRGB Color Space Preferred Timing Mode Chromaticity Coordinates Red X: 0.631 Red Y: 0.349 Green X: 0.341 Green Y: 0.622 Blue X: 0.152 Blue Y: 0.053 White X: 0.313 White Y: 0.329 Timing Bitmap 720×400 @ 70 Hz 640×480 @ 60 Hz 800×600 @ 60 Hz 1024×768 @ 60 Hz Standard Display Modes X Resolution: 1280 X:Y Pixel Ratio: 16:9 Vertical Frequency: 60 X Resolution: 1280 X:Y Pixel Ratio: 5:4 Vertical Frequency: 60 X Resolution: 1440 X:Y Pixel Ratio: 16:10 Vertical Frequency: 60 X Resolution: 1680 X:Y Pixel Ratio: 16:10 Vertical Frequency: 60 X Resolution: 1920 X:Y Pixel Ratio: 16:9 Vertical Frequency: 60 Detailed Timing Descriptor Pixel Clock: 148.5MHz Horizontal Active: 1920 Horizontal Blanking: 280 Vertical Active: 1080 Vertical Blanking: 45 Horizontal Sync Offset: 88 Horizontal Sync Pulse: 44 Vertical Sync Offset: 4 Vertical Sync Pulse: 5 Horizontal Display Size: 476 Vertical Display Size: 268 Horizontal Border: 0 Vertical Border: 0 Interlaced: false Stereo Mode: 0 Sync Type: 3 2-Way Line-Interleaved Stereo: false
U108 has a larger EEPROM, and contains the DisplayID data used by the Displayport. As I don’t have any knowledge about the format of the ROM, I didn’t explore any further, but it is different to (and more sophisticated compared to) the EDID data. It does, however, have a valid EDID header at 0x500.
00 FF FF FF FF FF FF 00 22 F0 46 29 01 01 01 01 31 15 01 04 A5 30 1B 78 26 95 25 A1 59 57 9F 27 0D 50 54 A1 08 00 81 C0 81 80 95 00 B3 00 D1 C0 01 01 01 01 01 01 02 3A 80 18 71 38 2D 40 58 2C 45 00 DC 0C 11 00 00 1E 00 00 00 FD 00 32 4C 18 5E 11 00 0A 20 20 20 20 20 20 00 00 00 FC 00 48 50 20 4C 41 32 32 30 36 0A 20 20 20 00 00 00 FF 00 33 43 51 31 34 39 4E 43 38 4D 0A 20 20 00 8D
The differences, compared to U104, are:
A: 46 47 [product-code] 13: 04 03 [EDID revision (newer)] 14: A5 80 [digital input exploiting reserved?] 18: 26 2E [supported features] 7F: 8D AA [checksum]
This is an interesting EDID, as byte 0x14 (20) has bits set 0b10100101, where the EDID 1.3 standard seems to say if the leading bit (digital input) is set, the rest must be zero (as in U104). This is different because this EDID is a version 1.4 EDID. Another difference is in byte 0x18 (24) where the supported features is RGB 4:4:4 + YCrCb 4:4:4 (0b00101110) for the DVI input, but the Displayport claims RGB 4:4:4 (0b00100110).
As it turns out for both EEPROMs, they were erasable just by clipping onto them and using the CH341 programmer “in place”, so it’s probably possible for you to reprogram your own EDIDs for your displays this way – unless the firmware interferes with it.
I’ve never seen a monitor firmware, but I suppose there’s always time for a first. It wasn’t as big as expected, and it probably contains the boot-up logo image amongst other things, but I couldn’t decypher it (it might be RLE stored in a particular scheme with no headers). I suppose a “bad” monitor firmware could ruin your day, and make a monitor “untrustworthy”, but it seems that this chip was just fine and the firmware was read out after the Vcc pin was cut as the power draw from the rest of the board meant the programmer wouldn’t work. The firmware chip also appeared to have code protection so it could not be erased or rewritten without sending an unlock command first – something the CH341 programmer software I have didn’t seem to be able to do.
An image showing the bits as pixels shows there are many spaces with white (0xFF) unprogrammed areas, and some periodicity patterns in the data (maybe a character bitmap for the OSD display, although I didn’t delve further). Looking at the text strings inside the firmware was somewhat interesting.
There seemed to be some interesting declarations and lists of commands. I’m not sure what it’s used for, but there’s also mswhql suggesting it’s a Microsoft Windows Hardware Quality Logo program compliance requirement perhaps?
Another section seems to give away the information about the expected connected LCD panel – I think it’s right – the LG Display LM215WF4.
Rather unusually, within the firmware itself, there is a valid EDID, but it’s an EDID for another model of monitor that’s also used at the university. This one is for the older LA2205wg, an 1650×1080 22″ monitor. Decoding this EDID using edidreader showed that it was for that monitor:
Header Information Valid Checksum: TRUE EDID Header: OK EISA ID: HWP Product Code: 2849 Serial Number: 16843009 Manufacture Date: 12/2008 EDID Version: 1.4 Number of Extensions: 0 Checksum: 0x35 Basic Display Parameters Digital Input Compatible with VESA DFP Maximum Horizontal Image Size: 47 Maximum Vertical Image Size: 30 Display Gamma: 2.20 DPMS Standby DPMS Suspend DPMS Active-Off Display Type: RGB 4:4:4 Preferred Timing Mode Chromaticity Coordinates Red X: 0.641 Red Y: 0.335 Green X: 0.298 Green Y: 0.611 Blue X: 0.147 Blue Y: 0.070 White X: 0.313 White Y: 0.329 Timing Bitmap 720×400 @ 70 Hz 640×480 @ 60 Hz 800×600 @ 60 Hz 1024×768 @ 60 Hz Standard Display Modes X Resolution: 1280 X:Y Pixel Ratio: 4:3 Vertical Frequency: 60 X Resolution: 1280 X:Y Pixel Ratio: 5:4 Vertical Frequency: 60 X Resolution: 1440 X:Y Pixel Ratio: 16:10 Vertical Frequency: 60 X Resolution: 1600 X:Y Pixel Ratio: 4:3 Vertical Frequency: 60 X Resolution: 1680 X:Y Pixel Ratio: 16:10 Vertical Frequency: 60 Detailed Timing Descriptor Pixel Clock: 146.25MHz Horizontal Active: 1680 Horizontal Blanking: 560 Vertical Active: 1050 Vertical Blanking: 39 Horizontal Sync Offset: 104 Horizontal Sync Pulse: 176 Vertical Sync Offset: 3 Vertical Sync Pulse: 6 Horizontal Display Size: 473 Vertical Display Size: 296 Horizontal Border: 0 Vertical Border: 0 Interlaced: false Stereo Mode: 0 Sync Type: 3 2-Way Line-Interleaved Stereo: false
It seems that, despite the differences in exterior housing, both monitors probably share an identical scaler board and firmware. Maybe in some cases, an external EDID EEPROM might not be required, and the scaler SoC can provide the functionality? Or maybe it can recover corrupted EEPROMs internally? I have no idea why else an EDID would be stored into the firmware …
There is some text alluding to different modes and possibly configurations/service menu burn-in tests available. It seems like the chip is probably very versatile, and capable of running TVs with HDCP with audio as well based on the MPEG/AC-3/AAC audio strings.
It’s definitely an HP monitor when you can see the HP support URL in its firmware. This is probably for its OSD, maybe when showing things like self-test, or non-native resolution warnings.
Towards the end of the firmware, there is an array of multi-lingual text for different menu options. This is probably where all the strings are stored, with an offset depending on which language is chosen in the menu. There’s probably a lot more fun in the firmware, but I just don’t know about it.
A monitor failed at the uni, and was destined for the trash. Instead of letting it go there peacefully, I tore it apart and salvaged most of the boards inside. The cause of failure was not conclusively determined, and could have been a really minor “stupid” fault. Otherwise, it might have been something more complicated and non-obvious. Whatever the cause was, there was no intention of repair and reassembly.
Instead, I managed to examine the EDID and DisplayID EEPROMs, and the firmware flash chip and learn a little bit about them in the process. Afterwards, it was also a chance to salvage some more components for the junk box – after all, the EEPROMs can be useful for small data-logging purposes with MCUs to avoid wearing out its internal storage, or for replacing in other equipment (e.g. where optional EEPROMs have been left out).