Popcorn Hour revisited

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.
PCH C-200 connector diagram

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:

  1. Compile the tools.
  2. NFS-export a directory containing the built tools to the PCH.
  3. On the PCH, mount the NFS share with the label boot.
  4. On the PC, run ./runcgi.pl <pch_address> yamon.cgi
  5. 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.

Bookmark the permalink.

30 Responses to Popcorn Hour revisited

  1. Pingback: 1 – Popcorn Hour Revisited – Exploding Ads

  2. Bousqi says:

    Hi,

    Thanks for this really interesting and detailed article on PCH C200.
    I’m the owner of a PCH A300, and I’ve been experiencing a lot of network instabilities.

    I planned to electronically check the main board, but I just read this article.

    On the Network chapter, you make reference to clock issues in the PHY when connected to a Gigabit switch. I just realized that all my switch at home are now Gigabit, and I can’t get any stable connection with my PCH A300. Both PCH share the same network chip, a Vitesse VSC8601XKN.

    Can you please give me more details about this : “Correcting the setting makes the link stable and enables transfer rates of up to about 400Mbps.”

    How did you manage to fix that ?

    • Mans says:

      I have updated the text with some more details on this and added a Linux app to perform the tweak to the pch-tools repo. The proper amount of clock skew depends on the PCB layout, so the A300 might need a different value.

      • Bousqi says:

        How can you “measure” the clock skew ?

        On my side, it appears that I might have another issue.
        After having connected an FTDI to the debug USART, I realized that my PCH A300 is restarting 3 or 4 times before detecting the PHY chip at startup, and finally booting the Os.
        By the way, once board has booted, the network is totally unstable.
        I suspect some mainboard issue. I’ll try to use a hot air blaster. There might be some soldering issues.

        Any comment ? suggestions ?

  3. softwarebug says:

    Hi,

    Thank you for this detailed article and for sharing your hard work on the internet.
    I know people that work at Sigma, if you want, I can put you in contact with them, I am sure they will like your article and hearing from you.

    Do you have an email address to share? Otherwise you can write to me using the address I filled up in this form.

  4. Mr.M. says:

    Hi,

    great article!

    Is it possible that you release a compiled version (binary) of your tool of the phy-fix for the official interface?

    • gertas says:

      I would be also very interested of getting phy-fix binary, I have spent two days trying to build sigma’s sdk toolkit but no luck. Thanks.

      • gertas says:

        Finally I managed to compile it with with Sourcery CodeBench cross-compiler. The command is:
        /mips-linux-gnu-gcc -std=c99 -O2 -EL -march=mips32r2 -Wall -s -o phy-fixup.cgi phy-fixup.c

        My results wIth Popcorn Hour A-200 are ~4MB/s where download is ~11MB/s (86% CPU utilization for samba). Auto mode which is 1Gbps link. The fix helped a bit but I still see lot of RX errors, especially during upload to PCH.

  5. Pingback: How good or bad is this DAC

  6. Stoka says:

    Could anyone help me downgrade C200 firmware back to first original firmware please so as to hopefully remove Cinavia and 3D stop play .

  7. Darren says:

    Hi. Thanks for the hard work. As far as I can tell, this is the only resource like this.
    I’m trying to replace the motherboard with a Raspberry Pi but keeping all of the components like the LCD. I’ve connected up the expander to the Pi but it is showing that every I2C address is occupied. Do you happen to know what I2C address is actually in use?
    Regards.

  8. Darren says:

    I’ve found a max732x driver in gpio but I’m struggling to find the backlight one. Would you please point me in the right direction.
    Thanks.

  9. Chris says:

    Hi Mans,

    I’m also researching the possibility to use one of my C200’s (I own two) as a source for a case for my Raspberry Pi 2.

    But I can’t find your github with the drivers for the display… Could you please give me the link? And is this driver suitable for lcdproc or is it stand-alone?

  10. Michael says:

    Hi – looking for some guidance here – maybe some tips. Pulled an RTL8191RU USB WiFi 802.11b/g/n module + multi-card reader station RTS5182 from old OEM machine. This combo ends in one standard USB 2.0 internal header (WiFi is daisy-chained to RTS5182). Do you think I could simply connect it to the C-200 mainboard, would it work of the box? Lots of effort to get it to work or not?

  11. Pierre says:

    Hi,

    Thanks for this detailed review. I’m not enough qualified to fully understand, but can the ram be upgraded? When I use Transmission for downloads, the C200 keeps crashing unless the speeds are limited to around 1 MB/s.

  12. Dako says:

    HI,
    C200 got to do “repair”. Apparently suddenly she stopped working. There is no HDD.
    Serial in PuTTY:

    39idxfs696b15f57c540829defeeee9f4a092007337a124S

    #xos2P52-100 (sfla 128kbytes. subid 0x00/af) [serial#2a033c3fc5d313ea5df59d0e1d408385]
    xmb 0xb5
    #chpll 0x01000024/0x00000201 -> 0x01000030/0x00000101… actual sys=330MHz
    #DRAM0 Window : 0x# (0)
    #DRAM1 Window : 0x# (17)
    #poisoned 131072 pages with 0xec8ccfc9
    #step6 @*** zxenv has been customized compared to build ***

    It is possible to repair?
    Sorry for the translation, I live in Poland.
    Regards

    • Mans says:

      Repairing that is tricky if not impossible. It seems to be failing before the secure loader hands over to the application processor. Perhaps your NAND flash has been corrupted. If so, it might be possible to connect a probe to the chip and re-flash it with a copy from a working device.

  13. Simon says:

    I’ve been having n/w problems with my c200 for years now. I just assumed the n/w port was faulty! Buy I’ve just tried hunting for a m/b replacement online, and came across this article. Brilliant! I’m no techie, but you’ve clearly done a great deal or good work here.

    But now I have a Q: you meantion above “Correcting the setting makes the link stable and enables transfer rates of up to about 400Mbps”. My connection to the c200 drops out when trying large file transfers (copying movies across the network, and using the extra space on my c200 drives as backup space), and only a reboot will fix it.

    So can you please tell me how to fix the settings on my c200 so create a stable wired connection to my network? This would be a MASSIVE help to me.

  14. syme says:

    Hi Mans,

    I need some help from you. I have an old popcorn hour C-200 but this one is crash… I have already a raspberry 2 and i want to place it inside the C-200. I block with the LCD.. I think that i correctly connect the raspberry to the J1 FIP
    Rasp: Pin14 (5v) –> J1 FIP: 1
    Rasp: Pin16 (GND) –> FIP:2
    Rasp: PIN2 (SLA) –> J1 FIP:9
    Rasp: PIN3 (SLC) –> J1 FIP:10
    It’s correct for you? Have i forgot anything else to connect?

    Also, i’m running under OPENELEC. I install LDCproc & I2Ctool. When i running the i2ctool, i see the the I2C port appear (0x5D & 0x6D)
    And edit the LCDd.conf with this lines:

    ## Server section with all kinds of settings for the LCDd server ##
    [server]
    DriverPath=/storage/.config/raspdrivers/
    Driver=hd44780
    Bind=127.0.0.1
    Port=13666
    User=root
    Foreground=yes
    # Hello message: each entry represents a display line; default: builtin
    Hello=" Welcome to"
    Hello=" OpenElec"
    # GoodBye message: each entry represents a display line; default: builtin
    GoodBye="Bye bye"
    GoodBye=" C U"
    # Sets the default time in seconds to displays a screen.
    WaitTime=5
    # set title scrolling speed [default: 10; legal: 0-10]
    TitleSpeed=1
    ## The menu section. The menu is an internal LCDproc client. ##
    [menu]
    ## Hitachi HD44780 driver ##
    [hd44780]
    ConnectionType=i2c
    # Port where the LPT is. Usual value are: 0x278, 0x378 and 0x3BC
    Port=0x5d,0x6d,0x36
    # Device of the serial interface [default: /dev/lcd]
    Device=/dev/i2c-1
    # Bitrate of the serial port (0 for interface default)
    Speed=0
    # Specifies the size of the LCD.
    # In case of multiple combined displays, this should be the total size.
    Size=16x2
    CharMap=hd44780_default
    DelayMult=4 
    

    So, my big problem it’s that the display show me nothing… I try with your drivers but nothing too. Can you help me please?? My connection are correct? The LCDd.conf are correct too?
    Thx a lot guy, and i hope that you can help me cause even in google i don’t find anything… :-(

    • Mans says:

      If the I2C device is detected at the expected addresses, that means the wiring is correct. However, the display is not an HD44780, so that driver can’t work. There’s a link to the datasheet for the display module at the top of the post. My git repo has a Linux fbdev driver for it. Note that you must also turn on the backlight or you won’t see anything. There’s a driver for that as well in my git repo.

  15. Peter Cherry says:

    Hi Mans and Syme,
    it seems my C-200 died during the firmware recovery:(
    FAIL ERR034 (can’t format internal flash to ext3).

    A) C-200 was working before the recovery. Do you think there is any solution to this? NAND problem=no solution?

    B) I am thinking about using case, LCD panel, buttons and 3.5 SATA HDD with Odroid/Raspberry/something else. Can you recommend any good single board computer or motherboard?

    I like Syme’s idea I would like to follow this approach.
    Thank you for tips and help
    Maybe some short summary for rebuild?

Leave a Reply

Your email address will not be published. Required fields are marked *