Main Device Links

Porting CM to SurfTab Ventos / rk3066 – Work In Progress

Project end.

Sorry to say that but I simply lost interest and I’m not hacking Android anymore :P

I’m also removing the image rescue images because they are producing way too much traffic.

15.02.2013 Static Fbset Version For Checking Framebuffer Format

I did not have any time to follow up on Rockchip hacking, so there aren’t much news on that topic. I figured out that some tablets seem to have a hacked init
binary that must be doing something special. I prepared an image for one user
from Korea and it only more or less worked when I used the init binary from his original recovery image.

Recently I started to receive requests about TWRP for rk3066 tablets with Retina displays, I have contact with a few guys who are trying to figure out how to get it to work. So far they tried my precompiled recoveries, but without success, I believe that Retina might have a different pixel format?

So here’s the statically linked fbset version that should work on the arm7 tablets, the -i parameter should hopefully give you some useful information.

08.01.2013 TWRP Recovery for SurfTab Ventos 10.1 – untested

Today I received a stock recovery image for the Ventos 10.1 and was asked if I could compile a recovery for the 10.1 tablet. I created another configuration for the 10.1 model (still have to polish and push it) and did build an image for it, however, I do not have this tablet so the image is absolutely untested. If you like you can download the TWRP recovery image for the TrekStor Ventos SurfTab 10.1 / rk3066 tablet here / md5 ecd7ebc0951b7118bf853c352bb35542. As mentioned – it’s untested, try it at your own risk.

03.01.2013 TWRP Recovery for SurfTab Ventos 9.7

After playing around with CWM I figured that I did not like it that much and got a hint to look at TWRP. Turned out the hint was a good one, I got TWRP running easily, just had to apply the same patch that I already did for CWM, rest worked almost out of the box. So, for those who want to test, here’s a TWRP recovery image for the TrekStor Ventos SurfTab 9.7 / rk3066 tablet / md5 ec3c7eedb8794073d4a2dd711b142854. As always – no warranties of any kind, try it at your own risk.

Here are some pictures:


02.01.2013 More Fixes To CWM Recovery Image

I got some things explained on IRC, so basically it goes like this: /sdcard is indeed the internal flash, /external_sd is the external SD card. So I fixed my recovery.fstab once again and was presented with an option to backup to the external SD card which seemed to work. Here is a CWM recovery image for the TrekStor Ventos SurfTab 9.7 / rk3066 tablet with the lates fixes / md5 edcb8f057714214db10feebaa9895156.

02.01.2013 Minor Fixes To CWM Recovery Image

Today I did a little bit more digging and found out that my recovery.fstab is slightly wrong. /sdcard is supposed to be the first partition on the external SD card, and /sd-ext is supposed to be the second partition on the external SD card. I however mapped /sdcard to the user partition in internal flash, because the original firmware used /mnt/sdcard for the user partition and /mnt/external_sd for the actual SD card.

Here is a CWM recovery image for the TrekStor Ventos SurfTab 9.7 / rk3066 tablet with fixed recovery.fstab. Again, no warranties of any kind.

02.01.2013 Testing First CWM Image

Today I made some good progress, basically I rewrote parts in CWM recovery that were using the MEMERASE ioctl and did the same as the stock recovery executable: used write() to dump a bunch of 0×00 intead of real erasing.

This worked out quite well and I finally got a sort of working CWM recovery. One thing that was not right – it expected mount points at root level while I had the /mnt/ path prepended to it, so when I tried to make a backup it complained about not finding /sdcard. That was an easy fix in recovery.fstab and after that doing a backup actually worked. Here are some shots, sorry for the quality:


I never used CWM recovery before so I have no clue how it is actually supposed to work. I can mount and unmount various partitions/devices (except USB), but it is never asking me where the backup should go, it always picks /sdcard. For instance, I’d like it to be on the external SD card or to a USB stick, how would I do that?

I do not know if this is not one of CWMs features or if it’s some badness in my build, that I will have to find out.

It also refused to mount my USB stick, I hoped for some errors in the log that might help, but there was nothing there. I tried to figure out what I need to put into recovery.fstab to be able to mount a usb stick, but I could not.

If you are an experienced dev/user and would like to test, you can try out my first CWM recovery image for the TrekStor Ventos SurfTab 9.7 / rk3066 tablet. If you do – as always, you do so at your own risk! It works for me, but it does not mean that it will work for you, if it somehow manages to brick your device: I’m not responsible.

Make sure to check the md5 sum before flashing: 51f64a5b800a8f7013fcbe252abfac2d

I flash it under Linux using rkflashtool like this (check your partition addresses!):

rkflashtool w 0x00010000 0x00008000 < jin_alphatest01_surftab_ventos_9.7_cwm_6.0.2.7.img

I’d be happy to have some feedback from someone who actually knows how CWM recovery is supposed to behave, so that I can fix any remaining issues.

I’ll continue testing in the coming days and will try to get my changes merged upstream.

31.12.2012 More CWM Recovery Debugging

