|Latest product reviews|
Wow... Using some carriage return would make your text much more readable...
Compiling your own kernel will be possible, if you figure out the deatils of your hardware. Most vendors and OEMs are not providing working or complete kernel sources, so you need to disassemble, test, measure and do a lot of trial and error.
The root caus is, that the kernel is the interface between your hardware and the system on top. So vendors need to adopt the hardware and therefore modify the kernel (at least the board dependend files from it) they often use the Rockchip SDK often nearly unmodified. So what we did with the Android is, to find all the nuts and bolts to turn, to make it working with most kernels.
We cannot support 300+ RK based boards if we had to compile 300+ different kernels. We just made our android APIU libraries a bit more flexible and adopt the original kernels.
We have some hardware where we have fully working kernel source code. And there are some companies that inherit GPL and open their kernel code too. But if you do not have one of these tablets, sticks or boards, you need a lot of time and knowledge to figure out your hardware details.
And in the above text there is hidden the answer, why we support AOSP and OMNI but not CM as frequent as the others. CM does a lot of modifications, even in the files we tuned to be more adaptive to different kernels. And it is a hell of work to always tune these files again and again after each release of CM.
A second reason is, that we, personally, like AOSP and OMNI more than CM... But this is without technical reasons, just a personal impression and should not minimize the good work the CM team does.
And cause of the way, OMNI includes updates and modifications, it matches more our way of providing updates and we have less work with it.
Hah, sorry, I'll try to use more formatting in my posts from now on
So, given that I already needed a lot of time just to figure out basic stuff about my tablet, like who manufactured the "motherboard" and the screen, I think I'll pass on the kernel for now - it would be my first one, so I'd better start with something easier.
And then there's the ROM. As far as I understand, all the hardware-related files, specific libraries may be in the kernel, boot, radio (if present, 'cos I see it's not there in my tab...?) and recovery partition... Then does it mean I can build any AOSP version and have the new API, framework and all this stuff on my tab? Would it make any difference to performance-related stuff? Resource management? Would for example ART from Android like 4.4.x or 5 work for my hardware?
And the third thing - I heard about methods of booting an Android device in a kind of a counterpart of PC's live boot, without flashing anything permanently to the device. That'd be very useful in case I embraked on a ROM-building journey, is there actually such a possibility? The thing's called "Rockchip SD Firmware Tool By Sonualok". If possible via SD, maybe also through some kind of sideload-like mechanism?
It is not needed to figure out the manufacturer of display or board. He will not give you anything helpful. In some countries it is more easy to get matching kernel sources as there software licenses are accepted and enforced by law and authorities. China is still learning this process.
There are two ways of handing over hardware to Android. One is to write the complete functionality for something as a kernel module and include the hardware adaption in this module. So you just stream a h264 file to that modules interface and it decodes the stream by pushing the parts of the video data to the right decoder registers.
Unfortunately CoDecs are a license to print money and therefore no software studio providing such software and hardware will make its system available open source. To make the kernel still open source, Rockchip went another way. They just wrote a simple interface kernel module as open source. This module connects to Androids libstagefreight that is closed-source. And in this there are the licensed codecs.
Unfortunately this libstagefreight is only compatible to Android but not Linux. And that is the reason why there is no proper video acceleration in Linux on Rockchip.
Rumors tell that RK has changed the supplier for the CoDec part of the SOC and will go a third way with RK3288 in future. Ther will be a lightweight driver as open source for the kernel, a less modified libstagefreight and a third binary only module that provides the closed source codecs, like it is handled with Raspberry Pi.
the radio image contains the firmware for the mobile companion SOC. This is a complete stand alone system including a CPU, memories and such. Many tablets only use a simple WiFi chip and that one often only needs a small firmware to be uploaded into it. As Linux and kernel provide very simple mechanisms to do that, the complex handling of an extra partition is not implemented.
ART has nothing to do with kernel or SOC. If you use modern 4.4.4 or 5.0.0 Android, ART is active. It is the interpreter / compiler part of Android itself and therefore independent of the underlying system.
Alternative boot methods:
Yes, you might boot our Rockchip RK3188 device by using an SD card, but not an RK30xx as with these SOCs it was not implemented. And even with RK3188 there seem to be different options to make booting an SD card difficult. For instance I do have an SD Image that boots on radxa rock and sticks like MK908IV and such, but not in my tablet. I am still trying to find out why. There is probably an option that a device can only boot signed images.
You can use usb to download a kernel into DRAM directly and run it but this is advanced knowledge and used by me for testing uboot, coreboot and other loader replacements.
OK, so maybe leaving the kernel for a little bit later, I'd like to try and build AOSP Lollipop for my device. I use CyanogenMOD's guide and I'm trying to generalize it and extend to my AOSP build, but first thing is that I think I don't need to figure out all the stuff like partition layout etc., because the job seems to have been done by Oma, since I run his build of CM 10.1 now So here's a kind request to you, Oma - could you give me a few hints, directions, what to use, what should I get from your git repo and what from the AOSP repo, how to put it together? I'm kind of new to ROM development, so my questions are probably way too vague and general, but if you could give me a hand here, I'd be very grateful.
You cannot unpack kernel.img.
It is a true kernel image (zImage) created by kernel compilation. The only special about it is, the rkcrc tool adds a header and a checksum to it. With rkunpack this header can be removed. The kernel does not provide any initramfs.
boot.img an recovery.img are different. These are the initramfs for the kernel, depending on the situation, kernel is started with boot as initramfs or recovery as initramfs.
Either boot.img or recovery.img or both can be formed as a combined image, so the image inherits a kernel and the boot initramfs nor the recovery initramfs respectively. Then no separate kernel.img is needed. In that case the Loader boots the kernel inside these images.
recovery and boot are secured by a header and checksum too, so you need to rkunpack these first and then you can pipe them through gzip amd cpio to recover the initramfs as a directory.
There is a thread in here, http://www.arctablet.com/blog/forum/firmware-development/unpackrepack-a-rockchip-boot-img/ where the process of unpacking and repacking of these images is shown.
I can't get the USB hub to work... The USB host controller says that "root hub is enabled", host is ofc present, but the S3C driver is not present (what is this anyway?)
Maybe the fact that the WLAN card is detected as a USB device changes something? I'm 100% certain that the hub worked on SOME stock firmware.
Edit: And going back to low runlevel stuff - I heard this very "wise" statement that in Android devices there's the radio that loads the bootloader, so that the bootloader isn't the master of the whole startup, but if I understand it correctly, it only is true for phones, i.e. devices with "modem" understood as some WCDMA device, while in tablets etc. radio doesnt have to be present and the power button calls the bootloader, correct?
Astralix - you mentioned something about alternative bootloaders and some tricks with kernel loading. Any success? Any point in trying on 3066? Will a Rockchip device comply with a JTAG? And does logcat provide logs for early stages of bootup or only since the kernel is fully loaded?
Rockchip tablets do not support any radio-first boot sequence. For phones it might be different, but there is a variety of different chipsets. So some have all major phone functions in the main SOC and only use "analog" front end chips for radio. Some have a separate radio SOC some have a mixture of these.
However rockchip has a mask rom loader that fetches a secondary loader from some external memory. While RK3188/RK3288 can boot from SD/MMC memory, your RK3066 can only boot from NAND. The only option to boot something from a different location is that you can search for miniroot image. This is a small linux system that only checks for an alternative image at SD slot and then boot from there.
In RK3188 this is not needed as the mask-rom already does that job.
The following users say thank you to Astralix for this useful post:Amarok
Hi guys! (after a break 😛 )
I have three questions:
1) Which source at your GitHub repo is the one for all these RK3066 tabs??
2) Is there any chance (and even more importantly - any point in) for loading 3.10 kernel or am I restrained to the factory one?
3) What about MarsBoard loaders?? They are RK3066 based and have some pretty fancy stuff going on like booting from an external SD card (WOW!) Are they compatible with my tab?
Most Users Ever Online: 749
Currently Online: siternr
Currently Browsing this Page:
Devices in use: Desktop (74), Phone (4)
Guest Posters: 43
Moderators: globula_neagra, exelletor, JochenKauz, Oma7144, cracktech