Development Information for Anbernic RG35XXSP

Introduction:

I received an Anbernic RG35XXSP in the mail the other day, and wanted to write a quick post about how I extract the information necessary to do mainline development on these devices. While schematics would be extremely helpful (and arguably the best way to get information about a device), it's not always the only way.

First Steps:

Obviously, the first thing you do when you receive a device is test it to make sure it's operating correctly. I checked the audio, buttons, and screen and everything appears to be working as it should.

Once I've confirmed working hardware, the next thing I need to do is get serial access to the console. When taking apart a device the serial connector is almost always very conspicuous, and the RG35XXSP is no exception. Once I remove the back cover I see 4 pinholes on the bottom right corner that are obviously a serial port.

The only question I have at this point is "which one is ground", because serial almost always goes power, tx/rx, rx/tx, ground (the tx/rx polarity we can figure out with trial and error). When I pull out my multimeter though, I notice both the first and 4th pins give me 0 ohms to ground which is odd. I power on the device and try to measure the voltage of each of the 4 pins. The 1st and 4th give me 0v and still are 0 ohms to ground, whereas pins 2 and 3 read 3.2v. At this point I'm just going to trust that pin 1 is ground and pins 2/3 are tx/rx (or rx/tx, we'll figure that part out later).

The front of the board for good measure.

My horrible soldering job on pin 1 suggests I guessed correctly on the ground pin. Since it's attached to the ground plane, the ground plane basically acted as a giant heatsink ensuring I couldn't get it hot enough to flow the solder well. Maybe next time I'll use more flux, for now though this should get me started.

After connecting my serial device to the board, I get a boot console. From there, I'm able to access the boot log as well as the values listed in /sys/kernel/debug for the regulators, the GPIO pins, the pinmuxing, and the clock frequencies which is most of what I should need.

The Device Tree:

That's everything but the most important part. Time to get the device tree. To get this, I'll need to extract it from the factory firmware. I shut down the handheld and take the SD card out, then put it in my computer. First I run sudo fdisk -l and get the partition layout as shown:

Disk /dev/sdc: 57.96 GiB, 62239277056 bytes, 121561088 sectors

Disk model: 1081CS0

Units: sectors of 1 * 512 = 512 bytes

Sector size (logical/physical): 512 bytes / 512 bytes

I/O size (minimum/optimal): 512 bytes / 512 bytes

Disklabel type: gpt

Disk identifier: AB6F3888-569A-4926-9668-80941DCB40BC

Device         Start       End  Sectors  Size Type

/dev/sdc1      73728  96542719 96468992   46G Microsoft basic data

/dev/sdc2   96542720  96608255    65536   32M Microsoft basic data

/dev/sdc3   96608256  96641023    32768   16M Microsoft basic data

/dev/sdc4   96641024  96772095   131072   64M Microsoft basic data

/dev/sdc5   96772096 113549311 16777216    8G Microsoft basic data

/dev/sdc6  113549312 120879103  7329792  3.5G Microsoft basic data

I'm going to first start digging through the partitions one by one looking for something of interest. Let's start first by mounting each one. Remember, we're looking for a file that ends in .dtb. Partition 1 looks like it just has our ROMs and stuff on it, and partition 2 has various logos and whatnot. Partition 3 however fails to mount, so let's do a simple hex dump with xxd and see if anything looks important.

00000000: e1fa 1062 0065 6172 6c79 7072 696e 746b  ...b.earlyprintk

00000010: 3d73 756e 7869 2d75 6172 742c 3078 3035  =sunxi-uart,0x05

00000020: 3030 3030 3030 0069 6e69 7463 616c 6c5f  000000.initcall_

00000030: 6465 6275 673d 3000 636f 6e73 6f6c 653d  debug=0.console=

00000040: 7474 7953 302c 3131 3532 3030 006e 616e  ttyS0,115200.nan

That looks like a u-boot environment. I didn't see anything else of import though in that partition, so time to keep digging. Partition 4 fails to mount, so let's do the same xxd and see what it looks like.

00000000: 414e 4452 4f49 4421 0848 0901 0000 0840  ANDROID!.H.....@

00000010: e2ca 2700 0000 0042 0000 0000 0000 f040  ..'....B.......@

00000020: 0001 0040 0008 0000 0200 0000 0000 0000  ...@............

00000030: 7375 6e35 3069 5f61 726d 3634 0000 0000  sun50i_arm64....

00000040: 0000 0000 0000 0000 0000 0000 0000 0000  ................

That's an Android boot image. If our device tree is going to be anywhere, it's in there somewhere. Let's extract that partition so we can examine it in closer detail. I do that by doing the following command: sudo dd if=/dev/sdc4 of=boot.img bs=1M. Now I'm going to run binwalk over it and see if I can locate anything that looks like a device tree. I run binwalk boot.img and here are the results:

DECIMAL       HEXADECIMAL     DESCRIPTION

--------------------------------------------------------------------------------

