RK3566 EBC Reverse-Engineering

The RK3566 SoC, used in the Quartz64 SBC by PINE64, contains an eInk interface. This is referred to as ebc by Rockchip apparently.

Unfortunately, the driver published for this eInk interface within the BSP kernel is an assembly dump produced by gcc. Fortunately, it contains quite a bit of debug information, which we can use to reverse engineer it.

Sources

The ebc driver source is available from the quartz-bsp repository.

The file of interest is ebc_dev_v8.S, which implements a DRM (Direct Rendering Manager) driver for the eInk panel.

Documentation

Assembly Syntax and Semantics

The Syntax is GNU Assembler (GAS) syntax. This modexp article provides a good introduction to the syntax, calling convention, semantics and some often used instructions.

The ARM Architecture Reference Manual for ARMv8 should be used as reference for any instructions.

At the very least, you should read up on the registers and calling convention used.

Debug Information

Quite a bit of debug info is left in the assembly dump, including function names, file names and line numbers. We can take this to our advantage.

.file file-number file-path

Specifies a number to reference a file by, and its path. All following code until the next .file or .loc statement are to be understood as originating from this file. This is particularly useful to understand which code has been inlined from other files, for which the source is available.

.loc file-number line-number 0

Specifies that the following code is generated from line-number stemming from file number file-number. See the .file directive for this file number to understand which source file it came from.

.type function-name, %function

This tells us that the following code belongs to function function-name. You'll usually see a .cfi_startproc, which signifies the start of the function code, until the matching .cfi_endproc.

A quick grep for %function shows that we are dealing with 30 functions in this file.

.type struct-name, %object

This seems to signify a definition of a C struct named struct-name.

A quick grep for %object shows that we are dealing with around 27 structs in this file.

.Ldebug_info0:

TODO: Wtf is this label, why does it have so much data? Does this contain function headers and struct member definitions, among other things? That'd be cool.