Omegamoon blog

MediaTek USB-UART on Gemini-PDA

Kernel development for any device without having a serial console, in my experience, is a real pain, and makes life extremely hard. Chances the device won't boot at one point are pretty high, so without a serial console you're pretty much in the dark in those cases.

I got the Gemini-PDA from the Indiegogo campaign. I used to have the Psion in the old days, where I used the Psion 3c as well as the Psion Series 5. The idea of having a device with that same Psion form factor, the same quality keyboard and up-to-date software sounded like a geek dream, so I backed the project.

Soldering a serial console on the mainboard can be done, but that did not seem such a good idea to me, since I want to actually use the Gemini as my primary phone at one point.

I wanted a more non-intrusive way of having a serial console and found this interesting blog. This article describes an UART over USB functionality that apparently most MediaTek devices have.

Here is the list of materials I used to get UART over USB working on the Gemini-PDA:

A USB-C to USB-A adapter
A USB-A to USB-A cable
USB FTDI Cable
4 dupont (male) connectors

Make sure you use a USB cable that has 4 wires. The (cheap) charging cables will only have 2 wires, which obviously won't work. I cut the USB-A on one side, stripped the 4 wires and connected the dupont plugs to the wires.

Usually an USB cable is wired as follows:

Red - VCC
White - Data-
Green - Data+
Black - GND

To be on the safe side, check which wires are GND and VCC using a multimeter.

When connecting the UART directly on the mainboard the absolute maximum power for the data lines would have been 1.8V, but since we're using plain USB, the data lines are powered at 3.3V max, and VCC is powered at 5v.

The VCC connection is needed for the MediaTek preloader to detect the cable. Once detected, the USB port will be automatically switched into UART mode.

Finally connect the FTDI cable and the USB-A cable, where you link Data- (white) to TX (green), Data+ (green) to RX (white), and of course VCC and GND.

Here are the steps to make it all work:

Switch off the Gemini-PDA

Connect the USB-C adapter and the USB-A to FTDI cable
Plug in the FTDI cable in your desktop PC
Start any terminal emulator, and connect to the FTDI at 921600 baud. I use miniterm like this:
# miniterm.py /dev/ttyUSB0 921600 -f direct
Plug in the USB-C adapter in the left USB port of your Gemini-PDA

After plugging in the cable in your Gemini-PDA you should immediately see output on your terminal, indicating that the preloader started, and detected the cable successfully.

LibreELEC test build for RK3288

I created a testbuild for anyone wanting to try LibreELEC on RK3288.

First image is a firmware update.img which can be flashed with upgrade_tool in Linux, or AndroidTool in Windows. This installs the image to eMMC flash storage. Beware that this firmware image is especially for the Ugoos UT3+ device. It contains boot, kernel, recovery and LibreELEC system all in one. It partitions the Ugoos UT3+ into a small (read-only) system partition, and a large 13Gb user partition. After flashing the image it should boot you straight into LibreELEC.

Second image is one for the more adventurous types out there, wanting to try LibreELEC on some other RK3288 device. You have to be comfortable with setting up a linux distro, and you're pretty much on your own. You need a working kernel to start off with. Make sure you have that. Download the tarball archive here. It contains a seperate SYSTEM and KERNEL image. The KERNEL is the Ugoos UT3+ one. You need to make your device boot the SYSTEM partition. You can use the initramfs found here to do so. Depending on the location you're installing the SYSTEM partition, you might need to change the initramfs. You also might need to set the STORAGE location manually in the initramfs.

~~I'm still in the process of getting all the source code into github, so please bear with me there.~~

[Update] 2017-03-14 Updated firmware available

Latest test image can be found here. This image has lots of hardware fixes. Wifi works, power LED and hopefully the CPU fan as well. There was a bug in the initial resize of the user partition which caused issues in the startup wizard. This has been fixed as well.

[Update] 2017-02-23 Updated firmware available

Latest test image can be found here. This image should work when flashed from Windows as well as Linux. After flashing completes, the device is rebooted. On first boot, the user partition is automatically resized, and although the device should reboot automatically after that, it seems to hang. So on first boot, the trick is to wait for lets say a minute, then unplug the power, and finally replug the power to boot into LibreELEC. I know this is somewhat of a hassle, but it works, and hey, this is an early test version :)

