Latest product reviews
ARCHOS 50 Diamond
ARCHOS GamePad2
ARCHOS
Smartphones
ARCHOS
TV Connect
ARCHOS 101 XS

A A A
Avatar

Please consider registering
Guest

Search

— Forum Scope —






— Match —





— Forum Options —





Minimum search word length is 3 characters - maximum search word length is 84 characters

Register Lost password?

ClockworkMod (CWM) Recovery easy install for RK3066 and RK3188 -- TWRP/CWM Flash-Tool and root for RK3288

 Please donate to support OMA and CrewRKTablets firmware work, thank you !

sp_Feed sp_TopicIcon
Updating TrekStor Ventos 10.1 (ST10216-2A) to Android 4.4?
Any way to update this device to a more recent ROM/kernel/Android version?
Avatar
awl
Regular Member
Forum Posts: 90
Member Since:
2015/02/11
sp_UserOfflineSmall Offline

Thanks Received: 1
31
2015/02/18 - 00:48
sp_Permalink sp_Print sp_EditHistory

Never mind - I have just sorted both issues out (two small config/C code changes needed) and successfully compiled a 3.0.36+ kernel plus modules... Smile

Will try tomorrow what happens if I try to install it...

Am I correct in that

1) I will have to use the 1.35 bootloader for RK3066?

2) http://crewrktablets.arctablet.com/?p=2398 will be the ROM image to be used as a starting point, or is there already some more recent system.img ROM that works for RK3066 (4.4.4 as opposed to 4.4.0)?

Will report later tomorrow night about my success...

Good night!

awl

Avatar
Oma7144

Moderator

Firmware Guru
Forum Posts: 6315
Member Since:
2012/10/06
sp_UserOfflineSmall Offline

Thanks Received: 1378
32
2015/02/18 - 06:49
sp_Permalink sp_Print

Yes, do so.

Usually KitKat builds are coming with a 2nd gen loader, a selinux kernel and selinux on in the build.

- Oma -

Avatar
awl
Regular Member
Forum Posts: 90
Member Since:
2015/02/11
sp_UserOfflineSmall Offline

Thanks Received: 1
33
2015/02/19 - 01:58
sp_Permalink sp_Print sp_EditHistory

Hello again, Oma,

so far, so good: I have successfully compiled and flashed 3.0.36+ kernel, but kept the stock 1.34 bootloader and the content of the stock recovery partition (if I understand correctly, still containing the old kernel).

When I boot the device normally into my 3.0.36 kernel, the screen flickers shortly, then stays black - most probably due to the fact that it does not have a graphics driver for the Mali 400 MP device. But I nevertheless assume that it has booted successfully to at least some extent, because it registers a USB device named Nexus with USB device IDs 2207/006 with my Windows PC, and this ID stays registered until I switch the tablet off using the power button.

So what I would now probably need to do is to "somehow" add the proper kernel modules for ump.ko and mali.ko in their 3.0.36+ versions to the KitKat system.img, but how do I do so without a CWM recovery?

Unfortunately, it seems that I cannot use neither the CWM recovery.img from the 10.1 build nor a TWRP recovery image to do so, because they seem to depend on the availability of a "proper" kernel in the kernel partition that is able to access the graphics chip. And I am unable to use adb against the newly compiled kernel, because in the KitKat system.img, USB debugging is not yet active, so I cannot connect to the already running 3.0.36 kernel (that is unable to access the graphics chip) with adb...

Do you have any idea how to move forward from here? Are there any RockChip tools that allow to unpack and repack the system.img file on a PC after insterting kernel modules as needed? Or a way to make the system.img start with ADB USB debugging mode enabled?

Many thanks & best regards,

awl

Avatar
Oma7144

Moderator

Firmware Guru
Forum Posts: 6315
Member Since:
2012/10/06
sp_UserOfflineSmall Offline

Thanks Received: 1378
34
2015/02/19 - 06:50
sp_Permalink sp_Print

The KK build itself is ok. It still has a mali.ko which is closed source. As fas as I know ump.ko is not longer active in the build. So it has to be inline. Usually the frame buffer handling is different in a new Android version.

