In a previous post, I recounted my adventures with the Popcorn Hour C-200 media player. Having not given the device much thought since then, I recently decided to dust it off and see what it was really made of. This is what I found.
Components
The system is based on a Sigma Designs SMP8643 SoC, and information about this chip is notoriously hard to find. Even the product briefs for older chips have been purged from the Sigma website, but the Internet Archive has a copy. Most of the other parts used in the PCH C-200 have easily obtainable data sheets. A summary of the important chips follows.
| Part # | Function | Comments |
|---|---|---|
| Sigma Designs SMP8643 | SoC | |
| Nanya NT5TU64M16DG-3C | RAM | 4x 1Gb, 512MB total |
| Samsung K9F2G09UOA-PCBO | Flash | |
| Vitesse VSC8601 | Ethernet PHY | |
| RT-G19264B-O-P2 | LCD panel | Clone of Orient Display AMG19264C |
| MAX7325 | I2C I/O Expander | LCD panel interface |
| LM27966 | LED driver | LCD backlight |
| PIC16 | µC | Unmarked chip |
| Genesys Logic GL850G | USB hub | 4 ports |
| Richtek RT9712A | USB power switch | 2x for front and rear ports |
| Richtek RT9018A | Voltage regulator | HDMI PHY power |
| AKM AK4420ET | Audio DAC |
Connectors
The main PCB contains a number of connectors, some more interesting than others:
| ID | Name | Function |
|---|---|---|
| J1 | FIP | Connection to front panel |
| J7 | UART0 | |
| J8 | FRONT_USB | Connection to front panel USB |
| J10 | UART1 | |
| J12 | IR input | |
| J16 | Ethernet | |
| J20 | Wifi | |
| J24 | HDMI | |
| J26 | Component, composite, audio | |
| J32 | ATX | Power supply |
| J40 | SATA2 | |
| J41 | SATA1 | |
| J43 | Internal USB | |
| J46 | CPU_FAN | |
| J47 | BACK_FAN | |
| J69 | JTAG (unpopulated) | |
| J75 | S/PDIF | |
| J85 | Unpopulated, purpose unknown | |
| J86 | Misc I/O | |
| J87 | S-video | |
| J88 | Rear USB |
This diagram shows the location and, where relevant, pin numbering of the connectors.
J1 FIP
This connects with the front panel display and buttons. Despite being designated FIP in the PCB silkscreen, this is not the interface referred to as FIP in Sigma kernel sources. The signal names, silkscreened on the bottom of the PCB, are in relation to the front panel, thus RC_IN and RC_OUT appear reversed. The table below lists the connections of each pin to SoC/board functions. All signals are 5V.
| Pin | Name | Dir | Function |
|---|---|---|---|
| 1 | +5V | O | |
| 2 | GND | O | |
| 3 | 5VSTB | O | ATX standby power |
| 4 | GND | O | |
| 5 | RC_OUT | I/O | GPIO12, IR decoder |
| 6 | GND | O | |
| 7 | RC_IN | O | IR/RF remote output |
| 8 | REST | I | System reset |
| 9 | SDA | I/O | GPIO1, I2C data |
| 10 | SCL | I/O | GPIO0, I2C clock |
| 11 | STB_LED | I/O | GPIO9 |
| 12 | POW_ON | I | ATX PS_ON# |
| 13 | POW_ON_LED | I/O | GPIO8 |
| 14 | TEST |
J86
This connector provides the signals Sigma refers to as FIP, which is an interface intended for communication with a NEC uPD16311 VFD controller, sharing pins with some GPIOs. It is not used in the PCH C-200. The RC_IN signal from J1 is also duplicated here. All pins have 5V signal levels.
| Pin | Name | Dir | Function | |
|---|---|---|---|---|
| 1 | GND | O | ||
| 2 | RC_IN | O | IR/RF remote output | |
| 3 | CLK | I/O | FIP clock | GPIO5 |
| 4 | STB | I/O | FIP data strobe | GPIO4 |
| 5 | DATA | I/O | FIP data I/O | GPIO2/3 |
J7/10 UART0/1
Two UARTs are available on 10-pin headers. Only the RX and TX pins are connected. These pins can also be configured as GPIOs. The signals are 3.3V.
| Pin | Function | |
|---|---|---|
| 1 | +5V | |
| 5 | RX | UARTn_GPIO0 |
| 6 | TX | UARTn_GPIO4 |
| 10 | GND | |
J69 JTAG
This unpopulated connector provides a JTAG interface as well as UART0 RX/TX. The JTAG pins are shared with the UART1 modem control/status signals, the JTAG_UART1# pin selecting the functionality. When in UART mode, these pins can also be configured as GPIOs through software.
| Pin | Function | |
|---|---|---|
| 1 | GND | |
| 2 | JTAG_TRST# | UART1_DSR |
| 3 | JTAG_TDO | UART1_RTS |
| 4 | JTAG_TDI | UART1_DTR |
| 5 | JTAG_TMS | UART1_CTS |
| 6 | JTAG_UART1# | |
| 7 | JTAG_TCK | |
| 8 | UART0_RX | |
| 9 | RESET# | |
| 10 | UART0_TX | |
| 11 | +3.3V | |
| 12 | GND | |
| 13 | GND | |
| 14 | GND | |
| 15 | GND | |
| 16 | GND | |
Front panel
The front panel assembly contains a 192×64-pixel white/blue LCD module, a power button with integrated LED, 7 navigation buttons, and two USB ports. The latter attach to the main PCB through the J8 FRONT_USB connector, everything else through J1 FIP.
The LCD module is a Chinese clone of Orient Display AMG19264C, apparently manufactured by Shenzhen Goodview Electronic Technology Co. The control pins are driven by a MAX7325 I2C I/O expander, and the backlight is powered by an LM27966 LED driver, also controlled over I2C.
Button presses are handled by an unmarked PIC16 µC and sent on the RC_OUT pin encoded using the NEC IR protocol. The PIC16 also receives NEC-encoded remote control codes on the RC_IN pin, and sends any with the expected vendor address back over RC_OUT. NEC-format codes with a different vendor address are replaced with a repeat code. All other messages are ignored.
The POW_ON_LED pin simply controls a white LED within the power button. The STB_LED pin activates an amber LED, and also resets the MAX7325 and LM27966, switching off the backlight.
The SMP8643
Introduced in 2009, the SMP8643 is one in a family of chips targeted at Bluray and network media players. It contains the following main components and interfaces.
| CPU | MIPS 74kf 667MHz |
| Realtime processor (IPU) | MIPS 4KEc 333MHz |
| Security processor (XPU) | MIPS 4KEc 333MHz |
| DRAM | 2x DDR2 32-bit, 333MHz |
| SATA | 2x 1.5Gbps |
| Ethernet | 2x Gigabit |
| USB | Dual-port EHCI/OHCI |
| I2C | 2 masters, 1 slave |
| UART | 2x 16550-like |
| GPIO | Up to ~80 |
| Audio outputs | I2S, S/PDIF |
| Video outputs | HDMI 1.3a, component, S-video, composite |
| Other interfaces | NAND, SDIO, smartcard, IR, “FIP” |
CPU
The main CPU is a MIPS 74kf core with floating-point support and 32kB I/D caches. Although all documentation mentions a 667MHz clock frequency, it is actually running at 661.5MHz, which is the closest frequency the PLL can generate from a 27MHz reference.
IPU
The IPU, a MIPS 4KEc, is a coprocessor intended to run Sigma’s real-time kernel IOS. It’s main purpose is servicing interrupts from the graphics subsystem. In addition to the MIPS core, the IPU block contains an interrupt controller and two timers. While probably not officially supported, it is possible to run arbitrary code in privileged mode on this CPU.
XPU
The XPU, also a 4KEc, is responsible for booting and security-related tasks. Having exclusive access to some chip resources, it normally manages DRM functions including HDCP.
DRAM
The two DRAM controllers operating at half the CPU clock frequency can each address up to 512MB of memory. Unlike some other designs, they cannot be interleaved. Parts of the memory space is typically reserved for the IPU or XPU with limited access rights for other bus masters.
In the PCH C-200, each DRAM controller is fitted with 256MB memory. Access restrictions are applied to the RAM as per the table below.
| Address | CPU | IPU | XPU | |
|---|---|---|---|---|
| DRAM0 | 0x00000000 | RW | RW | RW |
| 0x0f2f8000 | – | RW | RW | |
| 0x0f300000 | – | R | RW | |
| 0x0f800000 | – | – | RW | |
| DRAM1 | 0x00000000 | RW | RW | RW |
| 0x0c000000 | R | RW | RW | |
| 0x0fff0000 | – | R | RW | |
| 0x0fffc000 | – | – | RW | |
GPIO
A primary GPIO block provides 16 pins, and through pin muxing with UARTs, Ethernet, and smartcard another approximately 70 pins (depending on chip variant) can be used as GPIO. Any four of the 16 primary pins can be configured to generate interrupts.
Booting
At system reset, only the XPU is active. Booting from on-chip ROM, it initialises itself and, later, the CPU and IPU. All code loaded to any processor must be cryptographically signed with chip-specific keys.
At the time of my initial investigation, I was told in no uncertain terms on the user forums, that running a custom kernel was not possible due the requirement of a signed image. I was, however, still able to run my own kernel using kexec. While this method satisfied my immediate needs, it has the double disadvantages of being slow as well as requiring manual intervention. I have since found a better way to boot directly into a custom kernel.
Getting to an interactive YAMON shell is as simple as writing the value zero to physical address 0x61950 and performing a warm reset. This gives the following output on UART0 (115200 8n1):
39idxfs696b15f57c540829defeeee9f4a092007337a124S #xos2P52-100 (sfla 128kbytes. subid 0x00/af) [serial#1c5c6b4e5d1a809db600a6828be131fa] xmb 0xb5 #chpll 0x01000024/0x00000201 -> 0x01000030/0x00000101... actual sys=330MHz #DRAM setup (method=0x10015858) ... #DRAM0 Window : 0x#21#24#20#24# (16) #DRAM1 Window : 0x#24#24#22#22# (17) #DRAM0 Settings: WD=0x0f0b0b0b RG=0x08080708 RR=0x08080708 RF=0x090a0a0b #DRAM1 Settings: WD=0x0b0c0b0b RG=0x08080808 RR=0x08080808 RF=0x0a0b0a0a #poisoned 131072 pages with 0x3954617a #step6 @0x0*** zxenv has been customized compared to build *** #step22 #ei sb!ntsb!ntsb!ntsb!ntsb!ntsb!ntsb!ntsb!ntsb!ntsb!nt CS 0 vendor id 0xec....... CS 0 device id 0xda....... ................................................................................................................................................................................................................................................................Main Management found doing Super block Sanity checks... location 4 doing Managment block Sanity checks ... CS 1 vendor id 0x00....... CS 1 device id 0x00....... ********************************** * YAMON ROM Monitor * Revision 02.13-SIGMADESIGNS-13-HEAD_SNAPSHOT_2009-03-17_01h00m02Z ********************************** Memory: code: 0x85000000-0x85040000, 0x85200000-0x85204000 reserved data: 0x85240000-0x86440000, PCI memory: 0x86440000-0x86840000 Version Mismatch !!Nand Flash version [ S I G M 1.0.3 ] and Nand driver version [ S I G M 1.0.2 ] on CS 0!! !! No NAND hardware found on CS 1 !! YAMON>
This boot mode can be made permanent by setting the z.default_boot XENV variable and storing it to flash:
YAMON> setxenv -b z.default_boot 0 Original value: 0x00000001 New value: 0x00000000 Please flush(using nflash/pflash write command) the updated transient XENV block (memory location: 0xbb79bcb0, maximum size: 0x00004000) to the location desired for permanent storage. YAMON> $commit Copying...Done YAMON>
Setting this variable to 1 restores the original behaviour, and the value 2 starts the firmware recovery procedure. The $commit command runs the command sequence stored in the commit variable, which has been prepared for the purpose of saving the environment. Similarly, $b1 will start the usual system, and $b2 launches the firmware recovery.
In the YAMON shell, the usual type of boot loader commands are available. It supports loading files from various sources including TFTP. Beyond the address-based access control imposed by the XPU, no further restrictions apply here. Notably, a signed kernel is not required. A few extra YAMON commands have been added by Sigma, their descriptions being available through the built-in help.
Ethernet
All SMP864x SoCs have two Ethernet controllers. According to official documentation, only the SMP8646 is gigabit capable. In reality, they all have RGMII compatible interfaces and support gigabit operation, although in the lower-numbered chips, the CPU has trouble keeping pace with the full data rate.
The PCH C-200 uses a Vitesse VSC8601 gigabit PHY and should thus support gigabit speeds. However, as many users have noticed, the link becomes extremely unreliable when connected to a gigabit switch. This is because the clock skew compensation in the PHY is set incorrectly by configuration pins or firmware. Correcting the setting makes the link stable and enables transfer rates of up to about 400Mbps. The clock skew is determined by the top four bits of register 28E (see the PHY datasheet for details), and the correct setting for this board is 1.4ns (initial setting is 1.7ns), i.e. a register value of 0x5000.
In the PCH C-200, the second Ethernet controller is connected to a Mini PCI slot intended for a Ralink Wi-Fi module sold separately. Note that the PCI signals in this slot are not connected, and standard Mini PCI cards will not work.
Kernel support
Linux support for these devices is sketchy at best with Sigma providing patches only to its chip customers, who may then pass them on to end users. These patches are against ancient kernel versions (3.4 is the most recent), and they are quite hideous even by evil vendor standards.
In order to get a modern kernel, I have ported/rewritten most of the basic drivers to work with current mainline. Graphics, audio, and media codec drivers have not been implemented. For reference, this repository also contains branches with patches as released by Sigma applied.
Tools
To ease the process of booting custom kernels, I created a few tools. Simply follow these exact steps:
- Compile the tools.
- NFS-export a directory containing the built tools to the PCH.
- On the PCH, mount the NFS share with the label boot.
- On the PC, run ./runcgi.pl <pch_address> yamon.cgi
- The PCH should now reboot to a YAMON shell.
In the YAMON shell, running phy-config.srec will correct the Ethernet PHY configuration as discussed above. This is recommended for loading kernels over TFTP. To fix the PHY settings while running the official interface, invoke the phy-fixup.cgi program using runcgi.pl as above.
Pingback: 1 – Popcorn Hour Revisited – Exploding Ads
Pingback: How good or bad is this DAC