Be aware of the fact that the image is for testing purposes only. There are still lots of things to fix...

[Update] 2017-02-21 Source code available

I've uploaded everything you need to create your own LibreELEC build on github here. For now it has only been tested on the Ugoos UT3+ (RK3288). Just clone the repository and run the script 'build_rk3288_ugoos-ut3s.sh'. It will generate a flashable firmware image that will run LibreELEC from eMMC.

I also updated the links above, pointing to the latest test images. The image contains LibreELEC 8.0.0 which is about to be released as a final version officially.

LibreELEC on Rockchip RK3288

Due to various reasons, it has been ages since I last wrote something here. I've been working on several projects, which pretty much consumed all my spare time. I won't bother you with all the boring details.

I'm currently using a custom made Kodi distro on a couple of RK3128 and RK3229 devices, which is what I use at home as media player on daily basis. I must say, these low-end devices work pretty well. They are Android based, which adds somewhat of overhead, since I'm only using Kodi most of the time. As a media player, for me it pretty much plays eveything that I throw at it. Of course, these aren't top notch devices, but my requirements aren't top notch as well. As long as it streams 1080p HD content without too much problems, I'm happy. My huge full fledged Intel i3 HTPC hasn't been powered on for quite a while, which is an indication these small devices are a good replacement.

I've been fiddling a lot with low-end RK3128 and RK3229 devices for quite some time, and by now the RK3228 is becoming more or less the new low-end so it seems. Prices have dropped significantly, which will probably mean more RK3228-based devices will show up. Interestingly, Rockchip has started to become a little more open in terms of community support. More and more source code can be found on github, and some Rockchip employees are actively participating on IRC, which I think is a really good development. Now big-name PC vendor Asus has quietly released the Tinker Board, a Raspberry Pi-like development board, available for around EUR 60 as I write this. Hopefully that means more developers will join in to make support for Rockchip better.

As said, my current media players are still running Android. I looked into ways to get rid of that, since I only use Android to launch Kodi. It would be nice to replace Android with a more dedicated, media centric platform. I fiddled with AndroidTV for a while, but dropped it, since I couldn't fit all the pieces together to get it working. One of my long-time favorite media platform is OpenELEC. The Intel i3 HTPC I mentioned is running it. On all the previous attempts I did to get OpenELEC running on Rockchip devices, I only partially succeeded.

This time I started with LibreELEC, which is 'an evolution of the popular OpenELEC project' according to the project 'About' page. It has the same build system that I know from previous OE endeavors. I like the simplicity of it, it is easy to extend and/or adjust.

Most of the LE distro builds without any problems. I had a basic linux distro up and running in no time on my RK3128. That is, using a serial console I was able to boot into a linux command line. Kodi didn't start since it needs hardware acceleration. For the RK3128 as well as the RK3229 this means it needs support for the Mali-400 (Utgard) GPU. Both these SOCs still use the 3.10 kernel, which seems to be no longer supported by Rockchip, and although there is support in the Linux mainline kernel, there are parts that still need closed source proprietary drivers. This makes it difficult to develop on. Therefore I switched to the RK3228 as a target. This SOC uses a Mali-T764 (Midgard) GPU. A Linux 4.4 kernel is available on github as well as Mali user space binaries matching the kernel driver.

I used the Ugoos UT3+ as a target, which was kindly donated to me by Ugoos long ago. I got a serial console working by soldering wires onto the serial pads as described here, and connecting it to my USB to Serial breakout board. The stock Ugoos Android still uses the old 3.10 linux kernel. Since source code for the 4.4 linux kernel is available with proper RK3228 support, I wanted to use that. This means that the serial console was pretty much essential. Without one, you're totally blind in *ANY* kernel development. I decompiled the kernel device tree from the 3.10 kernel, and used that as a base for the 4.4 kernel. After some fiddling that gave me a working 4.4 kernel. There were still things that needed to be fixed and improved here and there, but it was good enough to continue work on LibreELEC.

Having a kernel in place, the basic LE distro was up and running on the Ugoos in no time. Like on the RK3128, it booted into a text-only terminal console. In order for Kodi to work, Mali hardware acceleration support was needed. It took me some time to figure out how to fit the pieces together, but as always, if you know how to do this, it turns out to be quite simple.