The problem with adb is typical. That's why kernel developer work with a serial adapter. Reverse-Engineering without debugging information is hopeless.

- Oma -


Avatar
awl
Regular Member
Forum Posts: 90
Member Since:
2015/02/11
sp_UserOfflineSmall Offline

Thanks Received: 1
35
2015/02/19 - 14:02
sp_Permalink sp_Print sp_EditHistory

Hello again,

getting closer:

1) I have resolved the issue of the custom recovery img files not containing a kernel: With the use of the tool "imgrepackerrk":

http://forum.xda-developers.com/showthread.php?t=2257331

I have been able to create a TWRP recovery img that includes the old stock 3.0.8+ kernel and therefore is able to run while I already have the new 3.0.36+ kernel in my kernel partition.

2) With this tool, I have also been able to loop mount the contents of your KitKat build's "system.img" taken from here:

http://crewrktablets.arctablet.com/?p=2398

on my Linux PC. Unfortunately, it looks like what is included in there does not make any sense:

$ pwd
/home/android/imgrepacker/kitkat/system/lib/modules

$ ls -l *mali* *ump*
-rw-r--r-- 1 root root 151930 Dez  3  2013 mali.ko
-rw-r--r-- 1 root root 217071 Dez  3  2013 mali.ko.3.0.36+
-rw-r--r-- 1 root root  42846 Dez  3  2013 ump.ko
-rw-r--r-- 1 root root  45442 Dez  3  2013 ump.ko.3.0.36+

$ modinfo mali.ko
filename:       /home/android/imgrepacker/kitkat/system/lib/modules/mali.ko
version:        r3p2-01rel0
author:         ARM Ltd.
license:        GPL
srcversion:     14244DB00F3C2C24997B7AF
depends:        ump
vermagic:       3.0.8+ SMP preempt mod_unload ARMv7
parm:           mali_dvfs:mali clock table (array of int)
parm:           mali_init_clock:mali init clock value (int)
parm:           mali_debug_level:Higher number, more dmesg output (int)
parm:           mali_max_job_runtime:Maximum allowed job runtime in msecs.
Jobs will be killed after this no matter what (int)
parm:           mali_l2_max_reads:Maximum reads for Mali L2 cache (int)
parm:           mali_dedicated_mem_start:Physical start address of dedicated Mali GPU memory. (int)
parm:           mali_dedicated_mem_size:Size of dedicated Mali GPU memory. (ulong)
parm:           mali_shared_mem_size:Size of shared Mali GPU memory. (int)
parm:           mali_max_pp_cores_group_1:Limit the number of PP cores to use from first PP group. (int)
parm:           mali_max_pp_cores_group_2:Limit the number of PP cores to use from second PP group (Mali-450 only). (int)

$ modinfo ump.ko
filename:       /home/android/imgrepacker/kitkat/system/lib/modules/ump.ko
version:        
author:         ARM Ltd.
license:        GPL
srcversion:     20ABD800A77F20A96C38F31
depends:        
vermagic:       3.0.8+ SMP preempt mod_unload ARMv7
parm:           ump_backend:0 = dedicated memory backend (default), 1 = OS memory backend (int)
parm:           ump_memory_address:The physical address to map for the dedicated memory backend (uint)
parm:           ump_memory_size:The size of fixed memory to map in the dedicated memory backend (uint)
parm:           ump_debug_level:Higher number, more dmesg output (int)
parm:           ump_major:Device major number (int)

While for a "standard" module in there - such as tun.ko - the modinfo output looks as expected:

$ modinfo tun.ko
filename:       /home/android/imgrepacker/kitkat/system/lib/modules/tun.ko
alias:          devname:net/tun
alias:          char-major-10-200
license:        GPL
author:         (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
description:    Universal TUN/TAP device driver
depends:        
vermagic:       3.0.36+ SMP preempt mod_unload ARMv7

So clearly both mali.ko and ump.ko in this system.img are the wrong kernel module versions and will not load - which means the black screen is expected... Frown

I am about to try fixing this, but need to figure out how to properly repack system.img from the loop-mounted ext4 image...

Do you have any idea why KitKat includes the wrong versions of these modules? Or has this been an addition that you made to this system.img? Did you ever try to run this KitKat system.img on a device with a Mali chipset?

Will report once again when I have more news... Wink

Best regards,

awl

Avatar
Oma7144

Moderator

Firmware Guru
Forum Posts: 6315
Member Since:
2012/10/06
sp_UserOfflineSmall Offline

Thanks Received: 1378
36
2015/02/19 - 18:53
sp_Permalink sp_Print sp_EditHistory

Yes, sure. Here is the build running on my rk30board: http://crewrktablets.arctablet.com/?attachment_id=2399

Maybe you will find some usefull stuff on our repo: https://crewrktablets.arctablet.com:8081/public/projects

- Oma -

Avatar
awl
Regular Member
Forum Posts: 90
Member Since:
2015/02/11
sp_UserOfflineSmall Offline

Thanks Received: 1
37
2015/02/19 - 19:27
sp_Permalink sp_Print

Hmm - and this your rk30board tablet indeed also uses Mali MP400 like the Ventos does?

But really wondering: How can a 3.0.36 KitKat kernel load the module mali.ko from /system/lib/modules if this module provenly is the 3.0.8 version? Or is there some logic hidden in the KitKat system image that - after loading mali.ko/ump.ko has failed, tries again with the names mali.ko.3.0.36+ and ump.ko.3.0.36+?

Otherwise I really have no explanation how this build can use the display on your tablet...!?

Is there a way to permanently activate USB debugging by default through changes made to system.img, such that I can connect through adb from the first boot into KitKat? Otherwise I'm once again stuck, because in order to activate USB debugging through the UI, I clearly need to see the display output, which I currently dont... Frown

Any ideas? What would you do at this point if you were in my shoes?

Thanks again & best regards,

awl

Avatar
Oma7144

Moderator

Firmware Guru
Forum Posts: 6315
Member Since:
2012/10/06
sp_UserOfflineSmall Offline

Thanks Received: 1378
38
2015/02/19 - 19:47
sp_Permalink sp_Print

Well, nameing conventions are dust in the wind. Kernel and firmware are done from at least 200 chinese guys working as long as it works ... but none of them knows why it works. Allright?

After doing the work they forget everything and disappear. That's why nobody can be GPL compliant.

When you speculate to find European standards you cannot expect Chinese prices. That's what it is.

When you have fun to do some reverse-engineering then you have to buy a serial adapter.

The 3.0.36+ mali.ko gets loaded. Ump.ko is (as far as I remeber) not active in the running build, because it is inline.

And yes, although I am very old, I am sure that my rk30board runs the same Mali GPU then every other rk30board, like your Ventos.

- Oma -

Avatar
awl
Regular Member
Forum Posts: 90
Member Since:
2015/02/11
sp_UserOfflineSmall Offline

Thanks Received: 1
39
2015/02/20 - 00:31
sp_Permalink sp_Print

Hello again,

many thanks for your reply!

What would this serial adapter (I assume, UART) need to look like? Searching the web did not really point me to what would be required... Also, where will this cable connected to the Ventos? Using micro USB port, or does this cable need to be connected elsewhere, i.e. directly on/to the motherboard (i.e. inside the case)? Opening up this Ventos is definitely NOT an option: its plastic cover/case is sealed, and any attempt to open it up will make it break once and for all times...

Back to the modules issue: If indeed the 3.0.36+ mali kernel module gets loaded, then this cannot work via Linux udev, but must have been explicitly coded via insmod/modprobe somewhere in the early boot cycle - so I will go and search for this code in the KitKat system.img image...

What I am wondering about is: Is this RK3066 KitKat system.img directly based on CyanogenMod 11? I think that CyanogenMod definitely should NOT contain this RockChip-specific code to insmod a mali.ko.3.0.36+ kernel module, so I still have no idea how this could work out for you!? Did you change the "stock" CyanogenMod code yourself at this place to make this work?

So again lots of follow-up questions - but I am indeed starting to worry whether this is worth doing further research, or whether I should simply accept that this device is not upgradeable...

Thank you one more time!

awl

Avatar
awl
Regular Member
Forum Posts: 90
Member Since:
2015/02/11
sp_UserOfflineSmall Offline

Thanks Received: 1
40
2015/02/20 - 00:57
sp_Permalink sp_Print sp_EditHistory

(updated - was initially looking at a wrong boot.img by my stupid mistake)

Looking at the boot.img taken from Oma_RK30_Pipo_S1s_KK_4.4_v1.0 (1.105.826 bytes, dated Dec 9th, 2013) gives the following search hit for loading the ump and mali kernel modules on boot:

In file /init.rk30board.rc we have:

on post-fs
    insmod /system/lib/modules/ump.ko
    insmod /system/lib/modules/mali.ko mali_dvfs=50,100,133,160,200,266,400 mali_init_clock=50
    insmod /system/lib/modules/rk30_mirroring.ko
    insmod /system/lib/modules/rk29-ipp.ko

This is the only search hit for the text "mali.ko" (and therefore, also for mali.ko.3.0.36+) within the whole boot process in the boot.img and system.img images...

So how could this have ever worked when the file versions of ump.ko and mali.ko in the associated system.img are the 3.0.8+ versions!? There clearly is something more than rotten (i.e. suspicious) in the state of Denmark here!!! Confused

Looking forward for your comments!

Thanks,

awl

Avatar
Oma7144

Moderator

Firmware Guru
Forum Posts: 6315
Member Since:
2012/10/06
sp_UserOfflineSmall Offline

Thanks Received: 1378
41
2015/02/20 - 07:35
sp_Permalink sp_Print

Yeah, your logic will fail again and again. Not because of your logic is wrong, but for the fact that this is Chinese stuff ;-)

