I added some extra logging to see what (not) happened and got the part fixed that reported the cpu speed back to userspace. While browsing through the logging I saw a different error early in the boot process saying something like ďvdd_core canít get regulator in clk_enable_dvfsĒ. I wondered what that meant. Investigating the dvfs (Dynamic Voltage & Frequency Scaling) mechanism I found that parts are missing and other parts are not working. The good thing is that the source code is provided, the bad thing is that, although itís easy adding the missing parts, it still doesnít work. The error messages disappeared, but the device now has trouble reading back the current voltage value. I ended up disabling dvfs completely for the time being. By doing so, looking at the code, this also removes some overhead and (hopefully) increases speed and stability.
The RK30 platform code has a build-in ďintelligenceĒ in regards to cpufreq governors, putting hardcoded limits on frequency scaling in place. I donít like hardcoded limits, so I removed them. I added some new governors, being SmartassV2, InteractiveX and SavagedZen and made SmartassV2 the default one. I also added IO schedulers VR and SIO.
From one thing came the other. I started tweaking the frequency table, and added overclock frequencies for 1.7GHz and 1.8GHz. Testing these frequencies with the new governors it looks like 1.7GHz is the highest stable frequency. I normally use the AnTuTu benchmark for testing, but on the MK808 AnTuTu in the current version (v3.1.2) always crashes on executing the 3D benchmark. Testing with 1.8GHz results in a complete device hang-up at some point. It seems to be a heat problem, because after a while it doesnít even boot anymore, and I actually needed to cool the device down to get it working again. So beware if you want to give this a try yourself!
Thatís it for now. Iím still working on the touchscreen driver, and my todo list is getting longer and longer. If I didnít respond to your comments or mails... sorry about that! I added most requests already to the todo list for further investigation.
Thereís a MK808B underway from Spain (thanks Alejandro!) and as you can see on the top-right of this blog, szTomato as one of the manufacturers of the MK808 is sponsoring me as well. More on that later.
Since my last kernel update I updated my github repository with a lot of changes already. There are still changes pending, like the touchscreen driver and the merge with the i-onik A09 code and the Google Common Android kernel tree. So more updates will follow!
Kernel downloadThe kernel can be downloaded here. Flash it in the usual way. The zip file contains only the 720p for DVI kernel. Sorry about that, but Iím short in time. Needless to say maybe, but be careful when using the CPU overclocking feature. It can damage your device!!
Please give it a try and sent me feedback of your findings. Enjoy!
[ 18 comments ] ( 753 views ) | permalink | ( 3 / 2510 )
Some of you reported that you still have 'No signal/Black screen' problems. I had trouble myself using the MK808 on my TV (HDMI) and my monitor (DVI). Each time one of the two devices ended up having a 'No signal/Black screen'. In the comments of my previous post you also asked for a 720p fixed resolution instead of 1080p. That's why this release has four different versions of the kernel. One for each output connecion, being DVI and HDMI and for each output a 720p and a 1080p fixed resolution. All four kernels have their own distinct default setup, being:
- HDMI output with 720p fixed resolution
- HDMI output with 1080p fixed resolution
- DVI output with 720p fixed resolution
- DVI output with 1080p fixed resolution
Kernel downloadThe kernel can be downloaded here. Flash it in the usual way. The zip file contains all four kernels.
I realize I haven't uploaded my github account lately. With a shortage of spare time I tend to choose doing more fun stuff than uploading changes. I promise I'll spent some time on cleaning up the code a bit and upload a new snapshot of my code base.
In the meantime I hope you all have fun with this release. Please give it a try and sent me feedback of your findings. Enjoy!
[ 31 comments ] ( 1286 views ) | permalink | ( 2.9 / 2563 )
In short, the default HDMI settings in my latest kernel are: HDMI enabled for image AND sound (took a while to get that fixed!), Autoconfig disabled, predefined resolution 1920x1080p at 60Hz. Hopefully these settings work for most of you. My guess is they will.
To give you more control over the HDMI driver you need to get access to the device. Use
adb shellto do this from your PC. This is probably the only option you have when you have the 'No signal' problem (duh!). Then you need to find out what the best configuration for your display is. This is done using sysfs. Try experimenting with different settings. After that you can create an
init.dboot script to make the settings permanent. On bootup of the device, the
init.dscript will configure the driver according to your preferred settings.
1. HDMI outputUse this setting to enable or disable HDMI output. Reason for disabling could be that you're using your device headless and you want to save as much power as possible. On default HDMI output is enabled.
2. Automatic configurationThe effect of enabling automatic configuration is twofold. First the "Hotplug" feature reacts on connecting and deconnecting a display and second the HDMI driver tries to read configuration information from your display using EDID and configure HDMI image and sound in the highest possible mode. This is the way the original stock kernel worked. In this kernel I disabled automatic configuration on default, but you can re-enable it if you want.
echo "0">/sys/devices/virtual/display/display0.HDMI/autoconfigBy disabling automatic configuration the "Hotplug" feature is disabled as well. The driver then acts as if a HDMI display is always connected. Sound output is set to HDMI as well. Apart from that, the driver no longer tries to read the configuration from your display using EDID. Only a predefined set of display modes can be used. The default resolution is set to 1920x1080p, 60Hz. Be aware that the stock Android image resets the resolution to a lower 1280x720p, at least on the one I use. Currently following predefined resolutions are being supported when automatic configuration is disabled.
Kernel downloadThe kernel can be downloaded here. Flash it in the usual way. Although a lot of the kernel is updated to version 3.0.50 already, I still kept the 3.0.8+ version number intact, so the stock Android image can still load it's kernel modules and keeps working as normal.
Please report any of your findings here! I'm very curious to know whether or not this once and for all solves these annoying 'No signal' display problems.
[ 28 comments ] ( 114894 views ) | permalink | ( 3 / 1950 )
So in the beginning I used 'adb' a lot, and walked over to the TV set in the living room like a million times, asking my wife again and again if it's okay to "borrow" the TV for just a minute and test my latest change(s) ;-)
Now, having the serial console feature, debugging has become so much easier. The console is available early in the kernel boot process, and the device is accessible from my PC. A lot of mistakes you make when customizing the kernel show up on the console, which is very helpful.
This is how I found out that, although no image showed up on my LCD monitor, detaching the monitor was detected by the HDMI driver. This made me think. Could it be a flaw in the HDMI driver after all? All the "solutions" I read about online were related to adding (powered!) splitters, (powered!) repeaters or other converters/adapters to the MK808. In my opinion, one of the nice things of a device like this is that is has an ARM CPU which uses very little power. The succes of having such device 100% working for me would be having a small extremely powerful, "always on" and very low powered device. That's why adding all kinds of additional powered hardware is a real show stopper to me.
Delving into the HDMI device driver code, I looked at the "hotplug" feature. This feature signals any changes on the HDMI port, connecting or disconnecting a display for instance. I changed the code by telling the driver that a display is always connected, in effect disabling the hotplug feature. I also set the resolution fixed to 1280x720 60Hz (
For all of you having the same black screen/no image problem, please try flashing the kernel, and let me know if this fixes the problem for you as well. Included in this 3.0.8+ kernel are a lot of additional patches and changes, cherry picked from the 3.0.50 kernel release. I'll continue to upgrade the kernel to a higher level.
[Update] 2013-01-20 Sound issue fixed.
The kernel can be downloaded here.
[ 21 comments ] ( 15986 views ) | permalink | ( 3 / 1887 )
Luckily there are a few hardware manufacturers that understand the value of GPL. Or it may be that they don't understand the chinese license agreement from Rockchip. Or it may just be that they understand the underlying GPL agreement, unlike Rockchip. It may be a coincident also, but all the manufacturers providing some of the Rockchip adaptations of the Linux kernel seem to be based outside the people's republic of China. Anyway, it doesn't matter how, what matters is that we finally have a few snapshots of the Rockchip linux kernel adaptations after all.
Unfortunately, from all current available snapshots a lot of the essential code is missing. This makes it a difficult process to get all the hardware components working. Some code parts are delivered in binary object files only, which prevents you from making changes without going through the time consuming process of disassembling and reverse engineering.
I tried to upgrade the MK808 kernel to a higher version of the linux kernel a while ago. Reason for this is to apply common (mainline) patches and enhancements and to add some new features as well. I failed miserably. The device didn't boot, and I came to the point that I had no ways to find out what error(s) I had made. The kernel died early in the boot process. This is a common problem in kernel development. One way to find out what goes on during the boot process is the use of a serial console. I saw this great blogpost a while back about the UG802. It's a similar device using the same Rockchip RK3066 CPU. Although the PCB layout is completely different of course, I imagined that PCB designers would always create ways to debug low-level problems like I had. This is easy to say with the little knowledge of hardware that I have ;-) I looked at detailed images of the MK808 PCB and saw some connector pins that could indicate the possible use of a serial console.
This is where my brother comes in. He has a strong hardware background, always messing around with Arduino's and the like. I asked him if it was as easy as I thought it would be. The short answer was... No, it's not "just" soldering three wires onto the MK808 mainboard and connect them to the serial port of a PC. You have to know, I'm a software guy, so in terms of background my brother and I come from two completely different worlds. He tried to explain the importance of voltage conversion for instance. The PC using 12V whereas the MK808 only uses 3.3V. Talking about the risk of blowing up the device if not being careful. Or why it doesn't make sense to "just" replace the Wifi antenna with a bigger model. I have to say, most of this is all way beyond the scope of my understanding!
Anyway, to cut an already long story a little shorter, my brother came visiting me saturday afternoon and we took the plunge and started to mod the MK808. What I suspected was that the three pins just outside the CPU area were meant for debug purposes. Like on the UG802. This was a long shot of course, but that was just my simplistic way of thinking :-)
With my newly bought soldering iron, multimeter, connectors and a FTDI serial to USB breakout board we started checking out these three pins. We were in luck. The first pin we checked was the receive (RX) pin for a serial console. Tadaaaa! The MK808 booted, and we saw console output on the PC. Wow! After that it was easy to guess the transmit (TX) pin, having only two more pins left, leading to a complete working serial console in no time. How cool is that!
Most time went into putting everything back together. The heatsink had to be put back in place and we needed to get the wires connected to the FTDI board outside the case. We made a connector on top of the device so the FTDI board can now be easily connected and removed if needed. Look for yourself, I think it looks slick, and more importantly, it works perfectly well!
I couldn't have done this without the help of my brother, so all credits go to him. Thanks bro, a job very well done!
Now back to kernel hacking, so hopefully more on that later :-)
For a detailed series of hi-res photo see here
[ 10 comments ] ( 268 views ) | permalink | ( 3 / 1867 )
I'm still testing it, but it seems to have a positive effect in terms of performance.
You have to enable it manually for now. Use a terminal emulator or use "adb shell" to do this more comfortably from your desktop.
To setup a 100Kb (100*1024*1024) zRam:
echo 104857600 > /sys/block/zram0/disksize
To disable the zRam:
Remember this won't survive a reboot, so you have to re-enable it again after reboot.
Download the kernel here (MD5: a89bd97f940cc33c11ca7cc73d521abb)
[ 9 comments ] ( 363 views ) | permalink | ( 3 / 2177 )
I got in touch with "genokolar" today, since he managed to get the camera flash fixed on the U8818. He was kind enough to send me his patches, so all credits go to him for this release. I also added some more overclock frequencies, up to 1.5GHz, but they result in reboots only. At least for now...
I've created a repository on github, so please feel free to fiddle around with the sources yourself.
Download the kernel here (MD5: da9199471e4ce538d2a16bfc1d3dc1c3)
[ 2 comments ] ( 118 views ) | permalink | ( 3 / 2060 )
Download the kernel here (MD5: ccd3c44e20ce1b79b0030341f4c6f68e)
[ 2 comments ] ( 85 views ) | permalink | ( 3 / 2025 )
the top 10 excuses for not blogging for so long my excuse would be... well, I don't have an excuse, I'm still here and that's what counts :-)
I've build a kernel for my Huawei G300/U8815 smartphone yesterday. Based on the Huawei v3.0.8 kernel code, I've added overclocking, governers and I/O schedulers and added some minor tweaks here and there. Not a lot of other features yet, but I'm quite surprised with the results so far in battery life and performance. So see for yourself. Tested with stock Huawei B927 ROM, up to 1.3GHz.
Tested for performance with max 1.306GHz and min 480MHz frequency, governor "Performance" and I/O Scheduler "VR" I get a AnTuTu score of 3542. This is with lots of applications installed and active. Not bad at all I think :-)
Tested for battery life with max 1GHz and min 122MHz frequency, governor "SmartassV2" and I/O Scheduler "VR" for 11 hours. Battery dropped 0%(?!) during that time. While not sure if that's really correct and representative I started using the browser intensively, made a 5min telephone call and used whatsapp. Battery dropped from 75% to 68% during that time. Needs more testing I guess, but please post your results here!
Use something like "No-frills CPU control" from the Market to quickly set the CPU frequencies, Governor and I/O Scheduler to use. Try different options to find out which combination works out best for your specific situation(s).
I packaged the kernel as an "update.zip" so it can be easily flashed from CWM. It only updates the kernel, no need to clear caches or wipe data or anything. Just make sure to have a backup in case you want to go back to the stock kernel.
Needless to say maybe, but I'll do it anyway... Be careful with overclocking your device. Overclocking will cause a CPU to have a shorter life expectancy. Apart from that, I take no responsibility whatsoever if you fry your CPU
Last but not least a shameless plug... there is this nice "Donate" button on the left side of this page. Feel free to use it if you like what you see.
More to come...
Download the kernel here (md5: 1a00982486bbff62907624c2507ebbd9)
[ 7 comments ] ( 391 views ) | permalink | ( 3 / 1916 )
Ubuntu Jaunty (v9.04) was the last version that supports armv5te CPUs. The current versions only runs on the newer ARM processors (armv7+). So that meant I had to re-target all armv7 specific packages to make them work on the (older) armv5te CPUs again. Since this is the only way to get the newer Ubuntu versions going on our beloved Zaurus, it had to be done!
What a work! It probably can be done much quicker, but here's what I did. I took a debootstrap of the ARM (armv7+) version of the official Ubuntu Lucid version to begin with, and started rebuilding all packages one by one, re-targetting them for the armv5te CPUs. Some of the packages need special attention, and others can "just" be recompiled. I have to say, the GuruPlug is really a marvellous piece of hardware, and just perfect for doing this kind of stuff. It's just great not having to concentrate on all these cross-compilation problems you have to deal with when building ARM packages on the i586 platform. I can assure you, the GuruPlug saved me quite some headache!
Before you're going to ask me where all the fun stuff can be downloaded, this post is first of all meant as a status update of the project. Currently I only have the minimal Ubuntu distribution working. All compiled from the original Ubuntu sources, with just minimal changes to some of the packages.
So, no, the complete repository isn't available yet. But I just wanted you all to know that the good news is that it is still possible to get the latest and greatest version of Ubuntu working on our Zaurus. Woohoo!
[ 15 comments ] ( 1659 views ) | permalink | ( 2.9 / 14923 )