As you can see on the screenshot, LibreELEC is running nicely on my Ugoos now. I haven't tested everything yet, but first looks show that full HD movie playback is smooth, sound works, Ethernet, touch screen. Kernel needs some more love, because Wifi isn't working yet, among other things. But apart from that I think LibreELEC has a lot of potential on the RK3288.

I need to clean up my code, but then I'll upload the code on github so you can give it a try as well if you want.

Rockchip GPL Kernel Upgrade to 3.0.101 Released

I have just uploaded all the kernel changes I made in the last couple of months. It is kind of a "big bang" commit. Sorry about that. There are too many changes to mention them all separately. Mali support is also included.

Also, any of you with touch screen monitors out there, please give it a try. Most linux distributions are not ready (yet) for touch screen monitors, but basic support should work!

Give it a try, and make sure to share additions or changes you make. The more this code is adopted, the better it will become. So please support my initiative to get a common code base for the Rockchip platform!

Support for more devices will be added soon, among other things.

I hope you like it. Make sure to leave your comments below, and feel free to use that little orange "Donate" button on the left of the screen at any time ;-)

The kernel source can be found here

Mali working on Rockchip RK3188 Quad Cores...

This is just to say that it is done, Mali is working. More to follow!

Rockchip GPL Kernel source released

There haven't been any updates for quite some time here. But that doesn't mean that nothing has happened lately... on the contrary!

Today I released a new kernel for the Rockchip SOCs. It is based on version 3.0.72 of the linux kernel, and merges have been done with code from several Rockchip kernels out there. Apart from that, all the latest Rockchip patches have been applied. Support for several devices has been added already, and changes have been made to add more devices easily later.

Tests have been done on the Tronsmart MK908 and the Kingnovel K-R42 (aka MK888), on which the kernel works stable and all onboard components are fully functional. More devices will be added later, among which are the Rikomagic MK802IV and the Radxa Rock. These are all RK3188 Quad core devices. I hope to find some time to add support for some of the dual core RK3066 devices later as well.

As part of the kernel I've also added the 3.0.72+ kernel modules that are still closed source, like the Mali and the Wifi drivers. These modules are needed if you want to use the kernel on an existing Android system. Know that we are working hard to make the changes necessary to get rid of those closed source modules, in order to create a fully 100% open sourced GPL kernel for the Rockchip platform. Parts are already in there (like Mali support), but more work has to be done in order to get it all working.

Give it a try, and make sure to share additions or changes you make. In the meantime we are trying hard to make this kernel even better, with added support for more devices and embedded support for Mali, Wifi, Bluetooth and other things. We also started working on several distributions other than Android. Think about Ubuntu and OpenELEC.

I hope you like it. Make sure to leave your comments below, and feel free to use that little orange "Donate" button on the left of the screen at any time ;-)

The kernel source can be found here

MK908 Kernel upgrade to 3.0.72+

There's still a lot of work to be done, but I've managed to upgrade the stock 3.0.36+ kernel to version 3.0.72+. As you can see it runs Android, and it does so perfectly well. Butter smooth, very fast and stable!

I'll start adding more functionality now. Overclocking already works, and I couldn't fry an egg on it yet, so maybe I have to push it a bit further.

Update: I forgot to say, this kernel still has everything 100% working on the MK908. Wifi, Bluetooth, Mali, the whole lot.

Stay tuned for more!

MK908 Kernel... 100% Working, including Wifi and Bluetooth. Finally!

I've uploaded the source code for the quad core RK3188 based MK908 on my github. This is the kernel source we've all been waiting for. It is fully functional and has Wifi and Bluetooth working out of the box.

It is pretty unchanged, I only changed the config a bit, setting the DDR SDRAM speed to 500MHz for instance and removing the camera support, freeing up some memory.

I'll add more features to the kernel later, so stay tuned.

These are exciting times!

I know, it has been a while since I posted something here. So it might look like nothing much happens here at Omegamoon headquarters. But believe me, the opposite is true.

Since respected Picuntu developer Alok got his hands on the rk3188 kernel, a small team of developers have spent much of their free time delving through the kernel code. It has been hard to keep a good balance between work, hobby and a healthy family life the last couple of weeks.

The team that has been working together across the world consists of Alok and Galland (known for their Picuntu work), Astralix (from CrewrRKTablets) and myself. Results were many sleepless nights slowly making progress or sometimes banging our heads against a brick wall. In order to do some groundwork we got support from Perry, one of the owners and founder of KSK Electrics, who kindly donated several rk3188 devices to the team members.

