This is an automated archive made by the Lemmit Bot.

The original was posted on /r/sbcgaming by /u/Capital-Common-3510 on 2024-08-26 13:24:30+00:00.

This post is about the development status of getting an open source kernel working on the Powkiddy X51, or any Actions Semi ATM7051/7021 handheld device.

For these who don't know, the Mainline Linux kernel (upstream) is the newest released and under-development version of the Linux kernel. Quite literally github.com/torvalds/linux

A bit of history beforehand: I've been working on SoC and device bringup as a linux kernel hobbyist for a while now (~4 years). 1 or 2 years ago I got my hands on this handheld called Powkiddy X51, cause why not :D. At first sight there wasn't much I could do: it contains all system firmware files on its NAND, and I couldn't find any exposed UART ports. I tried running a small custom ARM assembly binary to write to the FB, but that didn't work as well, so it was a dead end and I abandoned any work for it.

Recently (1 or 2 months ago) I decided to get back at it since a friend of mine also bought the same console. After a lot of digging (keep in mind there's close to NO information about both the SoC and the device, so progress is really hard to keep going), I found the following stuff:

A tool from actions semi that allows flashing individual partitions on the nand as long as a .fw file with a proper partition layout is provided (IH FW Burning tool)

1. UART5 TX and RX are exposed on the sd card pins
2. Kernel source for the NeoGeo Arcade Stick Pro (which is using the same SoC, but has an older kernel - 3.4 instead of the newer 3.10 with device trees used on my handheld)
3. Android firmware files for ATM7051 tablets>! (I'm most likely not gonna put any effort towards that though :P)!<
4. Schematics for some random ATM7051 device

Proceeding forward, after disassembling the device, soldering a serial-to-usb adapter to the UART5 RX and TX, and finally firing up putty, we get u-boot logs!

And then it was time to do the hard work: get mainline linux booting. The boot flow of the device is as follows:

bootrom -> bl31 -> u-boot -> linux -> userspace

In order to get my own build of the linux kernel booting, we need to replace the downstream closed-source one. It resides in the first fat16 partition of the device, called MISC, so after dumping the whole nand via ADB, I mounted the MISC partition image dump, modified the uenv.txt a bit and started testing/debugging my mainline linux fork by flashing the modified MISC with Actions IH FW Burning Tool.

It took quite a bit of work, but I managed to get the following peripherals working:

• timer ("actions,atm7051-timer")
• multi core ("actions,atm7051-smp")
• serial ("actions,owl-uart")
• i2c ("actions,s500-i2c")
• SIRQ (a second interrupt controller besides GIC that provides up to 3 external interrupt lines for devices like MMC and PMIC) ("actions,atm7051-sirq")
• SPS (Smart Power System, used for managing important CPU-related power gates) ("actions,atm7051-sps")
• DMA ("actions,s500-dma")
• partially pinctrl
• regulators ("actions,atc2603c")
• SimpleDRM (wooo display via framebuffer)

And BOOM! Arch Linux INITRAMFS with 4 fancy penguins on my handheld:

Of course it was a bit messy at first xD

Here's a few issues though:

1. Proper pinctrl and clock drivers will be hard to achieve. The drivers coding style has changed a lot not just from SoC to SoC (atm7051 3.4 pinctrl driver is quite different from the 3.10 s500 one), but also in mainline. I'm missing information about pinctrl groups, functions, clock gate and div values, etc etc etc.
2. There's no NAND driver for any Actions SoC upstream. This means that we'll either have to write one, or stick to working on MMC.
3. I haven't dug deep into MMC yet since we need clocks first, but there's a decent chance that it's not gonna be controlled via the DMA block (at least according to the 3.10 DTS)
4. The GPU driver isn't open sourced. We can use proprietary blobs with hacks, but it'll still be annoying.
5. We can't use both SD card and UART5 at the same time, otherwise we get garbled uart output.

-> I also tried getting the 3.4 compiled and booting. It needs some changes to the board driver files, as MMC isn't wired to SIRQ on our device and that causes a kernel panic. It shouldn't be that hard to get up to initramfs. If anyone wants to work on that, go ahead, it's more doable for usability purposes since it's got more drivers available than my current fork of mainline linux.

-> For the funsies, I got upstream u-boot booting with working UART, which is capable of booting linux via kermit. It could be useful if we ever want to replace the outdated stock u-boot, as long as it doesn't turn out to be signed.

Honestly though, don't have huge expectations for the future. I don't have *that* much motivation to keep working on that SoC, and I'd appreciate any help. My current focus is building up a solid portfolio for a kernel dev job.

I'll be upstreaming my work in the following weeks/months. I also need to write more detailed instructions/explanations on how things work.

Here are a few useful links (NOTE: I AM, IN NO WAY, RESPONSIBLE FOR ANY DAMAGE YOU DO TO YOUR DEVICE BY TRYING TO REPLICATE WHAT I'VE DONE. IF YOU WANT TO EXPERIMENT WITH FLASHING DIRECTLY TO YOUR NAND, PROCEED AT YOUR OWN RISK):

My mainline linux branch with atm7051 commits - (I still have to push device trees and pinctrl support, it needs some cleanup first though)

Useful information for stuff like UART pins and schematics -

The Actions IH FW Burning tool -