The software environment

These sets are multiprocessor, just not SMP. There are two microprocessors,
an 8-bit 8051 variant and a 32-bit MIPS.  There are also a lot of DSP
co-processors.

The following is a best guess.  Corrections welcome.

On application of power the only CPU that begins execution is the MIPS.
It loads something from a small SPI serial flash chip and executes it.
That is smart enough to enable the larger NAND Flash and starts U-Boot.
If you don't press the ESC key on the serial port it will by default
boot up by loading the kernel and lgapp partitions into memory
and booting Linux.

During the early startup for Linux it initializes the 8051/MICOM CPU.
If it see that the 8051 isn't running it loads it's firmware into it's
RAM.  Somewhere there is a persistent bit that records whether the set
is supposed to be ON or OFF.  That is examined as soon as the 8051 is
loaded and it's clock is enabled.

If the set should be OFF the MIPS processor
commands the 8051 to cut power to everything except the 8051, keyboard
and IR sensor.  From here the MICOM is in sole control, watching for
a wakeup event.  When it sees one it simply resets the MIPS cpu
which begins a full boot process again.

Only five events will awake the main processor.  The hard power
button, POWER or POWER_ON on the IR port, a timed wakeup or a
CEC power on event over HDMI.

If Linux boots and the set should be ON it will continue past
initializing the MICOM and finish initializing all of the custom
hardware.  Then it does what Linux always does at the end of the
boot process, it forks init/process 1.

This brings us to examining the userspace environment.
The rootfs partition is a squashfs partition with exactly one binary
plus a few scripts, some text file and a hard coded /dev tree.

The one binary is a staticly linked copy of busybox which is symlinked
to appear to be thirty five commands.

The entire software that runs the set is inside one huge executable,
the contents of the lgapp partition that gets loaded into ram by
U-Boot and mounted as an xipfs (Execute in place filesystem).  Since
it is staticly linked to the LGPL licensed uclibc library some users
have managed to get the .o files from LG but that is probably as far
as we will get to knowing what goes on in RELEASE.

There are some other mount points with interesting things though:

/mnt/lg/model
	A jffs filesystem. The only contents is RELEASE.cfg.  It has the
	gritty details on the hardware in your set and which features are
	supposed to be enabled.  It looks like the purpose is that a
	firmware upgrade doesn't touch this partition so it will
	still be there to reinitialize things.

/mnt/lg/res
	A top level directory with three more mountpoints.

/mnt/lg/res/emanual
	The not so useful built in manual.

/mnt/lg/res/ezcal
	The test patterns used by the EZ-Calibration and the two
	expert test patterns.

/mnt/lg/res/lgres
	This looks like a big ol archive of some undocumented sort
	with all of the artwork.  Figure it out and retheming the
	entire look of the set is possible.

/mnt/lg/recdb
/mnt/lg/user
	These are jffs formated partitions that get mounted but do
	not appear to have anything in them on a shipping set.

/tmp
/lgsw
	These are ramfs (i.e. ramdisks) mounted up at boot.  /tmp
	makes sense to avoid excessive writing to the flash.

/mnt/usb1
	When you put a USB stick in, this is where it goes.  Specifically
	it will get mounted to /mnt/usb1/Drive1 unless you have a hub.