Others have posted their rk3188 success-stories online already. I saw an Ubuntu implementation and overclocked kernels already. Very nice! It�s good to see that apparently there are more people working on these devices, which is a good thing! Our small team has a long list of things that still need to be fixed, or things we would like to see support for. On top of this list is Wifi networking and bluetooth support. We think our current implementation of kernel and OS is not yet ready for primetime, but my guess is that this won't take long. Until that time, please bear with us!

I�ll try to post a few things that might be interesting for others as well. We have modded the MK908 and the S400 to get a serial console for instance, and... well, we have more in store. These are exciting times!

OpenELEC distribution for RK3x in the making...

I have been working on the 3.0.36+ kernel sources for the RK3x for a while now. I focus development on the MK808(B) for now, since I have a serial console available on those devices. For me the serial console is a must-have for kernel development. It makes it so much easier to find out what is causing a (fatal) kernel error, and it helped me out several times during development. I uploaded the current kernel sources to my github for anyone willing to give it a try as well. Be careful though. You have to be aware that (for now) the recent stock Android 3.0.36+ based images won't boot with the custom kernel. Cause of this is the Mali driver. It seems there are differences between the kernel driver I use and the userspace binary that is part of the stock kernel. Seems they don't match, resulting in a kernel oops during the boot process.

I also started with the development of a RK3x release of OpenELEC v3.0. For any of you that don't know OpenELEC, it is being advertised as a small Linux distribution built from scratch as a platform to turn your computer into an XBMC media center. I'm already using OpenELEC on a heavy weight quad-core Intel based machine. I use it as a dedicated media center, and it would be really something if this huge machine could be replaced with one of the noiseless(!) and extremely low powered mini RK3x devices.

I managed to build the complete OpenELEC distribution, replaced the (Android) boot.img and kernel and put the OpenELEC distribution on a SD card. Current status is that the kernel is booting nicely and the good news is that OpenELEC is starting as well, but the X-Server is causing some problems, so it needs more work. I still need to incorporate the Mali X11 driver as well.

I tried to test the OpenELEC distribution on the quad core RK3188 based MK908 as well, but since the boot process is being killed due to the X-Server not starting currently nothing shows up on screen. Maybe I need to try to get the serial console mod working for the MK908 just to see if the custom kernel boots on the RK3188 as well, using all cores...
I feel another solder session coming up :-)

Ready for the RK3188 quad cores?

RK3188 based quad core devices are hitting the streets rapidly now. I bought the Cube U30GT2 recently for my wife (so I keep away from it... for now) and I got the message that the Tronsmart MK908 has just arrived at my house today as well. Both devices are powered by the quad core RK3188 SOC, and both use version 3.0.36+ of the linux kernel.

A few days ago Galland contacted me saying that he found this github repository containing new Rockchip kernel sources that referenced the new quad core RK3188 SOC.

The original source of this repo is once again bq Readers, the Spanish tablet maker that was among the first manufacturers to release the RK3066 kernel code last year. The original kernel source is meant for the bq Curie model, and can be found here.

Looking at the bq Curie kernel snapshot it is version 3.0.36+ of the linux kernel, like all the RK3188 devices currently use. The code is the most up-to-date Rockchip version that I've seen so far. I started out to configure the kernel for the MK808B because I was curious to know whether or not this kernel snapshot has support for the RK903 Wifi/Bluetooth working out-of-the-box. Since the HDMI drivers are also updated from the version I use it might as well have fixes for the "Black screen/No signal" problem as seen in the 3.0.8+ version of the kernel. I decided to leave all code as-is and see if it compiled to begin with. I had to make a couple of changes in order to get the kernel compiled, and after it finally compiled I had to fiddle with the kernel configuration here and there because of some errors I made in the configuration.

The kernel booted but Android didn't start, so I had to check what happened using the serial console. Problem was that the serial console got disabled early in the boot process, so I couldn't see what went wrong. Current status is that I have the serial console fixed. I now know that Android is not booting because of the missing/non-working NAND module for the 3.0.36+ kernel. I tried changing the kernel version back to 3.0.8+ but then the NAND module crashes. So next thing will be to copy over the 3.0.36+ version from the Cube or the MK908 to see if that works.

