Hacking a printer motherboard
Apr. 19th, 2026 09:01 amThis is a bit of a random side project. The backstory is that a few years ago, I had a HP printer which eventually ran into print head problems. I had tried to fix it, but was unsuccessful, so I did what I do with things I deem a lost cause: tear it down, salvage the electronics, and throw out the rest.
Recently, I was curious about that printer's motherboard, and what made it tick - and if I could reuse it somehow.
I tried to run it bare, out of curiosity - with just the front panel boards attached. It actually boots after a while - and complains about the cartridge door being open. If the sensor is blocked, it instead complains about a problem with the print head. Well, of course, there's none.
However, we still have: front panel LEDs and buttons, a SD card slot, a LCD panel with some capacitive touch buttons, a USB-B port, a wifi card.
Looking at the chips, we have:
* Marvell 88PA2DU2-BGE1 - SoC
* Hynix H5PS5182FFP - DDR2 SDRAM, 64MB
* Winbond 25Q128BV1-G - SPI FLASH, 16MB
* Macronix MX25L1606E - SPI FLASH, 2MB
* Texas Instruments SC211038 - mystery chip (likely a support MCU)
First thing I did was desolder the 16MB FLASH and plop it in my MiniPro. I expected it to contain firmware code, while the other, smaller FLASH would be for configuration data. I didn't know what to expect regarding the SoC architecture.

I quickly recognized this: big-endian ARM. Odd choice.
The firmware is mapped at 0x0, but the gist of it is compressed with a variant of LZ77. I hacked together a quick and dirty emulator so I could get an idea what's going on.
The next step was to inject code into this device, so I could try to extract more data from it - figure out what the CPU is, how memory is mapped, extract the ROMs if there are any, and so on.
For this, I had a solution in mind.

Since this is a bog standard SPI flash, I thought my FPGA-based SPI FLASH emulator might be compatible. It is! I made a test with the stock firmware and it booted just fine.
From this, it wasn't hard to build a binary that could be injected into the board. However, I had to figure out how to output data. Analyzing the firmware code reveals the existence of a UART-type debug output, but I couldn't find it on the board.
So instead, I did the same thing I did with the WiiU gamepad - use the SPI interface. With a bit of digging, I was able to find firmware code for accessing the configuration FLASH - and confirmed that the two FLASH chips share the same interface. Thus, I knew how to use the SPI interface for my purposes.

A few observations about the hardware, so far:
* At first, I was surprised by the SPI traffic I saw when running my own code - it seemed to be hitting the same addresses in a loop. I eventually realized what is going on - the FLASH is directly mapped to the CPU. I had expected it to be more like the WiiU gamepad, where you have a boot ROM loading a binary from FLASH into RAM, but there's none of that here. The stock firmware eventually decompresses itself into RAM and runs there - while this direct FLASH mapping is convenient for getting things started, I imagine it would be very slow for anything else.
* The CPU is an ARM946E-S. The same model as in the DS. I don't yet know which speed it runs at - the crystal frequency is 27 MHz, but there's likely a PLL inside the SoC that I haven't initialized yet.
Next step is going to be figuring out how to initialize the RAM, so I can run proper code.
Then I can try to reverse-engineer more of the hardware and figure out fun things to do with it. It would be nifty to figure out how to use the LCD.
Recently, I was curious about that printer's motherboard, and what made it tick - and if I could reuse it somehow.
I tried to run it bare, out of curiosity - with just the front panel boards attached. It actually boots after a while - and complains about the cartridge door being open. If the sensor is blocked, it instead complains about a problem with the print head. Well, of course, there's none.
However, we still have: front panel LEDs and buttons, a SD card slot, a LCD panel with some capacitive touch buttons, a USB-B port, a wifi card.
Looking at the chips, we have:
* Marvell 88PA2DU2-BGE1 - SoC
* Hynix H5PS5182FFP - DDR2 SDRAM, 64MB
* Winbond 25Q128BV1-G - SPI FLASH, 16MB
* Macronix MX25L1606E - SPI FLASH, 2MB
* Texas Instruments SC211038 - mystery chip (likely a support MCU)
First thing I did was desolder the 16MB FLASH and plop it in my MiniPro. I expected it to contain firmware code, while the other, smaller FLASH would be for configuration data. I didn't know what to expect regarding the SoC architecture.

I quickly recognized this: big-endian ARM. Odd choice.
The firmware is mapped at 0x0, but the gist of it is compressed with a variant of LZ77. I hacked together a quick and dirty emulator so I could get an idea what's going on.
The next step was to inject code into this device, so I could try to extract more data from it - figure out what the CPU is, how memory is mapped, extract the ROMs if there are any, and so on.
For this, I had a solution in mind.

Since this is a bog standard SPI flash, I thought my FPGA-based SPI FLASH emulator might be compatible. It is! I made a test with the stock firmware and it booted just fine.
From this, it wasn't hard to build a binary that could be injected into the board. However, I had to figure out how to output data. Analyzing the firmware code reveals the existence of a UART-type debug output, but I couldn't find it on the board.
So instead, I did the same thing I did with the WiiU gamepad - use the SPI interface. With a bit of digging, I was able to find firmware code for accessing the configuration FLASH - and confirmed that the two FLASH chips share the same interface. Thus, I knew how to use the SPI interface for my purposes.

A few observations about the hardware, so far:
* At first, I was surprised by the SPI traffic I saw when running my own code - it seemed to be hitting the same addresses in a loop. I eventually realized what is going on - the FLASH is directly mapped to the CPU. I had expected it to be more like the WiiU gamepad, where you have a boot ROM loading a binary from FLASH into RAM, but there's none of that here. The stock firmware eventually decompresses itself into RAM and runs there - while this direct FLASH mapping is convenient for getting things started, I imagine it would be very slow for anything else.
* The CPU is an ARM946E-S. The same model as in the DS. I don't yet know which speed it runs at - the crystal frequency is 27 MHz, but there's likely a PLL inside the SoC that I haven't initialized yet.
Next step is going to be figuring out how to initialize the RAM, so I can run proper code.
Then I can try to reverse-engineer more of the hardware and figure out fun things to do with it. It would be nifty to figure out how to use the LCD.








































