I was always afraid of the behemoth of code lying beneath the software I ran on a daily basis: the Linux kernel. I loved what it provided to me: the opportunity to run operating systems unhindered by license agreements and monetary exchanges, the security of knowing how many eyes were on it. However, I was terrified by the concept of becoming one of those eyes. But a recent project led to my first contributions to the kernel, however small, and thrust me far outside my comfort zone. It's still something of a work-in-progress, but here's where it all started.
At the tail end of September 2024, I sealed the deal on a 3D printer: the Creality Ender 3 V3 SE. I had been wanting to get one for months at this point, but had been holding back for a while; however, a failed attempt to buy a used E3V3 KE finally overwhelmed my inhibitions, and I decided to pull the trigger on a brand new printer from a local retailer. I did do my research beforehand though; I knew this model wasn't exactly plug-and-play, with some poor tolerances regarding gantry tilt, many untightened screws, and the top-mounted spool holder being particular pain points.
I also knew the display was what mostly ran the show on this printer, and that it ran Marlin on a rather low-powered MCU. I had heard Klipper was the better software, with a lot more configurability and flexibility, and would allow me to print over the network (which was a necessity for me, as my desk didn't have the space for a printer). However, since I was in a somewhat impulsive mindset, I decided I didn't want to wait for a Raspberry Pi, and looked for other options.
That was when I made the fateful decision to buy the Creality Sonic Pad. I didn't know at the time, but my next few months would be spent more focused on this weird little tablet than the plastic-spitting monster I bought it for.
I was having a rough time getting high quality prints from my printer. A lot of it came down to just being new to the hobby; I think many people underestimate the complexity of getting into 3D printing in the first place, as I did. Initially, things seemed to be going well; I printed out a small duck with a crown with the included filament, and it looked fine for the most part; the quality was lacking somewhat, but it was something.
It seemed like every time I tried to make changes in an effort to improve the printing quality, however, I wouldn't have any luck. I tried doing a lot of researching, spending many nights just Googling and making test prints, and eventually started to get somewhere. From that point, I decided to set up a webcam with the Sonic Pad, so I could monitor the print without jumping back and forth between my computer and my printer.
This was where I realized the vendor firmware sucks. Firstly, the frame rate is supposedly locked to 15 FPS, which would be fine if it was actually capturing at that speed. But really, it was more like 5 FPS; I was watching a blurry slideshow approximating a video instead of a slightly slower live feed. Others online had reported the same issue. I dug around a bit, messed with more settings, but ran into more problems: leaving the live feed open in my browser for too long would crash the interface on my Sonic Pad, which would bring a sense of panic when it happened during 6-hour long prints. I quickly got fed up with this, and looked for more solutions.
I had looked early on, even before buying, at open firmware solutions. One that caught my eye was the SonicPad-Debian project, which installs a fairly stock Debian 11. It worked somewhat fine with some tweaking, and I certainly preferred the FOSS firmware over that which was built-in, but I was somewhat displeased that it used Creality's kernel tree from its BSP. In a piece of documentation, it was mentioned that using a mainline kernel was "out of the question", as it would require "serious patching" due to the lack of support for its SoC.
I originally just decided to take the maintainer at his word; I had went into this just wanting something that'd work, but I got hesitant about using this distro. I ended up dealing with the stock firmware for a little while longer, but the problems kept on coming. Eventually, I decided it was time to take up the challenge.
Looking deeper, I found that the SoC used by the Creality Sonic Pad was a rebadged Allwinner R818; there wasn't much info on this particular chip, but eventually I learned that it too was a rebadge of another chip: the Allwinner A133. Now we're getting somewhere.
It turned out Jbe230, the developer of the SonicPad-Debian project, was half-right: some patches were needed to get support for the SoC into mainline. However, they weren't as major as was originally portrayed, as some pre-existing support already existed for the SoC, but under another name. This is where a little bit of history is in order.
The Allwinner A133, and by extension the R818, are actually binned variants of another SoC: the A100. This SoC was released sometime in 2020 to little fanfare; mainly intended to target the mid-range tablet market. However, not even a year after its release, it was mostly replaced by the A133 in all marketing. The exact reason is unknown, but the rumors I heard state that most A100 chips ended up meeting or exceeding the binning thresholds for the A133, and thus they killed the A100.
In any case, the hardware is exactly the same between the A100 and A133 as far as we know, and in fact there is a variant of even higher binning, but I'll get to that later. What we do know is that in late 2020, two developers working for Allwinner submitted patches to implement support for the A100, and these patches were compatible with the A133 as well. I didn't really know much more than the existence of these patches and the R818 and A133 being functionally equivalent when I started; most of this information is what I was able to figure out later.
Sounds like a great place to start, but we were missing other pieces of the puzzle as well. For one, U-Boot didn't have any support for the A100 series; I did some research and found nothing that would suggest to me any pre-existing support for the A100. I found the same with ARM Trusted Firmware (TF-A); no support was available for the A100. Finally, it seemed like the sunxi-fw tool (whose author plays a large part in this story) didn't recognize the SoC; although this seemed like the simplest place to start, there were magic values needed I didn't recognize yet, and had no clue where to find.
However, on the way there I found out about the linux-sunxi community. This was a decentralized group of developers working on support for SoCs like mine; "sunXi" is the branding/internal name/something for Allwinner SoCs. I decided to drop into their IRC channel on OFTC and ask my first question.
I wasn't really expecting a response, let alone a useful reply. In many communities I've tried to interact with in the past, all I could get was a "sorry, no clue, you're on your own bud". I did want to at least make an effort before giving up though.
Luckily, it turned out the sunxi community was different, and after a few hours, I got a response from another IRC user. apritzel (who wrote the sunxi-fw tool I mentioned earlier) pointed me to testing branches he had made a while back for U-Boot and sunxi-fw, but I learned a critical piece was missing from U-Boot to bring it up and running.
That's it for part 1. Not a lot of development yet, but this should give at least a decent idea of where I started at the beginning, and I wanted to leave some sort of suspense. Keep your eyes peeled for part 2!