|Latest product reviews|
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...
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...
Yes, do so.
Usually KitKat builds are coming with a 2nd gen loader, a selinux kernel and selinux on in the build.
- Oma -
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,
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 -
1) I have resolved the issue of the custom recovery img files not containing a kernel: With the use of the tool "imgrepackerrk":
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:
on my Linux PC. Unfortunately, it looks like what is included in there does not make any sense:
$ 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
author: ARM Ltd.
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
author: ARM Ltd.
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
author: (C) 1999-2004 Max Krasnyansky <email@example.com>
description: Universal TUN/TAP device driver
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...
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...
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 -
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...
Any ideas? What would you do at this point if you were in my shoes?
Thanks again & best regards,
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 -
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!
(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:
insmod /system/lib/modules/mali.ko mali_dvfs=50,100,133,160,200,266,400 mali_init_clock=50
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!!!
Looking forward for your comments!
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 -
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...
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...)
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
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,
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.
The following users say thank you to JochenKauz for this useful post:awl
Most Users Ever Online: 749
Currently Browsing this Page:
Devices in use: Desktop (76), Phone (3), Tablet (2)
Guest Posters: 43
Moderators: globula_neagra, exelletor, JochenKauz, Oma7144, cracktech