Or do you mean the rk29 (RK2918) module will work? No, nothing is really that what you may detect.

A serial adapter needs to be soldered to the board. Like this here: http://www.android-hilfe.de/attachments/root-hacking-modding-fuer-das-odys-loox/63872d1325783744-odys-loox-mit-linux-serielle-schnittstelle-odys-serielle-klein.jpg

Only logs (and debug options on in the kernel) will give you hints of what's getting live and what fails for what reason.

Btw here is a feedback from yesterday that the KK build runs on a Medion E10320: http://www.arctablet.com/blog/forum/crewrktablets-rk3188-entwicklung-customroms-development-croms/aldi-tab-medion-e10320/page-2/#p50793

- Oma -

Avatar
awl
Regular Member
Forum Posts: 90
Member Since:
2015/02/11
sp_UserOfflineSmall Offline

Thanks Received: 1
42
2015/02/20 - 13:01
sp_Permalink sp_Print

Thanks Oma,

so let's forget about the UART debugging due to opening the case and soldering needed, as this cannot be done on the Ventos without irreversibly destroying the case.

Anyway, I'm moving forward slowly, but steadily:

Looks like in order to properly boot a 3.0.36+ kernel, I will also need to apply the same workaround that I needed for CM 10.2, namely to flash the stock recovery first in order to have it format /data, /cache and internal SD. Having done so, the 3.0.36 kernel and the KK build indeed comes up with the kernel that you provided:

Linux version 3.0.36+ (root@alex-System-Product-Name) (gcc version 4.4.3 (GCC) ) #2 SMP PREEMPT Tue Jun 4 18:16:21 CST 2013

As this kernel is based on largely different hardware than mine, there are several issues that will hopefully be resolved once I succeed to run my own kernel with its kernel config:

  • orientation/rotation sensor does not work, so I get a vertical/portrait display that is hown on my tablet in horizontal/landscape mode
  • touchscreen does not work
  • neither WIFI nor Bluetooth do work

But luckily, the KK build has adb debugging enabled by default, so I could finally connect with adb to a running 3.0.36 kernel for the very first time... Laugh

