Reversing the ZX Vega: Hardware

It’s been a while since I wrote part one. I promised I’d have a look at the hardware on the Vega.

Here is the front of the board:

And the rear:

As can be seen from the front photo, the components are quite simple, with the major ICs being:

  • CPU (in red), an NXP MCIMX233DAG4C ARM based processor
  • Storage (in yellow), a Spansion FL512SA1F01 512 Mb SPI Flash chip
  • Memory (in purple), an Alliance AS4C8M16D1-5TCN 128 Mb DRAM

Note memory sizes are in Mbits – i.e. 1024 * 1024 bits; to get these in bytes we need to divide by 8, so that’s 64 MB of storage and 16 MB of RAM.

The storage chip is NOR SPI flash. SPI flash is relatively simple to read and (mostly) follows a standard core of commands defined by JEDEC.

I’ve rigged this up through a custom cable, from a 16 pin Pomona clip to one of my Raspberry Pis (as it gives me a lot of control over what I can do).

I have a few python scripts written to read NOR flash over SPI. One of these is a raw command line interface to the JEDEC op codes.

The first step here is to identify I can actually talk to the chip, this can be performed by using the RDID (opcode 0x9f), RES (opcode 0xAB) and REMS (opcode 0x90) commands. These should return the same information about the chip identifying the manufacturer and the density of the device which should tell us the size.

This produces the below, which isn’t quite right, the manufacturer ID is AMD and the density would work out as 4294967296 bytes or 4096 MB, which is a bit silly. We know it should be about 64MB:

A quick test to see whether we can read data, using the READ (opcode 0x03) command. Ah; we’re reading data. That’s a good thing, maybe the identification results aren’t quite perfect.

Using flashrom fails to identify the chip, which means flashrom won’t even try to read it:

pi@raspberrypi:~/spireader $ flashrom -p linux_spi:dev=/dev/spidev0.0
flashrom v0.9.9-r1954 on Linux 4.9.24-v7+ (armv7l)
flashrom is free software, get the source code at https://flashrom.org

Calibrating delay loop... OK.
Found Generic flash chip "unknown SPI chip (RDID)" (0 kB, SPI) on linux_spi.
===
This flash part has status NOT WORKING for operations: PROBE READ ERASE WRITE
The test status of this chip may have been updated in the latest development
version of flashrom. If you are running the latest development version,
please email a report to flashrom@flashrom.org if any of the above operations
work correctly for you with this flash chip. Please include the flashrom log
file for all operations you tested (see the man page for details), and mention
which mainboard or programmer you tested in the subject line.
Thanks for your help!
No operations were specified.

So, I’m going to use my own code, which allows you to read it from a web browser with a one click solution, as shown below:

Because the chip didn’t respond correctly to the RDID call I had to make a couple of amendments to not try and read too much data from the chip.

So, I know have the file read from the onboard storage and… It’s exactly the same as the firmware, meaning that the CPU decrypts it on the fly, which, I’d expected. Bugger.

Right, onwards, if you look closely at the photos of the rear of the board, there are a couple of test points that are visible: one in-circuit programming type header at the top (red) and two sets of three test points a bit further down (yellow, marked J4 and blue marked J3) .

Using a multimeter in continuity mode to attempt to buzz out where these go shows me that the connector marked J4 connects to ground and the PWM0 and PWM1 pins of the CPU, according to the datasheet these are commonly used for Debug UART. J3 has 3.3V and a connection to the DEBUG pin of the CPU, this is used for SJTAG.

The header at the top only appears to buzz to ground and VCC, this is probably due to components between the connectors and the pins they connect to. This is something to look into later.

I can’t test the SJTAG connection with the tools I have with me, but UART is a simple serial protocol that uses two wires for transit and receive and is commonly used for consoles on devices.

A quick trip to the garage, where I keep the soldering iron, allows me to tack some wires to the board; now I can rig up a logic analyser to allow me to monitor those pins whilst I boot my Vega.

And what do I get… not quite what I expected:

Looks like they updated the bootloader text screen. Unfortunately that’s it, there’s nothing else as I continue to use the Vega. This really isn’t going anywhere fast unless I can either get the SJTAG interface or the other header working.