I continued to dig around and traced down the failing call: ioctl(fd, MEMERASE, &erase_info) in mtdutils.c is the one that never returns, most likely due to some kernel bug. I was curious how the stock recovery executable is dealing with this, so I cross compiled strace and launched the stock recovery program:

open("/dev/mtd/mtd1", O_RDWR|O_LARGEFILE) = 13
lseek(13, 0, SEEK_CUR)                  = 0
write(13, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 16384) = 16384
lseek(13, 0, SEEK_CUR)                  = 16384
write(13, "boot-recovery\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 16384) = 16384
lseek(13, 0, SEEK_CUR)                  = 32768
write(13, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 16384) = 16384
lseek(13, 0, SEEK_CUR)                  = 49152
close(13)                               = 0

It was not using the MEMERASE ioctl, instead it was using write() on the misc partition. My assumption is, that they ran into the same problem and implemented a workaround. The only flash related ioctl that they use is MEMGETINFO.

As the next step I will try to rewrite those parts in CWM recovery so that I avoid the ioctl that is failing, let’s see how that goes.

30.12.2012 Debugging CWM Recovery

Today I tried to figure out why I do not see anything on the screen. My assumption was that there is something wrong with the framebuffer so I digged in that direction. Turned out – I was wrong. The graphic routines work just fine, the problem is elsewhere. Remember the “task recovery:78 blocked for more than 120 seconds.” paste from yesterday, the one with the mtd_ioctl errors? That’s the actual problem!

In main() recovery.c is calling get_args(&argc, &argv); to retrieve some arguments. One part of it tries to read and write the misc partition on mtd and that’s where things seem to go wrong. Surprisingly, there are no errors in recovery.log, but I suspected the problem somewhere in get_bootloader_message_mtd() in bootloader.c. That wasn’t it though, it hangs in set_bootloader_message_mtd() when it is calling mtd_write_close(), this function never returns.

So next I have to look at mtdutils to figure out what exactly is failing there…

29.12.2012 Analyzing CWM Recovery Image

Now that I was able to boot my CWM recovery image, it was time to investigate why the cwm recovery was not working. The image actually boots, but the screen stays black, adb shell access is possible.

Let’s have a look at recovery.log:

~ # cat /tmp/recovery.log 
Starting recovery on Sat Dec 29 02:20:16 2012
framebuffer: fd 5 (1024 x 768)
CWM-based Recovery v6.0.1.9
recovery filesystem table
=====================
  0 /tmp ramdisk (null) (null) 0
  1 /mnt/sdcard vfat /dev/block/mtd/by-name/user (null) 0
  2 /mnt/external_sd vfat /dev/block/mmcblk0p1 /dev/block/mmcblk0 0
  3 /system ext4 /dev/block/mtd/by-name/system (null) 0
  4 /cache ext4 /dev/block/mtd/by-name/cache (null) 0
  5 /data ext4 /dev/block/mtd/by-name/userdata (null) 0
  6 /misc mtd misc (null) 0
  7 /boot mtd boot (null) 0
  8 /recovery mtd recovery (null) 0
  9 /backup mtd backup (null) 0
W:Unable to get recovery.fstab info for /datadata during fstab generation!
W:Unable to get recovery.fstab info for /emmc during fstab generation!
W:Unable to get recovery.fstab info for /sdcard during fstab generation!
W:Unable to get recovery.fstab info for /sd-ext during fstab generation!
I:Completed outputting fstab.
I:Processing arguments.

Why are all mounts logged as “null”? Not sure what that means, because cache is actually mounted:

~ # mount
rootfs on / type rootfs (rw)
tmpfs on /dev type tmpfs (rw,nosuid,relatime,mode=755)
devpts on /dev/pts type devpts (rw,relatime,mode=600)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
/dev/block/mtd/by-name/cache on /cache type ext4 (rw,nodev,noatime,nodiratime,barrier=1,data=ordered)

And it does contain the recovery directory, so that seems to be OK:

./recovery/last_install
./recovery/last_log

Another interesting part is in dmesg, it seems that the recovery process has trouble accessing flash:

<3>[  241.090294] INFO: task recovery:78 blocked for more than 120 seconds.
<3>[  241.096757] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
<6>[  241.104686] recovery        D c092f5c8     0    78      1 0x00000000
<4>[  241.111305] [<c092f5c8>] (__schedule+0x6d0/0x79c) from [<c06d8bd8>] (mtd_ioctl+0x43c/0xad8)
<4>[  241.119783] [<c06d8bd8>] (mtd_ioctl+0x43c/0xad8) from [<c06d92a0>] (mtd_unlocked_ioctl+0x2c/0x44)
<4>[  241.128897] [<c06d92a0>] (mtd_unlocked_ioctl+0x2c/0x44) from [<c05a1a70>] (do_vfs_ioctl+0x500/0x57c)
<4>[  241.138203] [<c05a1a70>] (do_vfs_ioctl+0x500/0x57c) from [<c05a1b20>] (sys_ioctl+0x34/0x54)
<4>[  241.146921] [<c05a1b20>] (sys_ioctl+0x34/0x54) from [<c04f4c00>] (ret_fast_syscall+0x0/0x30)

I was also interested in the framebuffer, you might remember that the screen stayed black. I figured it might be helpful to run fbset -i to get some info. At first I tried to cross compile fbset using the toolchain that comes with Android, but this was not easily possible, system headers are spread all over the place, it was just chaos and pain all the way. Then I received a hint that I do not really have to use the Android toolchain – it just had to be a gcc that would spit out arm7 binaries.

Usually I roll my embedded linux distros with OpenEmbedded, so naturally that was my first choice when it came to building an arm7 toolchain. I went with the Yocto Project, got my toolchain and cross compiled fbset. Actually, I could have simply cross compiled fbset using OE but that came to my mind later, when the toolchain was already done.

Here is the framebuffer information:

/tmp # ./fbset -i -fb /dev/graphics/fb2
mode "1280x720-60"
    # D: 74.250 MHz, H: 45.000 kHz, V: 60.000 Hz
    geometry 1280 720 1280 720 16
    timings 13468 220 110 20 5 40 5
    nonstd 4
    rgba 5/11,6/5,5/0,0/0
endmode
Frame buffer device information:
    Name        : fb2
    Address     : 0x90000000
    Size        : 8388608
    Type        : PACKED PIXELS
    Visual      : TRUECOLOR
    XPanStep    : 1
    YPanStep    : 1
    YWrapStep   : 0
    LineLength  : 0
    Accelerator : No

It’s the same for fb0 btw, only the address differs. Only fb0 seems to produce visible output, not sure where fb2 is going.

I did not specify any TARGET_RECOVERY_PIXEL_FORMAT in my BoardConfig.mk which to my knoweldge means that 565 will be used (BGRA_8888 and RGBX_8888 have their own defines, then it #else’s to RGB_565. I also tried the BOARD_HAS_JANKY_BACKBUFFER option, but it did not do anything for me.

By looking at the recovery.c sources I can see that “I:Processing arguments.” log output comes way after UI initialization, so in theory I should be seeing something on the screen.

As the next step I will add more debug output to the recovery application and try to figure out what is going on.

23.12.2012 Analyzing Stock Recovery Image

For now my primary interest lies with the recovery partition, as the first step I’d like to get CWM running on my device. I could unpack the recovery partition without problems using abootimg and unpackbootimg (latter comes with mkbootimg as part of the Android sources) but reassembling the image did not work out that well – the image did not boot.

The image needed the following parameters:

pagesize = 0x4000
kerneladdr = 0x60408000
ramdiskaddr = 0x62000000
secondaddr = 0x60f00000
tagsaddr = 0x60088000

Turned out that mkbootimg misses a few things – support for page size of 16384, parameter for second address (probably not needed but I added it anyway), parameter to specify the tags address. However that was still not enough – the image refused to boot. After comparing the original recovery dump and my reassembled image of the unpacked original recovery, I could see that the difference lies in the checksum of the image, it was simply different. I asked a friend of mine, Bertl, for help and he found out that I actually reinvented the wheel with my mkbootimg fixes. He found a repo at github from a user naobsd and it seems that naobsd already went through all this. Here is naobsd’s mkbootimg github repo which contains the important line that allows correct checksumming.

Bertl also added a patch to mkbootimg so that it can be compiled with OpenSSL which is quite useful if you want to build it outside the Android tree. He also added a check for the correct checksum to the unpackbootimg utility, which might be quote useful to detect corrupt images.

Finally, I added some an autotools build environment so that it is easier to compile without Android, but also adapted the sources in a way so that a build within the Android tree would also work (this is not yet tested though).

Have a look at my mkbootimg for rk3066 repo, it contains all the changes described above.

Now, that image generation worked, I could finally repack my compiled CWM recovery and try to boot it.

I used the following commands to do so:

Generate the proper image:

~/Work/Android/github/rk3066-mkbootimg/mkbootimg --kernel kernel \
    --ramdisk ramdisk-recovery.img --base 0x60400000 --pagesize 16384 \
    --ramdiskaddr 0x62000000 --tagsaddr 0x60088000 --secondaddr 0x60f00000 \
    -o cwm.img

Flash it (this needs to be done as root):

rkflashtool w 0x00010000 0x00008000 < cwm.img

Reboot tablet:

rkflashtool b

Once it’s up, reboot into recovery:

adb reboot recovery

The result is… well. Not an epic fail but no reason for too much joy either. Screen stays black, however adb gets started and connecting via adb shell is possible. A deeper analysis of what we have at this point will follow.

Someday… First CM Configuration

Not so long ago, but before I started writing down my findings I created a CM configuration for rk3066. I looked at this git repo as a sample and tried to come up with something similar for my device.

I am still learning on how to do things on Android so I did not get very far. However I have something that will compile a recovery image for rk3066 / SurfTab Ventos tablet, you can find the configuration here.

Put it in device/rockchip/rk3066 in your cyanogen source tree.

Assuming that your CM tree is working and that you ran envsetup you can use the following commands to compile it:

lunch cm_rk29-userdebug
make recoveryimage

The resulting image is not yet bootable.

© 2012-2013 Sergey 'Jin' Bostandzhyan <jin at mediatomb dot cc>