Looking at the code a bit further one sweet thing I found was that it finally contains source code for clock_data.c. I broke my head over this previously closed source part over and over again. I need to investigate this piece of code later, since this might open up more overclock/underclock possibilities. But more importantly it can drastically improve general stability if tweaked correctly.

Hopefully I will find some time later this week to see if this kernel snapshot can be used on the RK3188 quad core MK908 device. If this version of the kernel indeed is usable for the RK3188 quad cores, then a big thank you goes out to bq Readers for providing the code. This sets an example for other companies that up until now refuse to follow the (GPL license) rules!

A lot of developments... Nice!

What's going on...

I get a lot of questions regarding RK3066 kernel development. Sorry if I didn't answer your question yet. It may take some time, but I'll clean up my email box in the end.

I've been breaking my head on Wifi/Bluetooth support for the MK808B. That took a lot of my time. I disassembled the stock kernel to find out what parts are currently missing in our kernel code. But I still haven't identified the piece of code that is responsible for the RK903 to do it's job. I still don't give up yet, but this one is hard to crack. Thanks again to Rockchip for keeping the kernel closed source. It sucks big time!

In the meantime I got myself an ODROID-U2. This device is based on a quad core Exynos4412 Prime ARM Cortex-A9 running at 1.7Ghz. This is the first quad core device I got my hands on, and first impressions are that this device is really speedy.

I haven't had much time to tinkle with it, but I think this device is capable of running as a full fledged media device.

Good thing is that kernel source is available for the Exynos4412, and there are several distributions to choose from already, including Ubuntu, Xubuntu, Debian, Fedora, OpenSUSE and of course Android.

I also got a V8 donated from Tomato. This dual core RK3066 device has one big advantage over the MK808 device. The external Wifi antenna provides the reception that the MK808 is missing badly.

Apart from the Wifi antenna there's not much difference compared to the MK808 though. It doesn't have Bluetooth, it runs Android 4.1 and has the same connectivity. Stock kernel is 2.6.35.7+ so that definitely needs an update.

Since I got this device sponsored by the manufacturer I tried to get my hands on the RK3066 kernel source through them as well. Without success, that's still a no-go. I tried to explain the value of open source, and what the open source community could do to help boost their sales. But somehow they feel that by returning kernel sources to the community, like they're obliged to do according to the GPL license, they are giving away intellectual property. It's like talking to a chair really!

RK3066 - The MK808B Wifi/Bluetooth chip (RK903)

I got a MK808B donated recently (thanks again Alejandro!). Where the MK808 has a RK901 Wifi chip on-board, the MK808B model contains the RK903 which combines Wifi and Bluetooth functionality.

A lot of you have tried to build a kernel with support for the RK903 Wifi and Bluetooth, up until now without success. So I gave it a try myself. I used a Broadcom 4330 driver as a base, one that matches the stock kernel driver as close as possible. Stock kernel uses version 5.90.195.26.1.6.1 and I use version 5.90.195.104.

It is still very much a work in progress, since I have to reverse engineer the (closed source) driver used by Rockchip. This is the current status of my findings. Look at the differences in the kernel logs.

In the stock kernel, the driver generates following output:

======================================================= ==== Launching Wi-Fi driver! (Powered by Rockchip) ==== ======================================================= RKWIFI WiFi driver (Powered by Rockchip,Ver 4.23) init. dhd_module_init: Enter =========== WLAN placed in POWER ON ======== ANDROID-ERROR) ## wifi_probe ANDROID-ERROR) wifi_set_power = 1 rk29sdk_wifi_power: 1 wifi turn on power ANDROID-ERROR) wifi_set_carddetect = 1 rk29sdk_wifi_set_carddetect:1 mmc1: slot status change detected(0-1) rk29_sdmmc_change_clk_div..1921.. newDiv=42, newCLK=294Khz [sdio] Linux Kernel SDIO/MMC Driver Dongle Host Driver, version 5.90.195.26.1.6.1 Compiled in drivers/net/wireless/bcmdhd on Aug 24 2012 at 09:28:21 drivers/mmc/core/core.c...1827.. ===== mmc_rescan Begin....[mmc1] mmc_attach_sdio..800.. ===== Begin to identify card as SDIO-card. [mmc1] rk29_sdmmc_change_clk_div..1921.. newDiv=0, newCLK=24750Khz [sdio] mmc1: new high speed SDIO card at address 0001 FW_PATH = /system/etc/firmware/fw_RK903.bin NVRAM_PATH = /system/etc/firmware/nvram_RK903_26M.cal F1 signature read @0x18000000=0x16044330 DHD: dongle ram size is set to 294912(orig 294912)

