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 ] ( 248 views ) | permalink | ( 3 / 1651 )
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 ] ( 345 views ) | permalink | ( 3 / 1976 )
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 ] ( 113 views ) | permalink | ( 3 / 1847 )
Download the kernel here (MD5: ccd3c44e20ce1b79b0030341f4c6f68e)
[ 2 comments ] ( 82 views ) | permalink | ( 3 / 1796 )
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 ] ( 375 views ) | permalink | ( 3 / 1716 )
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 ] ( 1653 views ) | permalink | ( 2.9 / 13479 )
PlugComputer arrived last friday. The GuruPlug Server Plus to be exact. What a great little gadget that is. I'm still experimenting, but I'm amazed by the speed. Bottleneck now seems to be the harddrive I'm using, which is a cheap USB drive. So I'll have to pick up a eSATA drive I guess.
Oh, and regarding all reported problems on overheating... no problems here!
This means new possibilities for Zubuntu... More on this later!
[ 4 comments ] ( 450 views ) | permalink | ( 3 / 14009 )
we can't help being disappointed by the specs. Pocketability and connectivity are my main worries. I just want to take the device from my jacket (size) and be online all the time (3G). But, apart from that, the keyboard looks great, the CPU speed and internal memory is enough to run most apps comfortably and battery life seems stunning (unchecked, have to see it first). Current mid/netbook trend has done great things in terms of optimizations of the Linux operating system, and since the PC-Z1 (the Z refers to little Zaurus brother of course) runs Linux, the limits of possibilities take a huge step forward compared to our beloved Zaurus.
I say this is a great upgrade from the Zaurus, much better than any of those battery slurping, overpriced and overweight Wintel based things thrown at us for months now.
Time for a group buy. I'll check what Brett can do for us. Anyone in? The more the merrier
PS: The PS-Z1 seems to be based on Ubuntu 9.04... Would be cool to have a Zubuntu 2.0 based on 9.10 for the Zaurus in the meantime. Oh, what the heck, I'll upload one later.
[ 18 comments ] ( 16155 views ) | permalink | ( 3 / 15899 )
Buffalo WLI2-CF-S11 compact flash card. Although the card worked nicely for a while, it has always been a troublesome experience setting it up. I guess last time I had it working was before I changed my home networking security from WEP to WPA.
So I figured today was the time to delve into the secrets of chipsets, firmware and flashing, just to see if I could get the Buffalo running again in Zubuntu.
First I checked for the chipset on the Buffalo card. Where else than on OESF I found that the Buffalo had a Prism 2.5 chipset. Next thing I checked was whether there was a way to update the firmware. I had no idea, never tried actually. I found this great site with lots of interesting information about flashing prism2 firmware.
I noted the information (using the '
dmesg|tail' command) after inserting the card into the Zaurus. It said:
wifi0: NIC: id=0x800c v1.0.0
wifi0: PRI: id=0x15 v1.1.0
wifi0: STA: id=0x1f v1.3.5
wifi0: defaulting to host-based encryption as a workaround for firmware bug in Host AP mode WEP
wifi0: defaulting to bogus WDS frame as a workaround for firmware bug in Host AP mode WDS
wifi0: registered netdevice wlan0
Using this handy reference table, I found that in my case, having a NIC id of 800c, I needed a primary 'K' and secondary 'F' release code of the Prism2 firmware. So I downloaded the firmware, using version 1.1.1 (
pk010101.hex) for the primary firmware and version 1.8.2 (
sf010802.hex) for the station firmware. Version 1.8.2 is not the latest (that is 1.8.4) but reportingly the most stable version, so I went for that one.
I used the Zaurus to do the actual firmware flashing. The
hostap-utilspackage contains the
prism2_srecutility, which is used for the firmware flashing. After doing a testrun using...
# prism2_srec -v wlan0 pk010101.hex sf010802.hex
...I saw no significant errors of any kind, so I then started the actual flashing using...
# prism2_srec -v -f wlan0 pk010101.hex sf010802.hex
This went flawlessly, and '
dmesg|tail' now told me:
wifi0: NIC: id=0x800c v1.0.0
wifi0: PRI: id=0x15 v1.1.1
wifi0: STA: id=0x1f v1.8.2
Firmware upgrade went fine this far, according to the version upgrade, so now it was time to check whether or not the card supported any new features, WPA being the most important for me.
In the current version of Zubuntu I use WICD as network manager. In the properties I saw my home network instantly (it was not shown at all before the flash upgrade) and I could choose WPA as well. After entering my WPA passphrase I was connected to my wireless home network in just a minute.
This was worth the upgrade, I hope this is of any help to any of you. It may be worth upgrading your wireless card as well. Be careful to pick the right firmware versions for you specific situation!
[ 5 comments ] ( 331 views ) | permalink | ( 3 / 15549 )
2.6.31-rc3 kernel MD5: 602d83142fbf3d8692e4adf4dee07b4d 2.6.31-rc3 modules MD5: b154506766ead4018140ca3c8bef9a63
Like previous kernels, the offline charging code still doesn't work, but at least the suspend/resume works again (thanks to Eric Miao for helping out again). This kernel also has all drivers compiled in to get Android going, so hopefully more on that later as well.
Again, please give it a try and give me feedback on your findings!
[ 13 comments ] ( 710 views ) | permalink | ( 3 / 15229 )