Some logs and debug files attached (dmesg, logcat, mtd layout, mounts, df)...

As a logical next step, I would like to compare the kernel build config that has been used for your kernel to my kernel build config. Would you be able to provide me with your kernel config for the kernel from Oma_RK30_Pipo_S1s_KK_4.4_v1.0?

BTW: I've just made a first donation for your continued support, and will make another one once KitKat is running on the Ventos (if at all we can get there...) Wink

Best regards,

awl

Avatar
Oma7144

Moderator

Firmware Guru
Forum Posts: 6315
Member Since:
2012/10/06
sp_UserOfflineSmall Offline

Thanks Received: 1378
43
2015/02/20 - 16:08
sp_Permalink sp_Print

Thanks a whole lot!

The alex kernel booted is a stock one. I thought I linked you to our repo ... here is the link directly to the genio defconfig: https://crewrktablets.arctablet.com:8081/crewrktablets/rk3x_kernel_3-0-36/blob/wip/genio/arch/arm/configs/odys_genio_defconfig

- Oma -

The following users say thank you to Oma7144 for this useful post:

awl
Avatar
awl
Regular Member
Forum Posts: 90
Member Since:
2015/02/11
sp_UserOfflineSmall Offline

Thanks Received: 1
44
2015/02/20 - 17:16
sp_Permalink sp_Print

Ah, ok, thanks, I see. I was unsure whether it was one of those configs, as this build was advertised to be for Pipo S1s (Oma_RK30_Pipo_S1s_KK_4.4_v1.0) and not Genio.

Will try to move forward from here, do a diffconfig and then compile "my" kernel one more time based on the results of the config parameter comparison.

Two more small questions:

1. Do you think that gcc version might make a difference? I currently use the cross compiler from Ubuntu 14.04 LTE (gcc 4.8.2), while you used gcc 4.4.3 (which might be more stable/reliable)?

2. How do you create the kernel.img from the build result? So far, I have used a tool called rkckcrc and packaged the "zImage" with this tool. I think that you might have done this differently, as typically, your kernel.img seems quita a lot bigger than mine - (even though my 3.0.8 kernel produced in this way also was booting fine).

Thanks again & best regards,

awl

Avatar
JochenKauz

Moderator

Firmware Guru
Forum Posts: 450
Member Since:
2012/11/19
sp_UserOfflineSmall Offline

Thanks Received: 76
45
2015/02/20 - 18:06
sp_Permalink sp_Print

Hi,

1. If you have a stable build with the 4.8.2 gcc all should be fine. The gcc 4.4.3 is the compiler that always produces bootable kernel code, so it is more to check if all runs fine. If a kernel build with 4.4.3 does not work, then you can be sure that it will not work with any other gcc version. Currently I compile my 3.0.36 kernel for a9 with a gcc 4.9.2 of linaro.

2. if you use a rk kernel you should get a kernel.img with only submitting a make kernel.img, that's it and no further steps needed. If you look at our repo rk3x_kernel_3-0-36 you will find a build script in the root. You can look at it perhaps it make things clearer how we build our kernel.img.

 

Cheers

JochenKauz

The following users say thank you to JochenKauz for this useful post:

awl
Forum Timezone: Europe/Paris

Most Users Ever Online: 749

Currently Online: makafile
78 Guest(s)

Currently Browsing this Page:
1 Guest(s)


Devices in use: Desktop (72), Phone (6), Tablet (1)

Top Posters:

finless: 604

DarthJabba: 551

maikal: 394

mussonero1: 350

alex: 252

damo: 243

DanielVd: 237

Mark06: 222

Newest Members:

psaygak

jw13santos

jw13

chakraecho

MobBob

test15243

Forum Stats:

Groups: 10

Forums: 185

Topics: 6037

Posts: 60500

 

Member Stats:

Guest Posters: 43

Members: 262194

Moderators: 5

Admins: 1

Administrators: admin

Moderators: globula_neagra, exelletor, JochenKauz, Oma7144, cracktech


CrewRKTablets moderators: JochenKauz and Astralix