This is the first part only. The driver attaches nicely to the SDIO driver. Now this is where I go wrong apparently. Looking at the kernel output of my kernel, the driver shows up as follows:

======================================================= ==== Launching Wi-Fi driver! (Powered by Rockchip) ==== ======================================================= BCMDHD Wi-Fi driver (Powered by Rockchip, reverse engineered by Omegamoon) init. rockchip_wifi_init_module: Enter ## wifi_probe wifi_set_power = 1 rk29sdk_wifi_power: 1 wifi turn on power wifi_set_carddetect = 1 rk29sdk_wifi_set_carddetect:1 mmc1: slot status change detected(0-1) rk29_sdmmc_change_clk_div..1921.. newDiv=42, newCLK=294Khz [sdio] Linux Kernel SDIO/MMC Driver Dongle Host Driver, version 5.90.195.104 Compiled in drivers/net/wireless/bcmdhd on Mar 16 2013 at 11:36:56 drivers/mmc/core/core.c...1861.. ===== mmc_rescan Begin....[mmc1] rockchip_wifi_init_module: sdio_register_driver timeout ## wifi_remove

Somehow the driver is unable to attach to the SDIO driver, resulting in a timeout. So I added some debug information to find out what goes on, resulting in the following output:

======================================================= ==== Launching Wi-Fi driver! (Powered by Rockchip) ==== ======================================================= BCMDHD Wi-Fi driver (Powered by Rockchip, reverse engineered by Omegamoon) init. rockchip_wifi_init_module: Enter ## wifi_probe Omegamoon >> wl_android function wifi_set_power entered... wifi_set_power = 1 rk29sdk_wifi_power: 1 wifi turn on power wifi_set_carddetect = 1 rk29sdk_wifi_set_carddetect:1 mmc1: slot status change detected(0-1) rk29_sdmmc_change_clk_div..1921.. newDiv=42, newCLK=294Khz [sdio] Omegamoon >> bcmsdh_linux function bcmsdh_register entered... Linux Kernel SDIO/MMC Driver Dongle Host Driver, version 5.90.195.104 Compiled in drivers/net/wireless/bcmdhd on Mar 16 2013 at 11:36:56 drivers/mmc/core/core.c...1861.. ===== mmc_rescan Begin....[mmc1] Omegamoon >> mmc_rescan_try_freq: mmc_power_up(mmc1) at 300000 Hz... Omegamoon >> mmc_rescan_try_freq: mmc_go_idle(mmc1)... Omegamoon >> mmc_rescan_try_freq: mmc_attach_sdio(mmc1)... Omegamoon >> sdio function mmc_attach_sdio entered... Omegamoon >> back from mmc_send_io_op_cond with code -12 Omegamoon >> mmc_rescan_try_freq: Could NOT mmc_attach_sdio(mmc1), code 255... Omegamoon >> mmc_rescan_try_freq: mmc_attach_sd(mmc1)... Omegamoon >> mmc_rescan_try_freq: Could NOT mmc_attach_sd(mmc1), code 255... Omegamoon >> mmc_rescan_try_freq: mmc_attach_mmc(mmc1)... Omegamoon >> mmc_rescan_try_freq: Could NOT mmc_attach_mmc(mmc1), code 255... rockchip_wifi_init_module: sdio_register_driver timeout ## wifi_remove

Now, "mmc_attach_sdio" is called to attach the SDIO driver. In there "mmc_send_io_op_cond" is called in which a 'probe' command is sent to the Wifi chip. No response is coming back, resulting in a timeout...

These are just quick notes I have taken. I'm still puzzled as to what is wrong. If any of you reading this have any knowledge of what's going on, or have any tips on how to proceed, please give your feedback in the comments!

RK3066 - Pushing the MK808 to it�s limits

I�ve been investigating several things lately. System Tuner, like other tools, always show a constant CPU speed, never changing. It looks like the CPU speed is fixed. That�s strange! Tools like System Tuner get their information from sysfs, so I looked at where and how those items are filled from within the kernel, or better, where they should be filled.

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 download

