Slow progress

Back in March I was in the UK troubleshooting a Humax set-top box that was behaving erratically. Most of the time it would work as expected, but sometimes it would just display a green screen when switching on or changing channels. In the end, the solution to the original problem was to change from using a HDMI cable to connect the set-up box and television to using a SCART cable instead.

One of the things I played with as a fallback option was a Raspberry Pi with a TV hat, which turned out to be more complicated to use than expected and not a direct replacement for a DVR. It probably didn't help that I chose an underpowered Pi (a Zero 2W) for the experiment.

Repurposing the Pi

Since the Pi isn't going to be needed for recording TV, I picked up the original Inferno port and tried to get it running on the updated hardware of the Zero 2W. There was a very frustrating initial two weeks where I learned the hard way about ARMv8, Hyp mode, MMUs, VideoCore and probably other things that make the BCM28** hardware so special. Then I was away in the UK again.

I picked up a bit more momentum when I tried running 9legacy on the Pi and saw that it ran pretty well. This encouraged me to look more closely at the code and update the parts of the Inferno port that originally came from there. At one point I had enough up and running to get the window manager working, but the result was disappointing because access to the microSD card was unreliable.

Meanwhile in microcontrollers

In parallel with the Pi porting, I picked up the Cortex-M ports and tried to add support for microSD cards to the Apollo3 port. This didn't go as quickly as I'd imagined, partly because I hadn't really done much with writing data to (micro)SD cards, even if I feel I've written so much code to read from them in the past. I also needed to figure out the multi-layer approach that Inferno seems to have adopted from the Plan 9 variants, and I'm still not entirely sure about it.

Taking it slow

Returning to the Pi, I decided to try and isolate the unreliability with the microSD card by changing the EMMC driver to not use DMA for transfers. This plan started with the expectation that I would remove DMA transfers, find out that card-reading was still unreliable, and proceed to some unknown next step. However, it seems that card-reading is now hopefully reliable, which means that I need to look into the DMA problems at some point.

Another issue I need to resolve is why I couldn't use FIQ (fast interrupt requests) for the USB stack. Currently, I just use a regular IRQ for the USB interrupt.

There always seems to be something not quite right with the Pi. I think a combination of shifting hardware between models, changing “firmware” and poorly documented interfaces between the ARM cores and the VideoCore processor really don't help make it a stable platform for anything other than the officially sanctioned OS. Still, maybe something can be salvaged from this and I won't have to run a system on it that struggles with “only” 512 megabytes of RAM.


David Boddie
10 May 2024