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.
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.
|Sigma Designs SMP8643||SoC|
|Nanya NT5TU64M16DG-3C||RAM||4x 1Gb, 512MB total|
|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|
|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|
The main PCB contains a number of connectors, some more interesting than others:
|J1||FIP||Connection to front panel|
|J8||FRONT_USB||Connection to front panel USB|
|J26||Component, composite, audio|
|J85||Unpopulated, purpose unknown|
This diagram shows the location and, where relevant, pin numbering of the connectors.
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.
|3||5VSTB||O||ATX standby power|
|5||RC_OUT||I/O||GPIO12, IR decoder|
|7||RC_IN||O||IR/RF remote output|
|9||SDA||I/O||GPIO1, I2C data|
|10||SCL||I/O||GPIO0, I2C clock|
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.
|2||RC_IN||O||IR/RF remote output|
|4||STB||I/O||FIP data strobe||GPIO4|
|5||DATA||I/O||FIP data I/O||GPIO2/3|
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.
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.
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.
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|
|I2C||2 masters, 1 slave|
|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”|
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.
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.
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.
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.
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.
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.
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.
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.
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
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 ?
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.
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 ?
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.
Is it possible that you release a compiled version (binary) of your tool of the phy-fix for the official interface?
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.
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.
Pingback: How good or bad is this DAC
Could anyone help me downgrade C200 firmware back to first original firmware please so as to hopefully remove Cinavia and 3D stop play .
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?
The MAX7325 I/O expander is at I2C addresses 0x5d and 0x6d. The LM27966 backlight control is at 0x36. My Linux tree on Github has drivers for the display and backlight.
Awesome. Thanks heaps.
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.
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?
The kernel tree is at https://github.com/mansr/linux-tangox
The display driver (FB_AMG19264C) uses the standard fbdev interface.
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?
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.
In short, no. For starters, it is soldered in place.
C200 got to do “repair”. Apparently suddenly she stopped working. There is no HDD.
Serial in PuTTY:
#xos2P52-100 (sfla 128kbytes. subid 0x00/af) [serial#2a033c3fc5d313ea5df59d0e1d408385]
#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.
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.
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.
PS have just set C200 to 10/100 in networking and it does seem much more stable, though am only getting transfer rates of just over 1MB/s…pretty glacial, and no where near the 400Mb/s you’ve been getting…
Actually, thought it was better, but I’m afraid it isn’t…
Fixing the PHY settings while running the stock software is somewhat tricky, unfortunately. As mentioned at the end of the post, I’ve made a small tool to simplify it, but it’s still somewhat convoluted.
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:
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… :-(
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.
Thanks to take some times to answer me.
Ok for my wiring, good.
I download this driver found on internet. I think that group drivers for display, i2c, and backlight:
Sorry for all my question, but how with LCDd.conf to load the correct drivers? How to turn on the backlight. Sorry, but i begin with that… Thx a lot!
Again me… Sorry…. ;-)
I downloaded your drivers:
– amg19264c-fb.c for I2C and display
– lm27966_bl.c for backlight
I have openlec. How to do that this drivers works with LCDd and LCDproc? It’s possible or not? Or what it’s the best way to have kodi info to popcorn display… Thx a lot, best regards.
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?