Thanks to Omegamoon, who found it, here is the full RK3066 Technical Reference Manual, 1142 pages and 26MB of completely necessary data for opensource development on this platform.
https://www.dropbox.com/s/80ubbvgou4g3bmk/Rockchip%20RK30xx%20TRM%20V2.0.pdf
It is the same file found in chinese websites and named as "Rockchip RK30xx TRM V2.0.pdf"
And here is the full folder shared with more RK29 and RK30 documents:
https://www.dropbox.com/sh/pycam3nl5bahwjt/WkfqGz6BVp
Enjoy!
Tuesday, June 18, 2013
Monday, June 17, 2013
Measy U2C HW serial console pins
A hardware serial console is a little module soldered to at least two pin pads of a CPU (in this case the RK3066 of the Measy U2C stick) in order to transmit to a PC the stick's boot log sequence happening long before the screen turns on.
Naturally, if a kernel (like the latest one) refuses to boot and does not even get to turn on the screen, the only way to debug the reason is to use the serial console.
With the indications and the useful blogpost (for MK808) of fellow developer Omegamoon, I set out to find the two pins necessary to watch in my PC the boot sequence, that is:
- TXD: the pin where the CPU outputs the console text
- Ground: the necessary reference for the electrical levels in TXD
These had to be connected to the RXD and GND pins, respectively, of a hardware serial-to-USB module, that is then plugged to a PC's USB port. If anybody wonders about the CPU's RXD pin, it is not necessary unless you want to send commands to the stick once it's booted.
In the PC I myself use Ubuntu's CuteCom console app, connecting to serial port /dev/ttyUSB0 at 115200 bauds 8 bits data, 1 bit stop, no parity, and no handshake.
The way in which I found the RK3066's TXD pin was by trial and error. But since I saw there were small circular pads around the same area where Omegamoon had found his stick's TXD/RXD, I supposed mine should be close.
Hence, I first soldered the ground cable to the micro USB port on top of the RK3066 CPU and started very carefully making the serial-to-USB module's RXD pin's cable touch the different pads while powering on the stick, until I found the one that was transmitting data: TXD and proceeded to solder the cable and make the smallest possible hole in the Measy U2C's enclosure to get the two cables out of it while closed.
For reference, these are the places where the cables to the serial-to-USB are soldered
The TXD pad looks tiny but with a bit of care and a little bit of solder tin on the cable tip and the solder tip, you'll get good results.
Naturally, if a kernel (like the latest one) refuses to boot and does not even get to turn on the screen, the only way to debug the reason is to use the serial console.
With the indications and the useful blogpost (for MK808) of fellow developer Omegamoon, I set out to find the two pins necessary to watch in my PC the boot sequence, that is:
- TXD: the pin where the CPU outputs the console text
- Ground: the necessary reference for the electrical levels in TXD
These had to be connected to the RXD and GND pins, respectively, of a hardware serial-to-USB module, that is then plugged to a PC's USB port. If anybody wonders about the CPU's RXD pin, it is not necessary unless you want to send commands to the stick once it's booted.
In the PC I myself use Ubuntu's CuteCom console app, connecting to serial port /dev/ttyUSB0 at 115200 bauds 8 bits data, 1 bit stop, no parity, and no handshake.
The way in which I found the RK3066's TXD pin was by trial and error. But since I saw there were small circular pads around the same area where Omegamoon had found his stick's TXD/RXD, I supposed mine should be close.
Hence, I first soldered the ground cable to the micro USB port on top of the RK3066 CPU and started very carefully making the serial-to-USB module's RXD pin's cable touch the different pads while powering on the stick, until I found the one that was transmitting data: TXD and proceeded to solder the cable and make the smallest possible hole in the Measy U2C's enclosure to get the two cables out of it while closed.
For reference, these are the places where the cables to the serial-to-USB are soldered
![]() |
| TXD pad of RK3066 (to RXD on serial-to-USB) and GROUND on the Micro USB connector |
The TXD pad looks tiny but with a bit of care and a little bit of solder tin on the cable tip and the solder tip, you'll get good results.
Saturday, June 15, 2013
Linux on RK3188 work in progress
Please note this is not a blog post, it's a my personal pastebin where I can put in writing to myself and other fellow developers the small things I find in the latest 3.0.36 kernel that supports rk3188 devices.
Once MALI is configured in as:
And /include/drm/drm.h is backported to rk3x's version, that is, the first:
#if defined(__linux__)
becomes:
#if defined(__KERNEL__) || defined(__linux__)
Then compiling throws this new error:
drivers/gpu/mali/mali/common/mali_kernel_core.c:1084:4: error: implicit declaration of function 'sync_fence_cancel_async'
That function is called because now CONFIG_SYNC is forced by PLAT_RK and should be implemented in /drivers/base/sync.c (see http://lists.linaro.org/pipermail/linaro-mm-sig/2012-June/002050.html) but it's missing.
Hence, since MALI has worked without CONFIG_SYNC and a quick grep of the codebase shows it's the only driver talking about CONFIG_SYNC, my fix for this is removing the dependence with PLAT_RK by going to /arch/arm/Kconfig
and in the config for PLAT_RK commenting the following lines:
# select SYNC
# select SW_SYNC
# select SW_SYNC_USER
and then in the .config removing:
CONFIG_SYNC=y
CONFIG_SW_SYNC=y
CONFIG_SW_SYNC_USER=y
Also had to add this line at the top of /drivers/video/rockchip/rk_fb.c due to missing references to 'GET_UMP_SECURE_ID_BUF2':
#include "mali_def.h"
MALI and CONFIG_SYNC ( sync_fence_cancel_async )
Talking about Omegamoon's codebase (but with backported drivers folder from my previous one)Once MALI is configured in as:
CONFIG_DRM=m
CONFIG_DRM_MALI=m
# CONFIG_ION is not set
CONFIG_MALI=y
CONFIG_MALI400=m
# CONFIG_MALI400_DEBUG is not set
# CONFIG_MALI400_PROFILING is not set
CONFIG_MALI400_UMP=y
CONFIG_UMP=m
# CONFIG_UMP_DEBUG is not set
And /include/drm/drm.h is backported to rk3x's version, that is, the first:
#if defined(__linux__)
becomes:
#if defined(__KERNEL__) || defined(__linux__)
Then compiling throws this new error:
drivers/gpu/mali/mali/common/mali_kernel_core.c:1084:4: error: implicit declaration of function 'sync_fence_cancel_async'
That function is called because now CONFIG_SYNC is forced by PLAT_RK and should be implemented in /drivers/base/sync.c (see http://lists.linaro.org/pipermail/linaro-mm-sig/2012-June/002050.html) but it's missing.
Hence, since MALI has worked without CONFIG_SYNC and a quick grep of the codebase shows it's the only driver talking about CONFIG_SYNC, my fix for this is removing the dependence with PLAT_RK by going to /arch/arm/Kconfig
and in the config for PLAT_RK commenting the following lines:
# select SYNC
# select SW_SYNC
# select SW_SYNC_USER
and then in the .config removing:
CONFIG_SYNC=y
CONFIG_SW_SYNC=y
CONFIG_SW_SYNC_USER=y
Also had to add this line at the top of /drivers/video/rockchip/rk_fb.c due to missing references to 'GET_UMP_SECURE_ID_BUF2':
#include "mali_def.h"
Monday, June 10, 2013
Disassembling .uu files
Quick post to not forget this procedure :)
Let's say we have a .uu file that is a "uu-encoded" (a kind of hex encoding of a binary file) compiled object file, for example:
https://github.com/Galland/rk3x_kernel_3.0.36/blob/master/arch/arm/mach-rk30/ddr.uu
In order to peek into its internals we would have to download it and:
1) Decode the file:
2) Disassemble it with the specific ARM toolchain:
The latest version (4.8) of the Linaro ARM toolchain can be downloaded from this place (thanks Omegamoon):
The result is at dissasembled-ddr.asm and, for the above ddr.uu, can be seen here.
Let's say we have a .uu file that is a "uu-encoded" (a kind of hex encoding of a binary file) compiled object file, for example:
https://github.com/Galland/rk3x_kernel_3.0.36/blob/master/arch/arm/mach-rk30/ddr.uu
In order to peek into its internals we would have to download it and:
1) Decode the file:
uudecode rk3x_kernel_3.0.36/arch/arm/mach-rk30/ddr.uu -o ddr.o
2) Disassemble it with the specific ARM toolchain:
toolchains/android-toolchain-eabi/arm-eabi/bin/objdump -d ddr.o > disassembled-ddr.asm
The latest version (4.8) of the Linaro ARM toolchain can be downloaded from this place (thanks Omegamoon):
The result is at dissasembled-ddr.asm and, for the above ddr.uu, can be seen here.
Friday, May 24, 2013
New 3.0.36+ kernel for Linux on RK3066 devices
The kernel you can find on Picuntu releases is 3.0.8-alok+, but a few weeks ago I found a 3.0.36 kernel for RK devices in github, which was released by Spanish tablet maker bq (support them if you can by buying their devices).
I soon set out to compile it for use with Linux, with some help from fellow developer Omegamoon, who is also doing a great work on OpenELEC XBMC Linux for RK devices.
Then, after adding some of the kernel fixes I've published in previous blogposts (to me the most important is the one that fixes support for 1080p monitors) as well as adding Mali 3D HW acceleration support (thanks Olegk0 for your great work!) I tested this kernel and it's more stable than the previous.
I've also noticed that an issue with USB has disappeared (on kernel 3.0.8 I experienced USB dis-/re-connects very often, which disabled USB devices for several seconds).
Please note that I am so in love with the extreme low power nature of these devices and their noiselessness that I am using my Measy U2C as a "PC stick" and work with it as much as I can (using the excellent lightweight XFCE windows manager), since you can install all the SW in the Ubuntu Software Center plus any other programs can be compiled straight away for ARM from within Picuntu itself (no need for cross-compilers).
All my code changes and fixes are publicly available in my github repositories (in this case here) but, since many people are not too comfortable compiling the kernel from sources, I've decided to release a generic 3.0.36+ image and modules+firmware so you can enjoy too this new level of stability and performance with your Linux.
You can find the 1080p kernel 3.0.36+ for RK3066 recovery image here (compressed with .7z)
and the 720p kernel 3.0.36+ for RK3066 recovery image here (compressed with .7z)
And the modules+firmware here (also .7z to be decompressed in the root folder of your Picuntu MicroSD).
My recommendation is to also install the following enhancements to your MicroSD filesystem:
- Flash support for Chromium web browser
- Mali 3D HW XF86 drivers (the above kernel includes the necessary Mali modules, but to enable them you also need these steps, except the last step of kernel compilation!)
- If you are going to use your stick as a PC, I strongly recommend adding a swap file to avoid "deadlocking" your Linux due to lack of RAM, look for "swap" here
BTW, I've enabled RK903 Wifi driver on the kernel configuration. However, I don't own a stick with the RK903, so I can't test if it works. In any case don't expect Wifi chips that didn't work with previous kernel to work with this one, since nothing has changed there, afaik.
If you find any troubles, I usually answer questions on Miniand's Linux forum, so don't hesitate to post your issues there :)
I soon set out to compile it for use with Linux, with some help from fellow developer Omegamoon, who is also doing a great work on OpenELEC XBMC Linux for RK devices.
Then, after adding some of the kernel fixes I've published in previous blogposts (to me the most important is the one that fixes support for 1080p monitors) as well as adding Mali 3D HW acceleration support (thanks Olegk0 for your great work!) I tested this kernel and it's more stable than the previous.
I've also noticed that an issue with USB has disappeared (on kernel 3.0.8 I experienced USB dis-/re-connects very often, which disabled USB devices for several seconds).
Please note that I am so in love with the extreme low power nature of these devices and their noiselessness that I am using my Measy U2C as a "PC stick" and work with it as much as I can (using the excellent lightweight XFCE windows manager), since you can install all the SW in the Ubuntu Software Center plus any other programs can be compiled straight away for ARM from within Picuntu itself (no need for cross-compilers).
![]() |
| Xubuntu on kernel 3.0.36+ running with Mali 3D on my RK3066 stick |
All my code changes and fixes are publicly available in my github repositories (in this case here) but, since many people are not too comfortable compiling the kernel from sources, I've decided to release a generic 3.0.36+ image and modules+firmware so you can enjoy too this new level of stability and performance with your Linux.
You can find the 1080p kernel 3.0.36+ for RK3066 recovery image here (compressed with .7z)
and the 720p kernel 3.0.36+ for RK3066 recovery image here (compressed with .7z)
And the modules+firmware here (also .7z to be decompressed in the root folder of your Picuntu MicroSD).
My recommendation is to also install the following enhancements to your MicroSD filesystem:
- Flash support for Chromium web browser
- Mali 3D HW XF86 drivers (the above kernel includes the necessary Mali modules, but to enable them you also need these steps, except the last step of kernel compilation!)
- If you are going to use your stick as a PC, I strongly recommend adding a swap file to avoid "deadlocking" your Linux due to lack of RAM, look for "swap" here
BTW, I've enabled RK903 Wifi driver on the kernel configuration. However, I don't own a stick with the RK903, so I can't test if it works. In any case don't expect Wifi chips that didn't work with previous kernel to work with this one, since nothing has changed there, afaik.
If you find any troubles, I usually answer questions on Miniand's Linux forum, so don't hesitate to post your issues there :)
Thursday, April 18, 2013
Compiling the Mali HW accelerated driver (xf86-video-fbdev for RK3066)
Expert Linux developer olegk0 has made a framebuffer driver for the RK30 HDMI with Mali acceleration (rk30fb_drv.so). You can just download and use his .so to have 3D acceleration, or you can follow these instructions to compile it yourself and help debug it.
Among other things, like 2D/3D, it allows playing fullscreen videos with far less CPU usage, leaving the processor just for what your app requires to decode the videos. With "app" I mean Parole, VLC or, my strong recommendation, the excellent commandline utility: mplayer (which immediately takes advantage of the HW acceleration).
The downside is that it still has some bugs, like turning everything in the screen black (except the played video). Just move the mouse or a window around and everything gets redrawn again.
Another bug is that the video output becomes mangled when the video window touches the left or right sides of the screen.
In any case I love to be able to watch movies/videos on this stick with Linux, so what I do is open a terminal and type:
mplayer whatever-video.aviAnd screen turns black except the video, I move the mouse a bit around (which causes the black parts to be redrawn) to find the corners of the mplayer video window and make it big enough to cover most of the screen, just without touching either left or right sides of the screen.
In any case, if you would like to give us a helping hand debugging the XVideo implementation (my suspect is ./xf86-video-fbdev/src/video.c) just follow these steps to tinker with the code and compile the driver to see the changes:
git clone git://github.com/olegk0/xf86-video-fbdev.git
sudo apt-get install xserver-xorg-dev
We must then fix a dangling symlinked folder at "./xf86-video-fbdev/src/ump" pointing to "../../../../../r3p1/ump/include/ump"
So go to http://malideveloper.arm.com/develop-for-mali/drivers/open-source-mali-gpus-ump-user-space-drivers-source-code-2/ and download the same revision (r3p1, until we get a first working driver; then we can try with a newer version), that is: Linux Kernel Device Driver r3p1-01rel1
At the time of writing this is located at: http://malideveloper.arm.com/downloads/DX910-SW-99006-r3p1-01rel1.tgz
Copy or symlink the uncompressed folder "./DX910-SW-99006-r3p1-01rel1/driver/src/ump/include/ump" to "./xf86-video-fbdev/src/ump"
And now just do:
./configure --prefix=/usr
make
sudo make install
There is a lot of debug information printed on /var/log/syslog every time you play a video with mplayer, which should help in the debugging.
Tuesday, April 16, 2013
3D HW acceleration on Picuntu Linux (Mali400)
I have ported olegk0's kernel (https://github.com/olegk0/rk3066-kernel) updates and Mali driver to Picuntu on my Picuntu kernel branch (https://github.com/Galland/picuntu-3.0.8-alok https://github.com/Galland/rk3x_kernel_3.0.36).
I'm testing and it seems very stable.
Please note that Mali is the GPU on the RK3066, responsible for 2D/3D acceleration, not for HW video en/decoding! That's done by the VPU core, which is still unsupported.
Please note that, afaik, all of this is work done by olegk0 (see [1]) and I have just checked it does work on our Picuntu, so all cheers go to him, thanks for the great work, olegk0!
If you would like to test this too, grab my github kernel and follow the instructions on [1] or these Picuntu-targeted instructions here:
1) Get xorg.conf and place it on your Picuntu MicroSD's folder /etc/X11/
2) Get rk30fb_drv.so (or compile it yourself) and place it on your Picuntu MicroSD's folder /usr/lib/xorg/modules/drivers/
3) Modify /etc/rc.local by commenting (precede with #) existing lines that use "fbset" and adding the following new lines:
fbset -rgba 8/16,8/8,8/0,8/24 -a
chmod 666 /dev/mali /dev/ump
4) Modify /etc/modules to add the following lines:
rk29-ipp
ump
disp_ump
mali
drm
mali_drm
5) Get the mali package, uncompress and install this file: mali400_2.1-13_armhf.deb
6) Run the following commands:
sudo mv /usr/lib/arm-linux-gnueabihf/mesa-egl/ /usr/lib/arm-linux-gnueabihf/.mesa-egl/
Then if you enter: ll /usr/lib | grep libMali
The output should look something like this:
lrwxrwxrwx 1 root root 19 abr 16 17:58 libEGL.so -> /usr/lib/libMali.so
lrwxrwxrwx 1 root root 10 feb 22 02:06 libEGL.so.1.4 -> libMali.so
lrwxrwxrwx 1 root root 19 abr 16 17:58 libGLESv1_CM.so -> /usr/lib/libMali.so
lrwxrwxrwx 1 root root 10 feb 22 02:06 libGLESv1_CM.so.1.1 -> libMali.so
lrwxrwxrwx 1 root root 19 abr 16 17:58 libGLESv2.so -> /usr/lib/libMali.so
lrwxrwxrwx 1 root root 10 feb 22 02:06 libGLESv2.so.2.0 -> libMali.so
-rw-r--r-- 1 root root 731492 feb 22 02:06 libMali.so
LAST STEP : ONLY IF YOU ARE NOT USING KERNEL 3.0.36+
Get my github kernel code (3.0.36+) and compile it, just make sure that you do this too:
- I'm using the Measy U2C stick, which has DDR3 1333 9-9-9 capable memory, but this may not be your case and may cause your system to not boot. So just before compiling ("make -j 4") do "make menuconfig" and get inside "System Type" and there set "DDR Memory Type" to "DDR3 (Type default)" and "DDR SDRAM frequence (in MHz)" [sic] to "333".
- Also please note that my kernel is set to Maximum CPU frequency of 1.6 GHz (instead of 1.2 GHz in stock Picuntu), so use at your own risk!!!!!For added safety you can make your CPU run cooler by setting (in above menuconfig) into "CPU Power Management" --> "CPU Frequency scaling" --> "Default CPUfreq governor" to "conservative" or "powersave", so it will rarely go to high frequencies (but it'll be slower). My CPU does fine with 1.6 GHz without any heatsink, and usually runs at 60-70 ÂșC, with 80+ spikes :S however voltage scaling is known to work on my stick (not on others I fear). I fixed this in current github kernel, so CPU automatically scales down frequency when temperature rises.
- You may also want to check on "Device Drivers" -> "Network device support" -> "Wireless LAN" that your Wifi chip/stick is selected there, for its driver to be compiled. My kernel is, currently, more up to date than others, and as you will see, there is a driver for the RK903 Wifi. However, since I don't own a stick that has it, I haven't been able to test. Please let me know if it works for you :)
- After compiling, you have to do "make modules" too, this is very important!
- Then do "make modules_install" and go to your PC's /lib/modules to grab the full"3.0.8+alok" "3.0.36+" folder and copy it to your Picuntu MicroSD's /lib/modules folder (or just do all this on your Picuntu Linux!!:), then boot up your Picuntu stick and type in a terminal "depmod -a" so it will parse the new modules and restart Picuntu.
- After doing that you can flash the recovery partition with the compiled kernel
This could sound complicated but kernel tinkering is actually pretty straightforward and works! :) Hope it helps and check your temperature with: cat /sys/module/tsadc/parameters/temp*
END OF LAST STEP (only for non 3.0.36+)
It should report >120 fps (I usually get from 120 to 170 fps) with a CPU usage of around 30% for Xorg and just <15% for es2gears.
If that's not the case then double-check above steps and if it still doesn't work, you can, for example, post your questions at Miniand's Picuntu forum, where I try to be of help.
Disclaimer: Use at your own risk!!
If you run into an "Illegal instruction" error or a sudden reboot... your stick needs a heatsink... I spent the whole glmark2-es2 test blowing air to mine!
This is due to my overclocking the GPU from 266 MHz to its limit of 400 MHz, I've undone this in the github kernel too :)
MK808 note: If you have a MK808 you may want to compile olegk0's kernel instead of mine, because MK808 uses a different "LCDC video port" for HDMI output (1 instead of 0), which requires some minor code changes. However my kernel is more up to date (less bugs, less power consumption, etc.) than his, so I must recommend it for other sticks.
Reference
http://www.slatedroid.com/topic/55626-my-version-of-the-linux-kernel-for-mk808/
http://linux-sunxi.org/Binary_drivers
https://www.miniand.com/forums/forums/picuntu-linux/topics/new-kernel-3-0-36-for-picuntu-linux-on-rk3066-released
5) Get the mali package, uncompress and install this file: mali400_2.1-13_armhf.deb
6) Run the following commands:
sudo mv /usr/lib/arm-linux-gnueabihf/mesa-egl/ /usr/lib/arm-linux-gnueabihf/.mesa-egl/
sudo ln -s /usr/lib/libMali.so /usr/lib/libEGL.so
sudo ln -s /usr/lib/libMali.so /usr/lib/libEGL.so.1.4
sudo ln -s /usr/lib/libMali.so /usr/lib/libGLESv1_CM.so
sudo ln -s /usr/lib/libMali.so /usr/lib/libGLESv1_CM.so.1.1
sudo ln -s /usr/lib/libMali.so /usr/lib/libGLESv2.so
sudo ln -s /usr/lib/libMali.so /usr/lib/libGLESv2.so.2.0
Then if you enter: ll /usr/lib | grep libMali
The output should look something like this:
lrwxrwxrwx 1 root root 19 abr 16 17:58 libEGL.so -> /usr/lib/libMali.so
lrwxrwxrwx 1 root root 10 feb 22 02:06 libEGL.so.1.4 -> libMali.so
lrwxrwxrwx 1 root root 19 abr 16 17:58 libGLESv1_CM.so -> /usr/lib/libMali.so
lrwxrwxrwx 1 root root 10 feb 22 02:06 libGLESv1_CM.so.1.1 -> libMali.so
lrwxrwxrwx 1 root root 19 abr 16 17:58 libGLESv2.so -> /usr/lib/libMali.so
lrwxrwxrwx 1 root root 10 feb 22 02:06 libGLESv2.so.2.0 -> libMali.so
-rw-r--r-- 1 root root 731492 feb 22 02:06 libMali.so
LAST STEP : ONLY IF YOU ARE NOT USING KERNEL 3.0.36+
Get my github kernel code (3.0.36+) and compile it
- Also please note that my kernel is set to Maximum CPU frequency of 1.6 GHz (instead of 1.2 GHz in stock Picuntu), so use at your own risk!!!!!
- After compiling, you have to do "make modules" too, this is very important!
- Then do "make modules_install" and go to your PC's /lib/modules to grab the full
- After doing that you can flash the recovery partition with the compiled kernel
This could sound complicated but kernel tinkering is actually pretty straightforward and works! :) Hope it helps and check your temperature with: cat /sys/module/tsadc/parameters/temp*
END OF LAST STEP (only for non 3.0.36+)
Testing 3D acceleration:
Run as a normal user: es2gearsIt should report >120 fps (I usually get from 120 to 170 fps) with a CPU usage of around 30% for Xorg and just <15% for es2gears.
If that's not the case then double-check above steps and if it still doesn't work, you can, for example, post your questions at Miniand's Picuntu forum, where I try to be of help.
Disclaimer: Use at your own risk!!
If you run into an "Illegal instruction" error or a sudden reboot... your stick needs a heatsink... I spent the whole glmark2-es2 test blowing air to mine!
This is due to my overclocking the GPU from 266 MHz to its limit of 400 MHz, I've undone this in the github kernel too :)
Reference
http://www.slatedroid.com/topic/55626-my-version-of-the-linux-kernel-for-mk808/
http://linux-sunxi.org/Binary_drivers
https://www.miniand.com/forums/forums/picuntu-linux/topics/new-kernel-3-0-36-for-picuntu-linux-on-rk3066-released
Subscribe to:
Posts (Atom)