0             0x0             Android bootimg, kernel size: 17385480 bytes, kernel addr: 0x40080000, ramdisk size: 2607842 bytes, ramdisk addr: 0x42000000, product name: "sun50i_arm64"

2048          0x800           Linux kernel ARM64 image, load offset: 0x80000, image size: 17977344 bytes, little endian, 4k page size,

9472000       0x908800        ELF, 64-bit LSB shared object, version 1 (SYSV)

9491552       0x90D460        gzip compressed data, maximum compression, from Unix, last modified: 1970-01-01 00:00:00 (null date)

9804512       0x959AE0        DES SP2, little endian

9804768       0x959BE0        DES SP1, little endian

9807888       0x95A810        LZO compressed data

9810688       0x95B300        CRC32 polynomial table, little endian

10385439      0x9E781F        Boot section Start 0x1F00 End 0x0

11843031      0xB4B5D7        mcrypt 2.2 encrypted data, algorithm: blowfish-192, mode: CBC, keymode: 8bit

11941261      0xB6358D        Unix path: /dev/vc/0

12055203      0xB7F2A3        xz compressed data

12096451      0xB893C3        Unix path: /sys/class/hdmi/hdmi/attr/reg_dump

12096491      0xB893EB        Unix path: /sys/class/hdmi/hdmi/attr/reg_dump

12140572      0xB9401C        Unix path: /sys/class/deinterlace/deinterlace/client

12141302      0xB942F6        Unix path: /sys/class/deinterlace/deinterlace/debug

12159297      0xB98941        Unix path: /lib/firmware/updates/4.9.170

12204386      0xBA3962        Unix path: /dev/block/nand0

12401961      0xBD3D29        Unix path: /dev/block/by-name/UDISK

12472101      0xBE4F25        Unix path: /sys/firmware/devicetree/base

12473153      0xBE5341        Unix path: /sys/firmware/fdt': CRC check failed

12545359      0xBF6D4F        Neighborly text, "neighbor table overflow!s %x"

12603776      0xC05180        Neighborly text, "NeighborSolicitss"

12603793      0xC05191        Neighborly text, "NeighborAdvertisementscmp6OutMsgs"

13478496      0xCDAA60        gzip compressed data, maximum compression, from Unix, last modified: 1970-01-01 00:00:00 (null date)

16624072      0xFDA9C8        AES S-Box

16793171      0x1003E53       Intel x86 or x64 microcode, pf_mask 0x00, 1919-19-19, rev 0x19190000, size 257

16976367      0x10309EF       Intel x86 or x64 microcode, pf_mask 0x8000, 2000-01-20, size 18882560

17331495      0x1087527       mcrypt 2.2 encrypted data, algorithm: blowfish-448, mode: CBC, keymode: 8bit

17389568      0x1095800       gzip compressed data, from Unix, last modified: 2024-05-07 15:28:13

19998720      0x1312800       Flattened device tree, size: 137675 bytes, version: 17

27683655      0x1A66B47       Certificate in DER format (x509 v3), header length: 4, sequence length: 21569

28815300      0x1B7AFC4       LZMA compressed data, properties: 0x6E, dictionary size: 134217728 bytes, uncompressed size: 2569 bytes

35825492      0x222A754       Cisco IOS microcode, for ""

61820296      0x3AF4D88       Intel x86 or x64 microcode, sig 0x00001e27, pf_mask 0x70301, 1E1D-06-24, rev 0x0009, size 2

61902588      0x3B08EFC       Intel x86 or x64 microcode, sig 0x00001e27, pf_mask 0x70301, 1E1D-06-24, rev 0x0009, size 2

61985604      0x3B1D344       Intel x86 or x64 microcode, pf_mask 0x11091008, 1D30-11-37, rev 0x111f1c1f, size 42

63798241      0x3CD7BE1       LZMA compressed data, properties: 0x63, dictionary size: 0 bytes, uncompressed size: 170 bytes

63901528      0x3CF0F58       Boot section Start 0x423A3A3A End 0x42

63901532      0x3CF0F5C       Boot section Start 0x42 End 0x0

64034946      0x3D11882       MySQL MISAM index file Version 3

64062964      0x3D185F4       Boot section Start 0x3FE2E2E2 End 0xB2943F

64063071      0x3D1865F       Boot section Start 0x0 End 0x0

65356406      0x3E54276       MySQL MISAM index file Version 11

66013846      0x3EF4A96       MySQL MISAM compressed data file Version 11

I see a "Flattened device tree" at 19998720. That's what we need. Let's extract it. Note the skip and the size. Use the following command (the skip is the device tree location, and the size is the size in bytes of the device tree).

dd if=boot.img of=tree.dtb bs=1 skip=19998720 count=137675

Now that we have the tree saved as tree.dtb, let's decompile it so we can see everything we need. Use the following command. dtc -I dtb -O dts -o rg35xxsp.dts tree.dtb

Conclusion:

We now have what we need to continue development on this device, and you can find all the boot logs and the decompile device tree at the following gist on Github. The H700 is still a bit early in its bringup, so it will still be a few months before we can have a fully working mainline kernel on this device. But we will some day!