So I got scammed.
I was trying to buy a proper r36s clone so I could play Stardew Valley in the bathtub. My mistake. Instead, I ended up with a "GA36-MB." Identical in every way from the outside, this little guy is quite the imposter. The CPU is allegedly not a Rockchip RK3326, but an Allwinner A33. From a performance perspective that's a little bit of a downgrade, but the real kicker is that the rockchip is a 64 bit chip and the allwinner is 32. More like allloser amirite. I'm not 100% convinced that this is the case though, I've seen a lot of conflicting information on this, so I intend to put the question to rest, though I'm hoping it's a rockchip.
(Spoiler alert: It's not a rockchip. It's a 32-bit allwinner with 512mb of ram.)
The MicroSD card that comes with it: Piece of shit. Create an image of it with dd then throw it away.
Hopefully you didn't pay extra for the """128gb""" model. The "64gb" card it shipped with turned out to be 16, and there are more that enough reports of these things failing early to indicate to you that you should backup the data off of it and throw it in the bin as quickly as possible.
Plug the micro sd card into your linux computer (you are using Linux, aren't you?). Identify where it is with
lsblk
Then run
sudo dd if=/dev/sdX of=ga36mb_sdcard.img bs=4M status=progress conv=fdatasync
And finally,
sync
Great now you have a backup. Now throw it on a new 16gb+ microSD card:
sudo dd if=ga36mb_sdcard.img of=/dev/sdX bs=4M status=progress conv=fdatasync
sync
Great!
The official instructions want you to stick a second microSD card in the 'games' slot and use that for your roms.
Fuck that.
I'm a one-sd-card kinda guy (though you may actually get slightly better performance if you use two, idk tho).
The sd card is formatted in some super fucked up way, which made it very annoying to figure out how to mount.
Partitions are overlapping, there's logical partitions nested inside of extended partitions. It's a mess. I can't tell if this is a result of them faking the 16gb SD card into reporting as a 64, or some kind of half-assed copy protection scheme, or both. Anyway, because of this, your OS will not mount it nicely. Not without some help:
We can just manually mount the volume at a certain offset because linux rules.
The .FEX file defines a hard-coded offset:
[card_boot]
logical_start = 40960With that, we can dedermine the actual physical sectors where all our data lives:
| label | logical start | physical start (sectors / bytes) | size (sectors) | /dev/ | file system | notes |
|---|---|---|---|---|---|---|
| bootloader | 0x1000000 | 73728 / 37748736 | 65536 | mmcblk0p2 | fat16 | splash image(s), magic.bin |
| env | 0x3000000 | 139264 / 71303168 | 32768 | mmcblk0p5 | none | raw data |
| boot | 0x4000000 | 172032 / 88080384 | 65536 | mmcblk0p6 | none | android bootimg |
| ARKOS | 0x6000000 | 237568 / 121634816 | 1048576 | mmcblk0p7 | fat16 | rootfs & splash image(s) |
| storage | 0x26000000 | 1286144 / 658505728 | 2097192 | mmcblk0p8 | ext4 | /storage |
| UDISK | 0x66005000 | 3383336 / 1732268032 | 27150295 | mmcblk0p1 | fat32 | /storage/roms |
and you mount those with this command:
sudo mount -o offset=<offset in bytes> /dev/sdX <mount point>
Where <offset> is the offset, <mount point> is an empty folder to mount to, and sdX is your microSD card identified by lsblk. Note: you can append ,uid=$(id -u),gid=$(id -g) to the end of the offset to mount some of the partitions in a way that lets you access it as not-root, which is slightly more convenient)
From there I would highly recommend going into the bootloader partition and changing the splash screen image
Inside of the ARKOS partition is a nice big file called SYSTEM which is a squashfs volume.
I beleive we can modify this file to basically create a custom firmware for this stupid ass device.
Let's try!
First, I'm gonna grab the squashfs file's stats:
$ unsquashfs -s SYSTEM
Found a valid SQUASHFS 4:0 superblock on SYSTEM.
Creation or last append time Thu May 7 22:00:46 2026
Filesystem size 422180918 bytes (412286.05 Kbytes / 402.62 Mbytes)
Compression lzo
algorithm lzo1x_999
compression level 9
Block size 524288
Filesystem is exportable via NFS
Inodes are compressed
Data is compressed
Uids/Gids (Id table) are compressed
Fragments are compressed
Always-use-fragments option is not specified
Xattrs are not stored
Duplicates are removed
Number of fragments 423
Number of inodes 12277
Number of ids 2aaand, decompressing it gives us a linux root directory. Woohoo.
The bad news:
There's a file in the root dir called ee_arch. I can only assume this is the system architecture, and bad news everyone: it contains three characters "A33".
This doesn't absolutely mean the chip is a 32 bit Allwinner a33, but I can't see what else this file is doing here.
Inside of /etc/os-release it literally says this is a build of EmuELEC for the Allwinner A33 lmao, BUT it also says aarch64 everywhere, which isn't possible on the allwinner chip. So who fucking knows.
Also, usr/bin is full of 32 bit binaries. Fuck.
(cw: cope) It is ENTIRELY POSSIBLE, that this IS a build for the a33 running on the rockchip, as armv8 is backward compatible with armv7, and 64 bit processors can run 32 bit software. It's POSSIBLE. I'm not giving up hope yet.
(EDITOR'S NOTE: He has since given up hope)
EmuElec generally has more menus, like scripts and ports, but those are absent here.
We can add them back!
find es_systems.cfg in the storage partition, and add something like this:
<system>
<name>setup_scripts</name>
<fullname>Setup Scripts</fullname>
<path>/usr/bin/scripts/setup</path>
<extension>.sh .SH</extension>
<command>%ROM%</command>
<platform>scripts</platform>
<theme>scripts</theme>
</system>This gives us a new menu option with the build in "setup scripts" that ship with the OS. I've tried most of them and they all fail, and the ones that do work cannot be interacted with except the PortMaster Setup Script, which needs internet to work anyway.
- There's a hidden Minecraft for PSP homebrew game in the PSP folder lmao. If you edit the psp folder's gameList.xml you can make it show up in the UI and play it. It works!
- There's a copy of
youtube-dlin/usr/binlmao. Yeah, that's gonna come in handy on a device with no internet. - libSDL2_ttf is broken and cannot load font files because they shipped the wrong version. Awesome. In order to build software for this thing with libsdl2_ttf, you have to ship your own version lol.
- DONE: Get an interactive terminal emulator working. I have the code written and compiling for ARM, but SDL is being rude and not loading fonts.
- Once thats figure out, write a quick guide for writing+compiling golang/SDL2 homebrew for this thing.
- Fix the SD card partition. This is probably harder than it seems. Some early boot process requires that the SD card be formatted the way it is, so we can't just repair the overlapping regions and call it a day. We'll have to find out where the system mounts volumes early on and set it. This might be on the built-in flash, which is going to be risky to touch and hard to work with.
- DONE: [It's an allwinner w/ 512mb ram]. Fetch actual hardware IDs from the kernel. I'm still not 100% sure which SoC this is
- Wile I don't think I can get PortMasters working on this thing properly, it's theoretically possible to run any 32 bit portmasters games provided the dependencies are all met and can be compiled to 32 bit arm. Sort this out, maybe start a
portmasters32project or something. - Stardew Valley has a 32 bit build apparently ??? It probably won't support mods, but the base game should still launch. The mono runtime can be compiled to 32 bit as well, so I can't really see any reason why it' won't work.
- Override the horrible front-panel LEDs. There should be no LEDs when the screen is on. When the screen turns off, then the LEDs can be turn on to indicate device-is-on. I'll have to find the systemd service or program that manages this.
- Rebuild the OS. This would be an incredibly tedious and long process and I probably won't do it unless I find schematics of the motherboard. (EDITOR'S NOTE: i'm doing it lmao)
The USB OTG port is pretty broken.
Plugging a device into it is a detected event in the kernel, but it doesn't seem to want to actually supply 5v.
dmesg runs a routine to start
sunxi_usb_host0which seems good...It attempts to "turn on 5V power" by running
axp_gpio_set_data....gpio4:1(which flips GPIO4 to HIGH)And then 4 seconds later it automatically runs the
sunxi_hcd0_soft_disconnectroutine and flips it back to 0Weird charging behaviour:
If I plug a USB-C->USB-C cable into my my computer's USB-C port and the other end into the GA36's OTG port, nothing happens. No dmesg.
BUT
if if I plug a USB-A->USB-C cable into my computer's USB-A port and the C end into the OTG port on the GA36, the GA36 starts charging.
The funny thing is:
Charging normally with the DC port does the following:
wake_lockmessage in dmesg/sys/class/gpio_sw/PG13/data))But charging via A->C cable on the OTG port:
wake_lockmessage in dmesgI have no idea what kinda shit they're doing behind the scenes to make that happen but I thought it was funny.