What you do with this information is your own responsibility. If you brick your TV trying this, it's not my fault. You should probably have some electronics experience if you want to attempt this.
This is going to involve opening your TV and attaching wires to the pins of an integrated circuit. If you're not comfortable with that, this is not for you.
This document is a work in progress.
LG TVs since at least the era of NetCast and "Global Platform" (webOS predecessors) have had the notion of a debug level, generally called "debugstatus". There are three modes: DEBUG, EVENT, and RELEASE. TVs normally operate in RELEASE mode. DEBUG mode enables a variety of logging and other debugging features in webOS, including access to the bootloader console and debug menus via serial. EVENT is similar to DEBUG, although it may not enable as much logging and has other relatively minor differences.
In older versions of webOS, debugstatus is stored in what LG calls "NVM" alongside a bunch of other configuration data, such as the baud rate for serial communications. You can find the relevant structures and enumerations in LG's GPL packages. Of note:
-
debugstatus on webOS:
DEBUGis 3,EVENTis 4, andRELEASEis 5debug level value (webOS) value (NetCast/GP) DEBUG_LEVEL3 0 EVENT_LEVEL4 1 RELEASE_LEVEL5 2 From
lg_modeldef.h -
baud rate: 2400 is 0, 9600 is 2, 115200 is 7
baud rate value 2400 0 4800 1 9600 2 14400 3 19200 4 38400 5 57600 6 115200 7 460800 8 SYS_BAUDRATE_Tfromcmnio_type.h
Although I've seen a default baud rate of 115200 in bootloader code, in practice the default seems to be 9600.
In all the cases I've encountered on webOS, debugstatus is a single byte at offset 0x1a1 in NVM. I'll use 0x1a1 throughout this document, but it may be different for your model. The best way of determining the correct offset is reverse engineering your bootloader (or programs that access NVM such as RELEASE), but the GPL package for your TV model should also provide the necessary information (except for LX SoCs, since lxboot is not open source). After dumping the contents of the EEPROM, you should verify that the structure matches your expectations.
Before webOS 5 (released on 2020 models), LG stored NVM in an I²C EEPROM IC. NVM is entirely unencrypted on webOS 3.5 (2017) models. In webOS 4.0 (2018), LG started encrypting debugstatus in NVM, although other config settings remained accessible. In webOS 4.5 (2019), they attempted to obfuscate debugstatus a bit by calling it "Doption". With webOS 5 (2020), NVM was removed and replaced by "bootdb", which is stored in an encrypted eMMC partition named dbboot.
The ICs I've seen being used for NVM are usually 256Kbit (32Kbyte) in SO-8 packages. Sometimes larger EEPROMs up to 1Mbit are used, but these seem to be mostly on less mainstream products. You may also find I²C EEPROM ICs (potentially smaller ones like 24C08 or 24C02) for HDMI stuff (EDID), which are not relevant here.
A "4G25" marking (with a lot number underneath) indicates a Rohm BR24G256F-3 (datasheet). (There is also a -5 part supporting 1MHz operation and more write cycles that LG sometimes uses in more recent models. The differences shouldn't matter here.)
The NVM EEPROM IC on a 43LJ5500-UA board (webOS 3.5; 2017; MStar M2R SoC) marked 4G25.
The Fremont Micro Devices (FMD) FT24C256A-ESR (datasheet) is commonly used for NVM. It is marked "FT24C256A".
The AN-WL100W main board stores NVM on a 1Mbit STMicroelectronics M24M01 (datasheet) EEPROM marked "24H01RP".
The AT24C256C I²C EEPROM from Microchip (formerly Atmel) often appears in schematics as an alternative to the Rohm part, and I have seen it on non-webOS boards. Like the others, it's in an SOIC-8 package. The key markings for identifying it are a first line starting with ATML (usually ATMLH followed by three numbers forming a date code) and a second line starting with 2EC. See the datasheet for more information on the markings.
You'll need a test clip unless you want to solder wires directly to the EEPROM IC's leads or otherwise find a way to connect to the I²C bus. Mini-grabbers (random example) may work. The I²C bus may be brought out to an unpopulated connector footprint (or, if you're really lucky, an actual connector) somewhere. There are other devices on the board that use I²C, but I don't know whether they're on the same bus.
A SOIC-8/SOP-8 test clip, such as the Pomona 5250, fits over the IC and provides easy access to the pins. Note that there are much cheaper generic test clips available from the usual sources (e.g., eBay, Amazon, AliExpress).
A cheap test clip on the NVM EEPROM IC of a 43LJ5500-UA board.
Any device that speaks I²C can potentially work. For example, a board based on the WCH CH341A or FTDI FT2232H (e.g., FT2232H Mini-Module) should work. An FT232H-based board can work, but note that the pre-2020 version of the Adafruit FT232H Breakout only has a 5V power output pin (see Notes below), although the I/O voltage should be fine. A Bus Pirate should theoretically work, although I had trouble with a Bus Pirate v4; I was able to detect the EEPROM and dump its contents, but the data was corrupted. I switched to using a Raspberry Pi 3 (Model B+), which gave me fewer problems, and ultimately allowed me to sucessfully change debugstatus. I used pins 3 and 5 of the 40-pin header, which are SDA and SCL, respectively. These pins correspond to /dev/i2c-1 in Linux by default.
Once you have DEBUG, you'll need a way to communicate with one of the TV's serial interfaces: RS-232 on a DE-9 connector or 3.5mm jack (if present), a 3.3V UART, or USB to serial adapter. If you are using a PC, you can accomplish this with a USB to serial adapter. If you're going to use the UART, make sure your adapter is configured to use 3.3V. If you are using something like a Raspberry Pi, you may be able to connect directly to its UART pins, although I haven't tried this. If you want to go the USB to serial route on the TV side, you may need two USB to serial adapters, at least one of which is PL2303-based.
While the EEPROM ICs themselves will tolerate 5V, you'll be backpowering parts of the board that are expecting 3.3V, so make sure your I²C adapter uses 3.3V.
I²C is pretty tolerant of less-than-ideal connections, especially at the lower speeds in use here.
Apparently at least some models can boot with an invalid or entirely missing NVM EEPROM. (As far as debugstatus goes, it'll default to RELEASE.)
The general idea is to attach a test clip to the EEPROM IC and use some I²C master device to access it. Then you should:
- Back up contents of EEPROM. (You may want to do this multiple times and make sure you always get the same result.)
- Make sure the value at offset 0x1a1 is 5. (If it's not, and you're sure you dumped the EEPROM correctly, I'd like to hear about it.)
- Write 3 to 0x1a1.
- Read the contents of EEPROM.
- Make sure everything is the same as before except the byte at 0x1a1 being 3 instead of 5.
First, you should check that you have DEBUG. You should see this in the Instart menu:
There are several ways to launch the Instart menu. The intended method is probably via IR (e.g., with a service remote or IR blaster), but you can also use a Luna request. My super hacky SSAP client can send the necessary request. This predefined request should work on webOS 3.0+:
The password is almost certainly 0413.
You can use the Instart menu to enable serial access: in System 1 set Baudrate to something sensible (like 115200), and in System 2, set RS-232C Control to On.
After enabling serial access, you'll need to connect to a serial port. The baud rate will be what you set earlier. Some models have RS-232 on a DE-9 connector, which may work, but most will have a 3.3V UART edge connector (and/or a UART on a 4-pin wafer connector). A potentially easier option is using two USB to serial adapters back-to-back, ultimately connecting from the TV's USB port to one on a PC. You can also connect from any of these options (except RS-232) to a Raspberry Pi via the appropriate pins in the P1 (GPIO) header.
You'll need to connect the GND, RX, and TX pins. (Don't connect anything to +3V3.) Connect the two GNDs first. The RX and TX pins should probably be swapped (i.e., RX on the TV to TX on your serial adapter and vice versa).
The pinout of the edge connector is:
- +3V3
- RX
- GND
- TX
UART edge connector.
On the boards I've seen, each data line has a 100Ω series resistor providing a bit of protection, but after that they probably run straight to the SoC, so be careful. The RX line is pulled up to 3.3V with a 10kΩ resistor.
The dimensions of the edge connector happen to match those of a SOIC-8 test clip. With a bit of padding (such as cardboard) underneath the board, a test clip will stay on well enough. If you can't get that to work, it's possible to solder wires to the test pads on the bottom of the board. There's usually a group of four with the same signals as the edge connector somewhere nearby. I'm not sure how they're arranged, so check what pin each one corresponds to with a multimeter.
You can also use a USB to serial device in one of the TV's USB ports, although only certain types will work. Your best bet is a PL2303-based adapter. Some LG TVs have been known to specifically check for an Aten UC232A, but I haven't had any problems with generic (even possibly counterfeit) PL2303 devices.
Using a USB to serial adapter connected to the TV means you'll likely need another one to connect to your PC. Make sure you remember to swap TX and RX: TX on one goes to RX on the other. Connect the GND pins, but don't connect the VCC/+3V3 pins.
NOTE: Some LX SoCs prohibit access to certain debug menu commands—including those that open a shell—without AccessUSB authentication. I've also encountered this on an MStar LM15U signage board. These restrictions may be more common on signage (and other commercial) models. There are likely workarounds, but I'm currently unable to help with this.
From the serial debug menu you can spawn a root shell. Press F9 to open the menu, and use the sh command to start the shell. (On newer models, you may just have to press s for shell access. You can usually press h for a list of available keys.)
Once you have the root shell, you need to use it to achieve persistent root access. First, force-enable dev mode by creating a directory named /var/luna/preferences/devmode_enabled. You may have to remove the existing file with that name. Make sure the LG Developer Mode app is uninstalled, or it will cause problems. Once you've created the devmode_enabled directory, reboot so that processes such as the app installer know that dev mode is enabled.
With dev mode enabled, you can install Homebrew Channel. Use the following commands to download and install it:
curl -L -o /home/root/hb.ipk https://github.com/webosbrew/webos-homebrew-channel/releases/download/v0.6.3/org.webosbrew.hbchannel_0.6.3_all.ipk
luna-send-pub -i 'luna://com.webos.appInstallService/dev/install' '{"id":"com.ares.defaultName","ipkUrl":"/home/root/hb.ipk","subscribe":true}'
You'll have to terminate luna-send-pub with control+C when it's done.
Once Homebrew Channel is installed, run its elevation script from the root shell:
/media/developer/apps/usr/palm/services/org.webosbrew.hbchannel.service/elevate-service
General information about Homebrew Channel and root can be found in my crashd guide.
I recommend you block updates using the Homebrew Channel settings (although this is not totally effective). I also prefer to disable telnet, enable SSH, and set up an SSH key.
Remember that on NetCast and Global Platform, DEBUG is 0 and RELEASE is 2, so you'd be changing 2 to 0.
The board in the AN-WL100W wireless transmitter box has an MStar Saturn7 SoC that runs Global Platform 2 (GP2). The general structure of NVM data is similar to more modern models, but it includes fewer fields. (However, it is on a 1 megabit EEPROM, which probably means it stores unknown other data.) There doesn't seem to be a baud rate setting in NVM. Its debugstatus byte appears to be at offset 0x185, and would be changed from 2 to 0 for DEBUG. I still haven't been able to get any further access, though.
- NXP UM10204: I²C-bus specification and user manual (Rev. 6, 4 April 2014) — I²C specification
- Philips AN10216-01: I²C Manual (March 24, 2003) — Introduction to I²C, with some history and context
- Linux I²C
/devinterface intro — Brief overview of how to use the/dev/i2c-Xinterface on Linux - webOS Homebrew Project — Information about using and developing for webOS in ways LG didn't intend
Oh... So I have USB to TTL from a project awhile back. This one to be exact: https://a.co/d/39LgUJ6. This should work, right? I just ordered the test clip from Digikey.