The 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!

New RK3066 kernel(s) - Changes galore - MK808 is getting better and better!

I've been busy with lots of kernel changes. Too many to mention them all seperately here. I merged a lot of code from the 3.0.50 linux kernel into our 3.0.8+ code base. One big change worth mentioning is that I added touchscreen monitor support from the mainline 3.8 linux kernel. Since I don't own a touchscreen monitor myself I ask all of you proud owners of such a device to test this kernel and see if it works. Please don't forget to report your findings here of course.

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

These settings are activated on bootup of the kernel, and are fixed as long as the 'autoconfig' feature is disabled. This feature is disabled on default, and can be re-enabled as described in my previous post. As long as 'autoconfig' is disabled, the fixed output and resolution remain in tact, whatever you do. Even changing the resolution from Android won't work! If you re-enable 'autoconfig' the output as well as the resolution can be changed to your liking again.

Kernel download

The 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!

RK3066 HDMI Driver Overhaul...

I've had several reports in regards to my 'Black screen/No signal' kernel fix, ranging from "Perfect, it finally works!" to "Still doesn't work" or "Sound doesn't work". I thought about a better solution, so I made another few adjustments to the HDMI driver.

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 shell to 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.d boot script to make the settings permanent. On bootup of the device, the init.d script will configure the driver according to your preferred settings.

1. HDMI output

Use 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.
Enable (default):

echo "1">/sys/devices/virtual/display/display0.HDMI/enable

Disable:

echo "0">/sys/devices/virtual/display/display0.HDMI/enable

2. Automatic configuration

The 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.
Enable:

echo "1">/sys/devices/virtual/display/display0.HDMI/autoconfig

Disable (default):

echo "0">/sys/devices/virtual/display/display0.HDMI/autoconfig

By 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.

2880x480i-60
2880x480p-60
2880x480p-60
2880x480p-50
2880x480p-50
1920x1080p-60
1920x1080p-50
1920x1080p-50

1440x480p-60
1440x240i-50
1440x240p-60
1280x720p-60
1280x720p-50
720x576p-50
720x480p-60
720x480p-50

To change the resolution use the exact format from the list above. For example, to set 1280x720p-60 use:

echo "1280x720p-60">/sys/devices/virtual/display/display0.HDMI/mode

Kernel download

The 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.

MK808 rk30xxHMDI driver - Fixing black screen/no image problem

From day one I had difficulties working with the MK808. None of my LCD displays worked with the device. All gave a black screen, no image at all. The only exception was my Samsung TV set. Not so handy when developing stuff for the MK808, tweaking the kernel, changing the Android OS or even create new distributions like Ubuntu or XBMC.

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 (~~1080p~~720p). This works! Booting the customized kernel now finally shows the Android home screen on all my displays.

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.

MK808 Endeavours...

As some of you know, I've been working on the MK808 TV Stick/Mini PC for some time now. The MK808 is based on the dual-core Rockchip RK3066. A quite powerful SOC, capable of doing the average stuff most of us do every day with a desktop PC. Unfortunately, Rockchip is one of those manufacturers that don't comply to any open source license agreement. Simply put, the rule of thumb is that when you use open source you have to give all the modifications you make when selling products based on GPL back to the community. Well, Rockchip doesn't comply to these rules. Worse, they make their own license rules, saying that they are the sole owner of all software, including all GPL parts. That's why most hardware manufacturers say they aren't allowed to give any of the sources. Too bad they don't seem to understand the value of working together on making things better. Oh well, enough of this, I think I made my point clear. It's just so frustrating!

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

[update] Huawei G300/U8815 kernel (added zRam)

I've added "zRam" to the kernel. This feature was previously known as "compcache". It increases performance by avoiding paging on disk and instead uses a compressed block device in RAM in which paging takes place until it is necessary to use external (disk) swap space.

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
mkswap /dev/block/zram0
swapon /dev/block/zram0

To disable the zRam:

swapoff /dev/block/zram0

Remember this won't survive a reboot, so you have to re-enable it again after reboot.

Download the kernel here (MD5: a89bd97f940cc33c11ca7cc73d521abb)

[update] Huawei G300/U8815 kernel (camera flash fixed)

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)