Quantcast
Viewing all 38 articles
Browse latest View live

EOC bit in Bosch BMP085 I2C registers

Searching for an End-of-conversion (EOC) bit
in the undocumented BMP085 I2C registers

(Answer is: EOC bit exists, you can skip to the bottom for the conclusion)


Here I am, tinkering with the Bosch BMP085 pressure and temperature sensor on a nice little 10DOF board I found on eBay at around $21 (half that of a FreeIMU, although with a little less precise sensors):





On to the problem, the datasheet of the BMP085 happens to be a shame. This is about the only I2C chip I've found where no description of its I2C register map is provided, just a diagram on the "usual" operation and what value to write to which register at what time. No explanations, no bits, no nothing.

As I would rather not have the extra EOC (end of conversion) pin connected, I'd be quite happy to have its value read through the I2C; and something tells me this bit should be available at one of the sensor's undocumented registers.


So, by using the Arduino IDE, I implemented a simple initialization function where it would:

1) read BMP085 calibration parameters (EEPROM)
2) read the uncompensated temperature value
3) read all I2C regs from address 128 to 255 (below them the values are 0)
4) request the uncompensated pressure value with oversampling 3 (writing 0xF4 to register 0xF4), which takes up to 25.5 ms to be measured.
5) During those 25.5 ms proceed to read again all regs 128 to 255
6) Wait 25.5 ms (just in case I2C reading interfered with measuring)
7) Read again all regs 128 to 255

Hence we end up with 3 sets of values for the I2C regs 128 to 255
1st value: before measurement is requested (i.e. sensor is idle)
2nd value: during measurement (i.e. sensor "working")
3rd value: after measurement (i.e. sensor back to idle)

If there is an EOC (end of conversion) bit in a BMP085 I2C register, it should be different during measurement time (2nd value).

Here are the results showing which registers do change at any of the above three moments:




Analysis

Let me share the results in a less-to-more important order:


Registers 0xF6 to 0xF8:

0xF6 and 0xF7 are the measurement's MSB and LSB respectively. Also register 0xF8 changes sometimes (as it is the measurement's XLSB byte).

So, obviously, these registers can not contain the EOC bit we are looking for.


Register 0xF3:

This undocumented register changes its value upon measurement start and so it stays even after finishing it, hence it is of no value as EOC indication.


Register 0xCF:

Actually this register almost always keeps its value (except in the above screenshot :), hence I am skipping it due to its inconsistency as EOC indication.





Register 0xC2:

This is one interesting candidate since it consistently has value 0xBC between measurements and value 0x98 during measurement.


Register 0xF4:

Another good candidate is 0xF4, the register that is written to command the sensor to start a pressure or temperature measurement.
Since oversampling 3 is being used, the value written to it between reading 1st and 2nd values is 0xF4.

As can be seen, bit 3 is auto-cleared at measurement's start, meaning who knows what.

However bit 5 also happens to be auto-cleared AFTER measurement is finished. Does this mean something?





Then, let's keep an eye only on 0xC2 and 0xF4 by sampling them as many times as possible before, during, and after a measurement is started.



Analyzing Register 0xC2 during measurement

So, by connecting to the Arduino board the P_EOC pin of the BMP085 and implementing the following code:

1) Read register 0xC2 and print its value
2) Request pressure with oversampling N
3) Read register 0xC2 and store its value in an array
4) If P_EOC is high, go to 5, if it is low, go back to 3
5) Read register 0xC2 and store its value at the last position in the array
6) Print the array

The results are, for oversampling 0 are:



Hence we can see that 0xC2 register's idle value is 0xBC, whereas during conversion it is 0x84 or 0x98.

Same register values are seen for the rest of oversamplings.



Analyzing Register 0xF4 during measurement

Code is same as with register 0xC2, but this time reading register 0xF4. The results are quite interesting, here is a screenshot:



The register values DURING measurement (step 2 above) are constant and only change (bit 5 cleared) when EOC pin rises, meaning end of conversion.

Please note that measurement took some 9 ms with an oversampling factor of 2, whereas the datasheet indicates only the maximum conversion time of 13.5 ms.

I don't know about you, but I find that difference useful, to say the least.


Same happens with other oversampling values:

- Oversampling 0: register 0xF4 changes its value from 0x30 to 0x10 upon EOC pin rising, after 4 ms real conversion time, as opposed to datasheet's maximum of 4.5 ms

- Oversampling 1: register 0xF4 changes its value from 0x70 to 0x50 upon EOC pin rising, after 6 ms real conversion time, as opposed to datasheet's maximum of 7.5 ms

- Oversampling 2: register 0xF4 changes its value from 0xB0 to 0x90 upon EOC pin rising, after 9 ms real conversion time, as opposed to datasheet's maximum of 13.5 ms

- Oversampling 3: register 0xF4 changes its value from 0xF0 to 0xD0 upon EOC pin rising, after 17 ms real conversion time, as opposed to datasheet's maximum of 25.5 ms




PRESSURE/TEMPERATURE EOC

Up until now all tests are conducted when requesting pressure measurements, however, both registers 0xC2 and 0xF4 show the same behavior when reading temperature.

From my tests, its real conversion time was around 3 ms.



CONCLUSION


On how accurate are these time measures, please note:

1) no Serial printing is done within the main loop (as should be)
2) the EOC pin is checked, in the loop, only after every I2C read, which takes a discrete amount of time, hence the above real times may be slightly above the actual value.
3) (**DISCLAIMER**) the real conversion times above have been measured in one particular day, with certain relatively stable pressure and temperature values, hence the real conversion time may vary for different conditions, probably up to the datasheet's maximum... but then that's why we wanted the EOC indication in the first place!

So, both registers 0xC2 and 0xF4 seem to provide EOC indication. I personally prefer checking 0xF4 for simplicity, hence:



Bit 5 of I2C register 0xF4 in Bosch BMP085 sensor is a busy indication (the inverse of the EOC pin value)



Feedback/constructive criticism is welcome.

Ubuntu Linux (Picuntu RC3) on Measy U2C (RK3066) with WiFi dongle




In this blog-post I'll explain how to install Picuntu 0.9 RC2.2, upgrade to RC3 without Internet connection, and then, using a very common WiFi USB stick connect it to the Internet, bypassing the internal WiFi chip.

In my case I will be using a TP-Link TL-WN422G USB WiFi stick, which contains an Atheros 9000 class (ath9k) WiFi chipset, supported by Picuntu 0.9 RC3.


Why?


As you may already know, the Measy U2C TV stick comes with chips Mediatek MT5931 (WiFi) and Mediatek MT6622 (Bluetooth) which are not currently (March 2013) supported in Linux.


For more up to date WiFi+BT compatibility information see Miniand's website:
http://dl.miniand.com/tecknight/RK3066Devices.html
Please note that, from the featureset, the Measy U2C stick seems to be a clone of Kimdecent's B12 (even the U2C's PCB silkscreen reads "B12_main_V1.1").






My current setup is the above MeasyU2C with:
- A phone USB power adapter (5V 1A) connected to the DC-5V Micro USB port
- A Logitech wireless keyboard+mouse with its USB dongle plugged in the USB 2.0 port
- A TP-Link TL-WN422G 802.11g WiFi USB stick into the side Micro USB port through an adapter (Micro USB to full size USB).
- An 8 GB Class 4 MicroSD card into the "TF Card slot" (helped by a small screwdriver)
- An Acer X233H FullHD monitor (with an HDMI to DVI adapter) to the HDMI connector





Now on to the installation, but first of all, a big thank you to AlokSinha, the main developer behind Picuntu, for his great work.


1st) Rooting the Measy U2C


When your Measy U2C arrives it will contain an unrooted Android system. The first task is to unroot it by following the directions indicated in this url:

http://blog.geekbuying.com/index.php/2013/01/31/how-to-root-measy-u2c/

This is necessary to end up with an Android console that can reboot your Measy into Linux whenever you want (you keep both systems, since the Linux kernel is flashed into the recovery partition).

The rooting process requires two tools: Moborobo will get the right drivers for WinXP to talk to the RK3066 stick, and only then, the TPShark tool will be the one unrooting the stick.

It took me some time to get Moborobo to install the right drivers on my Windows XP 32 bits, so much that I can't really tell what I did besides rebooting, plugging/unplugging lots of times to get it done. I was unable to get Moborobo to install drivers correctly on a clean WinXP VM on VirtualBox.
However I must admit I heavily dislike the Moborobo tool, to me it feels like screaming "malware", so I am very cautious dealing with it.

Once Moborobo gets the right drivers installed, the TPSharky unrooting utility will be able to work (or else it'll complain that device is not detected or it's offline) and effortlessly unroot it (after three reboots).

After this, get into Android and install in the stick the utilities: SuperRoot, Busybox, and Android terminal. These will be needed to order the Android stick to reboot into Linux (that's the way it is).





2nd) Installing Picuntu Linux


This part can't be better explained than it already is in the comprehensive Miniand's website:

https://www.miniand.com/wiki/Picuntu+Linux+Step+by+Step+Installation

It's great to see a distributor taking so much care for the products it sells, by supporting customers with all this information.

When running the "prepicuntu" script (as root, to access/format the SD), from my Linux PC (in order to copy Picuntu in my 8GB MicroSD card that will go into the Measy U2C) I selected iMito MX1 as my stick (current options are UG802, MK808, MX1, and generic).

UPDATE: Install is fine when selecting "Generic" also, but even if you select USB dongle for Wifi, you'll still have to change the "interfaces" file as indicated in a step below, since the Wifi stick gets named "wlan1" anyways.

VERY IMPORTANT if by the time you are reading this the Miniand's website instructions still refer to Picuntu 0.9 RC 2.2:
Since we need the Picuntu RC3 kernel+modules to be able to use our WiFi USB stick:
- When reaching "Part 3-Flashing the PicUntu kernel as the Android recovery image" page, you MUST NOT follow this instructions
- Instead turn to "Appendix C--Using PicuntuRC3KernelInstaller to Flash your Desired RC3 kernel" and follow those instructions, to flash the RC3 recovery kernel.
Then, follow on to "Optional-Upgrading your PicUntu installation to RC3" with the modifications described next.


Since we don't have Internet in the stick yet, we can not download the required kernel modules + firmware from inside it. Hence, it has to be done from the PC with these steps:

1) Insert the Picuntu MicroSD card prepared on "Part 2-..." into your Linux PC


2) Open a terminal and type
wget http://download.g8.net/picuntu/modules-3.0.8-alok-RC3.tgz

3) Followed by:
sudo tar -xzfv modules-3.0.8-alok-RC3.tgz -C /mnt/linuxroot/lib/modules
Root is necessary or it won't allow modifiying the SD contents. Changing "/mnt/linuxroot" with the appropriate dir where the MicroSD was mounted (could be /media/user/linuxroot for Ubuntu PCs, where "user" is your username).


4) Then, as indicated in the previous Miniand's website, correct the folder name:
sudo mv /mnt/linuxroot/lib/modules/modules /mnt/linuxroot/lib/modules/3.0.8-alok+
  (Same as before: modify the linuxroot base dir to your case)


5) NEW STEP: Since a firmware file is needed for my USB Wifi stick (htc_9271.fw for mine, check out yours) to communicate with Linux, we'll copy it now. Supposing your Linux PC already has it (or else it's easy to find & download):
sudo cp /lib/firmware/htc_9271.fw /mnt/linuxroot/lib/firmware
   (Same as before: modify the linuxroot base dir to your case)


6) NEW STEP: Now you must modify the "/mnt/linuxroot/etc/network/interfaces" file in the MicroSD in order for Picuntu to use the USB WiFi stick with your Internet router, you can type:
gksu gedit /mnt/linuxroot/etc/network/interfaces
   (Same as before: modify the linuxroot base dir to your case)

And then rename every reference to wlan0 to wlan1 (the name Picuntu gives to my Wifi USB dongle at boot time, you can check yours with ifconfig if it doesn't work for you), and set your SSID + password. As an example here is my [mangled] interfaces file:
auto lo
iface lo inet loopback
auto wlan1
iface wlan1 inet dhcp
wpa-ssid MyWLANname
wpa-psk "MyWLANpassword"
Please note ssid does not have quotes, whereas the psk text password does need them.


7) Enter the "sync" command twice to write all changes, safely extract the MicroSD from the PC, and insert it into the Measy U2C stick (all terminal commands from now on are on the stick, not on the PC).


8) Boot into Android, get into the terminal, type "su" followed by "reboot recovery" (as indicated in previous Miniand's link as step 7).


9) Now the screen should show a typical Linux boot sequence and after a minute or so you'll be prompted to login (do so as root, with default password being 12qwaszx )


10) Type "depmod -a" and after it hit Ctrl-Alt-Supr to reboot, get into Android, do the Terminal+su+reboot recovery and be back into Linux


11) I have made a little init script with the following contents:

#load spanish keyboard
loadkeys es
#make sure console fits screen (or else missing bottom lines)
fbset -move up
#set to 0 or else every 120secs task kinteractiveup shows block debug warning
echo 0 > /proc/sys/kernel/hung_task_timeout_secs
#remove large module, since this Wifi chipset is not present!
modprobe -r 8188eu

    In my case I need the "fbset" line because for some reason the Linux prompt looks the usual 80x24 size, but I am missing the bottom lines once I get past the last line shown in screen. Using fbset the terminal gets the right resolution. If you want to see this issue, type (w/o quotes):  "find /." and see if you are missing the cursor when it finishes listing.

UPDATE: The "fbset" thing was due to the monitor displaying a resolution of 720p (look in the OSD), even though the monitor is capable of HDTV 1080p60 video timings, the kernel is also 1080p, and the system res is also 1080p... However, since 720p also happens when booting into Android, I'll blame it on the stick's HDMI I/F chip.


12) Try a ping to see if the WiFi dongle is connected:
ping www.google.es
If there is response, you are good to go, or else try "ifconfig" to see if the WiFi USB is detected and maybe check the Linux logs and the interfaces file to see if the correct Wifi and settings are there.



3rd) Getting a GUI into the stick


Now for this you should run as root, from the Picuntu Linux prompt, the script: picuntu-da-server.sh

This will guide you through the configuration, download & installation of the necessary packages, which may take very long (hours) depending on the Class (speed) of your MicroSD card.

In my case the GUI of choice is the very fast and lightweight XFCE. After install finishes, I can get into XFCE by typing: startxfce4

The GUI feels snappy and it's quite cool to have such a minimal computer with a real OS!! (Android who?).



UPDATE: Just arrived a Samsung 32GB MicroSD card Class 10 (UHS-1), system is much faster!

UPDATE: If you run into problems (CRASHES) when installing apps or trying to change settings in XFCE, you may be running into the same DBUS bug I did, click here for my post on how to fix it.



I hope this quick write-up helps other people get through these steps, since it's great to be able to run Linux (and a graphical one!). If you run into any problems or would like to remark something I may have missed, please don't hesitate to leave a constructive comment below.   :-)




Picuntu 0.9 RC3 crash in XFCE (dbus)



Symptoms:


If any of these happen to you:

- Ubuntu Software Center issues a crash report when clicking an app's "Install" button (plus install doesn't start)

- Settings Manager: crashes and no window opens when clicking over any of Settings icons (like "Language Support")



Spotting the problem:


Open a terminal and enter:
sudo cat /var/log/syslog
If the last lines report issues like:
Activated service '....' failed: Failed to execute program /usr/lib/dbus-1.0/dbus-dameon-launch-helper success
Then there likely are permission problems with the above mentioned dbus daemon helper. Now enter:
cd /usr/lib/dbus-1.0/
ll
If everything were right you would get the following result:

-rwsr-xr-- 1 root messagebus 170348 Oct 3 23:18 dbus-daemon-launch-helper*

Date/time/size are unimportant. The permissions (-rwsr-xr--) and group ownership (messagebus) is what matters.

In my case I got the following result:
-rwsr-xr-- 1 root ssh 170348 Oct 3 23:18 dbus-daemon-launch-helper*

 So the group ownership is dead wrong, preventing the file from being run properly.



Fix Procedure:


Enter the following commands:
sudo chgrp messagebus dbus-daemon-launch-helper
Now, doing "ll", you may find that the group is fine, but the permissions have changed. To correct them, type:
sudo chmod u=rwxs,g=rx,o=r dbus-daemon-launch-helper
Check that "ll" returns the above expected result and, then, safely restart the stick (you don't want to corrupt the SD flash card!):
sudo shutdown -P now 

Once you get back into Picuntu, the problem should be fixed.



References:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=659953


Picuntu XFCE problems' fixes

I'll use this blogpost as a kind of FAQ, including all the troubles & solutions I've found while using my Measy U2C RK3066 stick as a second PC with Picuntu 0.9 RC3 installed (with Xubuntu's XFCE).


Slow system


Get a Class 10 microSD card! :)
Seriously, it feels faster than a netbook.



Changing Default Language (only English installed)


To change the XFCE language it is necessary to do the following (this examples are for Spanish language, es_ES, change it to your language of preference):
sudo apt-get install language-pack-es
sudo locale-gen es_ES
dpkg-reconfigure locales 
If you now go to XFCE's System Settings and choose Language Support, you should see and be able to drag your language of preference to the top of the list. Changes happen after logging out and back in.

Reference:



Getting Parole to play videos (Gstreamer backend error)


I tried to play an mp4 file but Parole (the default video player) complained saying
"Gstreamer backend error. Configured videosink video is not working"

Solve it forever by opening, once, a terminal and writing:
parole --xv false
Note the two hyphens. From now on, opening any video should work, even after rebooting.

Reference:

Additionally you will find that the Home folder is empty, whereas usual Ubuntu distros do already contain several folders to classify your digital life (Downloads, Documents, Images, Music, etc.).
Solution is to manually create your own language's folders and then edit the file:
~/.config/user-dirs.locale
change en_US for your locale (for Spanish it's es_ES)
and then edit the file
~/.config/user-dirs.dirs
to point every variable to the right folder. For instance:
XDG_DESKTOP_DIR="$HOME/Escritorio"
XDG_DOWNLOAD_DIR="$HOME/Descargas"
and so on with the eight variables. Then run the following command:
xdg-user-dirs-update
Log out and back in and you should see the desktop containing only the files/shortcuts in folder "~/Escritorio" (or however "Desktop" is said in your language) and the rest of home folders with a nice icon.

Reference:



Missing last lines after first boot (before installing XFCE/Gnome)


The Linux prompt looks the usual 80x24 size, but I am missing the bottom lines once I get past the last line shown in screen. If you want to check if you have this issue, type:
find /.
and see if you are missing the cursor when it finishes listing.

You should also check your monitor's OSD to see what resolution is being displayed. In my case it was 1280x720 (also called 720p or just HD), whereas the kernel I had installed was 1920x1080 (also 1080p or FullHD). The incomprehensible thing is that my monitor is perfectly able (and so it shows in its EDID and normal PC use) of the typical HDTV 1080p60 mode.

I am skimming through the RK HDMI kernel code but I believe it has something to do with the way the EDID's CEA timings are read (TBC), since it also happens when booting into Android.

In any case, if you want to get rid of this problem and be able to properly run the script picuntu-da-server.sh, you can fix it by typing:
fbset -move up
Another way to get past this is to flash Picuntu's 720p kernel.


UPDATE: this is indeed a kernel bug, for the patch see http://hwswbits.blogspot.com.es/2013/03/bugfix-for-wrong-monitor-resolution-in.html




Reference:



Avoid kinteractiveup error in syslog


Add to /etc/rc.local the line:
echo 0 > /proc/sys/kernel/hung_task_timeout_secs
This avoids several syslog error lines about kinteractiveup task every 120 seconds.



32bpp screen instead of 16bpp (background color stripes)


Add to /etc/rc.local the lines:
echo 32 > /sys/devices/platform/rk-fb/graphics/fb0/bits_per_pixel
fbset -rgba 8/16,8/8,8/0,8/24 -a
Works for 1080p as well as 720p kernels.



For Measy U2C permanently remove module 8188eu


To avoid the 8188eu wireless driver module from being uselessly loaded at boot time (since that's not the Wifi chip on this stick), comment out (by preceding with a #) the line "8188eu" in /etc/modules as root:
sudo leafpad /etc/modules


XFCE Shutdown button just restarts the stick


If you click on the shutdown button but the stick just restarts, instead of powering off after shutting down, this is due to the command used by ConsoleKit (the dbus way used by XFCE to restart/shutdown), to solve it you have to modify the shutdown script (I had to Google hard to find this solution!).

Open a terminal and write:
sudo leafpad /usr/lib/ConsoleKit/scripts/ck-system-stop
and in the two places where it says "shutdown -h" change for "shutdown -H" (uppercase the h). This small difference instructs the system to halt after being brought down.

Actually the lowercase "h" lets the system choose between halting or powering off; however the system currently makes the wrong choice, and that's why we have to force it to halt. Probably something that could be fixed somewhere in the kernel code.

Reference:
http://unix.stackexchange.com/questions/30726/how-to-shutdown-with-consolekit-without-sysvinit-but-with-systemd



System deadlocks upon a few apps open


This happened to me, the system was completely unresponsive, not even letting me move the mouse and was caused by lack of free RAM. After more than 10 minutes of wait I had to take the power off.

Since filling the RAM is not so difficult, and there is no swap by default, the best solution is to create a swap file into the SD card (no need for repartitioning, it's just a file).

The best guide, and also a very simple one, to quickly add a swap file into the SD card is this one:
http://www.cyberciti.biz/faq/linux-add-a-swap-file-howto/



Can not change english language in Chromium 


There is a version mismatch in the Ubuntu Software Center. It installs Chromium version 22.0.1229.94, whereas the languages pack (chromium-browser-l10n) requires Chromium version 25.something.

The solution is to install the 22.0.... language pack from launchpad's repository, here:
http://launchpadlibrarian.net/119854807/chromium-browser-l10n_22.0.1229.94~r161065-0ubuntu1_all.deb



Fixes to use boot-picuntu to dualboot Picuntu/Android

If you have parsed the [outdated] Picuntu repo, you may have found the following dir:
http://code.google.com/p/rk3066-linux/source/browse/boot-picuntu/

It contains two scripts for Android and one for Picuntu that allow you to kind of set the default OS to boot the stick into, and an easy way to boot back into the other one.

However the README file contains a couple of typos that prevent it from working.


How-to


The way this is done is taking advantage of the "init.d" functionality that custom Android ROMs usually provide (in my case thanks to Bob's Finless ROM 1.4 for Measy U2C). If you don't have the folder /etc/init.d/ (in your Android filesystem, not on Picuntu!) then you probably can't use this.

First of all install, in your rooted Android, the ES File Explorer, open it and go to its Settings to check allow root access and to mount the root system with write permission.


Android files setup


Then just download file http://rk3066-linux.googlecode.com/git/boot-picuntu/40picuntu
and store it in /etc/init.d/    (easiest way may be copying and pasting from ES File Explorer)
now open a terminal emulator in Android, and type:
su
chmod 777 /etc/init.d/40picuntu
(note that in the README file it is erroneously typed "chown", instead of "chmod"). Make sure that upon download the file was not renamed as 40picuntu.bin or something like that (or else remove the dot and extension).

Then download file http://rk3066-linux.googlecode.com/git/boot-picuntu/go-picuntu.sh
and store it in /mnt/sdcard/    (easiest way may be copying and pasting from ES File Explorer)

now open a terminal emulator in Android, and type:
su
chmod 777 /mnt/sdcard/go-picuntu.sh
(note that in the README file it is erroneously typed "chown", instead of "chmod")


Android files corrections


Next step is to edit both files and comment (prefixing with a #) the line that reads:
DEVC="/dev/block/sda1"
to
# DEVC="/dev/block/sda1"
and also change line:
# DEVC="/dev/block/mmcblk0p1"
to
DEVC="/dev/block/mmcblk0"
(IMPORTANT: note that also the trailing "p1" has been removed!)
I do it with the bad-old "vi" through the Terminal emulator (just because I know the obscure key combinations for basic "vi" file manipulation), but you may prefer to use any Android text editor.

Last step is to run go-picuntu.sh from the Terminal emulator with:
su
sh /mnt/sdcard/go-picuntu.sh
and then you'll be always booting into Picuntu by default, until you run (in Picuntu) the script go-android.sh

Compiling Picuntu Kernel (Ubuntu Linux for RK3066 devices)


Starting from Picuntu Linux' source code, along with several tools, we will end up with a recovery.img file. This is used to flash the recovery partition of an RK3066 device, which will then be able to boot into Picuntu (Ubuntu Linux).



WARNING: You DO NOT need to follow these steps unless you want to modify Picuntu's kernel!
The stock kernel from Alok Sinha works fine and is very easy to install. Follow this guide:



Assuming the kernel is compiled from an x86 PC running an Ubuntu Linux:

#get the right packages for the compiler [3]
sudo apt-get install git-core gnupg flex bison gperf libsdl-dev libesd0-dev libwxgtk2.8-dev build-essential zip curl libncurses5-dev zlib1g-dev ia32-libs lib32z1-dev lib32ncurses5-dev gcc-multilib g++-multilib sharutils lzop

#start out from the user's home and create "rk" folder for all the work
cd ~
mkdir rk
cd rk

#toolchains folder is where the ARM compiler toolchain will be downloaded to [3]
git clone https://github.com/DooMLoRD/android_prebuilt_toolchains.git toolchains

#tools folder is where the mkbootimg tool (create recovery image) will be downloaded to [4]
git clone https://github.com/olegk0/tools.git

#initramfs folder is where the Picuntu kernel's .config file looks for initramfs.cpio (see CONFIG_INITRAMFS_SOURCE)
git clone https://github.com/Galland/rk30_linux_initramfs.git initramfs
cd initramfs
gzip -dc debian-3.0.8+fkubi.cpio.gz > initramfs.cpio
cd ..

#picuntu-3.0.8-alok is where we download the latest available Picuntu Linux kernel source code (0.9 RC3)
git clone https://github.com/aloksinha2001/picuntu-3.0.8-alok.git
cd picuntu-3.0.8-alok/


#copy Picuntu 0.9 RC3 config file (actually extracted from a running Picuntu, located at /proc/config.gz)
cp ../initramfs/config .config


#set the target architecture and toolchain location (CHANGE the base folder if you are not using ~/rk/)
export ARCH=arm
export CROSS_COMPILE=~/rk/toolchains/arm-eabi-linaro-4.6.2/bin/arm-eabi-

#launch the Kernel compilation (-j 4 indicates that 4 compiler threads run in parallel, I have a quad-core PC...)
make -j 4

#
# Kernel compilation takes some minutes...
# BTW, don't worry about the warnings while compiling
#

#last step is to generate the recovery.img to flash the recovery partition of the Android stick
cd ..
tools/mkbootimg --kernel picuntu-3.0.8-alok/arch/arm/boot/Image --ramdisk initramfs/fakeramdisk.gz --base 60400000 --pagesize 16384 --ramdiskaddr 62000000 -o recovery.img



Now flash recovery.img into the recovery partition and boot into Picuntu Linux, just like using the stock Picuntu kernel!




REFERENCES

[1] https://docs.google.com/folder/d/0B02hgWz32NpXcC1ONVBSLWx6RHc/edit

[2] http://www.slatedroid.com/topic/41654-pre-alpha-03-ubuntu-linux-for-mk802-iii-ug802-mk808-ug007-imito-mx1/page__view__findpost__p__502961

[3] http://www.armtvtech.com/armtvtechforum/viewtopic.php?p=5072#p5072

[4] http://www.slatedroid.com/topic/41654-pre-alpha-03-ubuntu-linux-for-mk802-iii-ug802-mk808-ug007-imito-mx1/page__view__findpost__p__495617

RK3066 Measy U2C stick power consumption


Today I've done an experiment I was curious about: measuring my Measy U2C's (RK3066 CPU) real power consumption.


Setup





      My current setup is the above Measy U2C powered (to the DC-5V Micro USB) by an HTC phone's USB power adapter (rated 5V 1A) connected to the DC-5V Micro USB port, through a breakout USB cable that allows me to place a multimeter in series (for current measurement) or in parallel (voltage).


The power consumers:

- The Measy U2C RK3066 stick running Picuntu Linux 0.9 RC3 (Xubuntu 12.10 Quantal Quetzal)
- A Logitech K400 wireless keyboard+mouse with its USB dongle in the USB 2.0 port
- A TP-Link TL-WN422G 802.11g WiFi stick in the side Micro USB
- An Acer X233H FullHD monitor to the HDMI connector



The variables:

- The stick is running Linux from a Samsung 32 GB Class 10 MicroSD
- RK3066 idle means just logged in XFCE with only conky running
- At idle the CPUs run at 252 MHz all the time ("ondemand" governor)
- RK3066 load means two threads at 100% CPU usage [1]
- For some reason my stick's CPUs won't go beyond 1.2 GHz at full load
- Picuntu kernel's DDR memory frequency is set at 300 MHz (below my stick's DDR3 chips' specs)
- Internal WiFi+BT, webcam, micro, and AV Out are not working from Linux (YET!)



Raw Measurements


- Current (in Amperes):

RK3066 idle = 0.24 A
RK3066 load = 0.5 A
RK3066 idle + HDMI connected (720p) = 0.29 A
RK3066 idle + TP-Link WiFi = 0.41 A
RK3066 idle + Logitech K400 = 0.28 A
RK3066 idle + TP-Link WiFi + Logitech K400 = 0.45 A
RK3066 idle + TP-Link WiFi + HDMI connected (720p) = 0.47 A
RK3066 idle + TP-Link WiFi + Logitech K400 + HDMI connected (720p) = 0.5 A
RK3066 load + TP-Link WiFi + Logitech K400 + HDMI connected (720p) = 0.75 A
RK3066 suspend = 0.13 A

- Voltage (in Volts):

In open circuit configuration (unconnected) = 4.77V
With RK3066 idle + WiFi + K400 + HDMI = 4.58 V
With RK3066 load + WiFi + K400 + HDMI = 4.52 V

Not the best in the world, eh.


Conclusions


So basically a bare idle RK3066 stick consumes approx. 0.24 A x 4.58 V = 1.1 Watts
Whereas at full load it goes up to 0.5 A x 4.52 V = 2.26 Watts

Now, with Ubuntu running on the RK3066, this is a low power PC!



References


[1] http://stackoverflow.com/questions/2925606/how-to-create-a-cpu-spike-with-a-bash-command

BUGFIX for wrong monitor resolution in Rockchip kernels

Finally found it!


Symptoms:


You have:
- a 1080p capable monitor
- a 1080p capable stick + kernel (Picuntu Linux on a Measy U2C RK3066 in my case)

But when booting on Android or Picuntu Linux the resolution looks wrong (specially in Linux).


Spotting the problem:


Open up your monitor's OSD and find the Info tab, where it should say which resolution it is displaying.

If it is 1280x720 then you have just run into this bug.


Fix Procedure:


Apply the patch indicated in [1] to your kernel's /drivers/video/fbmon.c
Recompile the kernel (if Picuntu Linux, see [2])
Enjoy 1080p




The Discovery :)


I must say I was thinking the blame was for the rk30_hdmi driver, however the bug was in the Linux kernel's EDID parser itself!

[N.B.: EDID is the contents of a very small ROM inside every digital TV & PC monitor, it summarizes the available and possible resolutions]

I ran up and down through the drivers/video/rockchip/hdmi/ folder looking for the place where the monitor's non-CEA EDID was being ignored, finding the function hdmi_ouputmode_select (rk30_hdmi_lcdc.c), which produced a sink_info in the kernel log that did not include the 1080p resolution.

After a couple of days, the following call sequence was found to be causing this:

hdmi_sys_parse_edid (rk30_hdmi_edid.c) -> hdmi_edid_parse_base (rk30_hdmi_edid.c) -> fb_edid_to_monspecs (../../fbmon.c)
and back in hdmi_sys_parse_edid (rk30_hdmi_edid.c) that called hdmi_ouputmode_select (rk30_hdmi_lcdc.c).

Since the EDID video modes themselves were being parsed by fbmon.c, I decided to delve into it just to know which modes it reported back to the rk30_hdmi driver.

Defining DEBUG in fbmon.c resulted in the list of 13 valid video modes extracted from the monitor's EDID. Of these, two looked extremely unusual:
1280x1280
1440x1440

So I looked up the monitor's EDID in another tool and, sure enough, the missing modes were:
1280x800
1440x900

It totally looked like the reported X-Y dimensions were being modified due to some erroneous aspect ratio calculation!!!

Digging further into the fbmon.c code, I found a totally suspicious:
static int get_std_timing(unsigned char *block, struct fb_videomode *mode) {
...
switch (ratio) {
case 0:
        yres = xres;
...

So indeed there was a place modifying a reported resolution into a "square" one (like 1440x1440, or 1280x1280) due to a ratio. However this behavior is so bizarre that I was sure it had been spotted before so I Googled for "get_std_timing" and "ratio" and found the kernel patch for this bug (see [1]).

What was happening back in the rk30_hdmi is that it took 1440x1440 as the largest resolution supported by the monitor, but couldn't match it to any of its hardcoded modes, so it just discarded it.

This is one of the problems of basing a system on Linux Kernel 3.0.8 when the latest version is 3.9

Hope it helps!



References


Measy U2C / B12 / NX003II Linux Microphone and Audio Out

As you may already know, the Measy U2C Android stick (AFAIK same hardware as Kimdecent B12 and NX003II sticks) contains an A/V Out (right besides the HDMI connector, in the picture below) and an integrated digital microphone (MIC in the picture below).

You can insert the typical stereo headphones jack into the A/V out and listen to music from there, in case your screen doesn't have HDMI audio, like my PC monitor.





However, if you want to use the mic and headphones from Linux (i.e. Picuntu) you will need to recompile the kernel (actually quite easy) enabling the following options in the ".config" file at the kernel source's root path.

Where it says (each line is in a different part, and the last may not be there at all):
# CONFIG_MFD_RK1000 is not set
# CONFIG_SND_RK29_SOC_RK1000 is not set
# CONFIG_SND_SOC_RK1000 is not set
and make them be (add if necessary):

CONFIG_MFD_RK1000=y
CONFIG_SND_RK29_SOC_RK1000=y
CONFIG_SND_SOC_RK1000=y
Compile and flash. Once Linux boots, open a terminal and type:
alsamixer -c 0 -V capture
You should see the microphone input, make sure the volume is at an adequate level, then exit and type:
arecord -f cd -D hw:0,0 test.wav
Hit enter and speak to the MIC, hit Ctrl-C to stop it and enter:
aplay test.wav
And you should hear the mono sound you have just recorded.

From XFCE I use PulseAudio's Volume Control app to select the headphone output, instead of HDMI, try it if you don't get to hear anything.

One step closer to full Linux support!! :)


References:

Measy U2C Webcam support in Linux RK3066


Since one of my goals for my Measy U2C stick is to use it as an in-home security camera, thanks to its integrated microphone and webcam (model GC2035 from GalaxyCore), I had to find a way to support them in Picuntu Linux (the RK3066 based Xubuntu 12.10 from developer Alok Sinha).



Wouldn't it serve its purpose running headless (no monitor) and attached to this battery or to a phone charger, ready to send an email to your phone upon sensing too much noise or "seeing" somebody? and we are talking of a CPU with Video encoding capabilities!

So, there is one of the motivations, now onto the quest. The first problem was that Picuntu does not include a driver for the GC2035 CMOS sensor (and the GC2015 it supports is different enough not to be fine), so I set out to github.com and its awesome code search just to find the latest RK3066 kernel (for Android Jelly Bean support), some months more modern than the one Picuntu uses.

Since porting Picuntu Linux to the JB (Jelly Bean) RK3066 kernel is taking me some time, at least I have made enough changes to successfully port the GC2035 driver.
Image may be NSFW.
Clik here to view.
Note the "(GC2035)" below the CMOS sensor at the right


I believe the Kimdecent B12 and, probably, the NX003II sticks are clones of the Measy U2C, in which case this solution would also work for them. If you are the owner of an RK3066 stick with integrated camera and are willing to take high resolution pictures of both sides of your PCB, we could all confirm that.


To add the driver to your Picuntu Linux stick, you have to recompile the kernel (quite easy actually) following the steps in this post but in the step where you download the latest Picuntu source code:
git clone https://github.com/aloksinha2001/picuntu-3.0.8-alok.git
you have to instead download the updated source code*:
git clone git://github.com/Galland/picuntu-3.0.8-alok.git
The rest of the instructions are exactly the same and you can still use the same SD card installation of Picuntu that you already have, since it doesn't change (only the kernel that goes inside the stick's flash recovery partition).

You'll just find that, upon bootup, the gc2035 driver is loaded and attached as a front camera (front_2) and the new device appears as:
/dev/video0

[*] You can review the changes by parsing through my commit history or just know that I've mostly added the GC2035 driver, updated the machine config to "talk" to this CMOS sensor and added a few notable bugfixes from Rockchip's JB kernel.



The catch


While the system can indeed communicate with the sensor, I've found that the driver is able to output NV12, NV21, NV16, or NV61 Video4Linux2 pixel formats (the way in which the luminance and chrominance samples of pixels are set up in the buffer where a captured image is sent to apps).

This would be fine unless for the fact that I haven't found an application able to get that V4L2 format and save an image to disk from it, though I haven't searched that much, I must say (see below).

While I temporarily move on to other tasks in this Linux support "challenge", this is a part where you, dear Measy U2C or clone owner, could be of great help, by googling and testing to get this very last step through! :-)

Even if you only find an app that dumps the raw NV* capture to a file, I can very quickly write a tool to transform it to a viewable RGB format.



My brief findings


Using the app "fswebcam" the output is the following:

user@picuntu:~$ fswebcam -v output.jpg
--- Opening /dev/video0...
Trying source module v4l2...
/dev/video0 opened.
src_v4l2_get_capability,87: /dev/video0 information:
src_v4l2_get_capability,88: cap.driver: "rk-camera-rk30"
src_v4l2_get_capability,89: cap.card: "gc2035_front_2-270"
src_v4l2_get_capability,90: cap.bus_info: ""
src_v4l2_get_capability,91: cap.capabilities=0x04000001
src_v4l2_get_capability,92: - VIDEO_CAPTURE
src_v4l2_get_capability,103: - STREAMING
No input was specified, using the first.
src_v4l2_set_input,181: /dev/video0: Input 0 information:
src_v4l2_set_input,182: name = "Camera"
src_v4l2_set_input,183: type = 00000002
src_v4l2_set_input,185: - CAMERA
src_v4l2_set_input,186: audioset = 00000000
src_v4l2_set_input,187: tuner = 00000000
src_v4l2_set_input,188: status = 00000000
src_v4l2_set_pix_format,541: Device offers the following V4L2 pixel formats:
src_v4l2_set_pix_format,554: 0: [0x3231564E] 'NV12' (YUV420 NV12)
src_v4l2_set_pix_format,554: 1: [0x3631564E] 'NV16' (YUV422 NV16)
src_v4l2_set_pix_format,554: 2: [0x3132564E] 'NV21' (YUV420 NV21)
src_v4l2_set_pix_format,554: 3: [0x3136564E] 'NV61' (YUV422 NV61)
src_v4l2_set_pix_format,554: 4: [0x3231564E] 'NV12' (YUV420 NV12)
src_v4l2_set_pix_format,554: 5: [0x3631564E] 'NV16' (YUV422 NV16)
src_v4l2_set_pix_format,554: 6: [0x3132564E] 'NV21' (YUV420 NV21)
src_v4l2_set_pix_format,554: 7: [0x3136564E] 'NV61' (YUV422 NV61)
Unable to find a compatible palette format.



Whereas VLC tries to access it in four different ways, unsuccessfully (notice the warnings):

main debug: adding item `v4l2:///dev/video0' ( v4l2:///dev/video0 )
qt4 debug: Adding a new MRL to recent ones: v4l2:///dev/video0
main debug: no fetch required for (null) (art currently (null))
main debug: rebuilding array of current - root Lista de reproducción
main debug: rebuild done - 1 items, index -1
main debug: processing request item: v4l2:///dev/video0, node: null, skip: 0
main debug: resyncing on v4l2:///dev/video0
main debug: v4l2:///dev/video0 is at 0
main debug: starting playback of the new playlist item
main debug: resyncing on v4l2:///dev/video0
main debug: v4l2:///dev/video0 is at 0
main debug: creating new input thread
main debug: Creating an input for 'v4l2:///dev/video0'
main debug: using timeshift granularity of 50 MiB, in path '/tmp'
main debug: `v4l2:///dev/video0' gives access `v4l2' demux `' path `/dev/video0'
main debug: creating demux: access='v4l2' demux='' location='/dev/video0' file='/dev/video0'
main debug: looking for access_demux module: 1 candidate
v4l2 debug: opening device '/dev/video0'
qt4 debug: IM: Setting an input
v4l2 debug: trying kernel V4L2
v4l2 debug: device gc2035_front_2-270 using driver rk-camera-rk30 (version 0.2.14) on 
v4l2 debug: the device has the capabilities: 0x04000001
v4l2 debug:  (X) Video Capture, ( ) Audio, ( ) Tuner, ( ) Radio
v4l2 debug:  ( ) Read/Write, (X) Streaming, ( ) Asynchronous
v4l2 debug: video input 0 (Camera) has type: External analog input *
v4l2 debug: input set to 0
v4l2 debug: device codec NV12 (YUV420 NV12) not supported
v4l2 debug: device codec NV16 (YUV422 NV16) not supported
v4l2 debug: device codec NV21 (YUV420 NV21) not supported
v4l2 debug: device codec NV61 (YUV422 NV61) not supported
v4l2 debug: device codec NV12 (YUV420 NV12) not supported
v4l2 debug: device codec NV16 (YUV422 NV16) not supported
v4l2 debug: device codec NV21 (YUV420 NV21) not supported
v4l2 debug: device codec NV61 (YUV422 NV61) not supported
v4l2 debug: found default width and height of 640x480
v4l2 debug: will try to find optimal width and height
v4l2 warning: Could not select any of the default chromas; attempting to open as MPEG encoder card (access)
v4l2 debug: trying library V4L2
v4l2 debug: device gc2035_front_2-270 using driver rk-camera-rk30 (version 0.2.14) on 
v4l2 debug: the device has the capabilities: 0x05000001
v4l2 debug:  (X) Video Capture, ( ) Audio, ( ) Tuner, ( ) Radio
v4l2 debug:  (X) Read/Write, (X) Streaming, ( ) Asynchronous
v4l2 debug: video input 0 (Camera) has type: External analog input *
v4l2 debug: input set to 0
v4l2 debug: device codec NV12 (YUV420 NV12) not supported
v4l2 debug: device codec NV16 (YUV422 NV16) not supported
v4l2 debug: device codec NV21 (YUV420 NV21) not supported
v4l2 debug: device codec NV61 (YUV422 NV61) not supported
v4l2 debug: device codec NV12 (YUV420 NV12) not supported
v4l2 debug: device codec NV16 (YUV422 NV16) not supported
v4l2 debug: device codec NV21 (YUV420 NV21) not supported
v4l2 debug: device codec NV61 (YUV422 NV61) not supported
v4l2 debug: device supports chroma RV24 [RGB3, RGB3]
v4l2 debug: device supports chroma RV24 [BGR3, BGR3]
v4l2 debug: device supports chroma I420 [YU12, YU12]
v4l2 debug: device supports chroma YV12 [YV12, YV12]
v4l2 debug: found default width and height of 640x480
v4l2 debug: will try to find optimal width and height
v4l2 warning: Could not select any of the default chromas; attempting to open as MPEG encoder card (access)
main debug: no access_demux module matching "v4l2" could be loaded
main debug: TIMER module_need() : 885.952 ms - Total 885.952 ms / 1 intvls (Avg 885.952 ms)
main debug: creating access 'v4l2' location='/dev/video0', path='/dev/video0'
main debug: looking for access module: 1 candidate
v4l2 debug: opening device '/dev/video0'
v4l2 debug: trying kernel V4L2
v4l2 debug: device gc2035_front_2-270 using driver rk-camera-rk30 (version 0.2.14) on 
v4l2 debug: the device has the capabilities: 0x05000001
v4l2 debug:  (X) Video Capture, ( ) Audio, ( ) Tuner, ( ) Radio
v4l2 debug:  (X) Read/Write, (X) Streaming, ( ) Asynchronous
v4l2 debug: video input 0 (Camera) has type: External analog input *
v4l2 debug: input set to 0
v4l2 debug: device codec NV12 (YUV420 NV12) not supported
v4l2 debug: device codec NV16 (YUV422 NV16) not supported
v4l2 debug: device codec NV21 (YUV420 NV21) not supported
v4l2 debug: device codec NV61 (YUV422 NV61) not supported
v4l2 debug: device codec NV12 (YUV420 NV12) not supported
v4l2 debug: device codec NV16 (YUV422 NV16) not supported
v4l2 debug: device codec NV21 (YUV420 NV21) not supported
v4l2 debug: device codec NV61 (YUV422 NV61) not supported
v4l2 debug: device supports chroma RV24 [RGB3, RGB3]
v4l2 debug: device supports chroma RV24 [BGR3, BGR3]
v4l2 debug: device supports chroma I420 [YU12, YU12]
v4l2 debug: device supports chroma YV12 [YV12, YV12]
v4l2 debug: found default width and height of 640x480
v4l2 debug: will try to find optimal width and height
v4l2 debug: Driver requires at most 460800 bytes to store a complete image
v4l2 debug: Interlacing setting: progressive
v4l2 error: mmap failed: Cannot allocate memory
v4l2 debug: trying library V4L2
v4l2 debug: device gc2035_front_2-270 using driver rk-camera-rk30 (version 0.2.14) on 
v4l2 debug: the device has the capabilities: 0x05000001
v4l2 debug:  (X) Video Capture, ( ) Audio, ( ) Tuner, ( ) Radio
v4l2 debug:  (X) Read/Write, (X) Streaming, ( ) Asynchronous
v4l2 debug: video input 0 (Camera) has type: External analog input *
v4l2 debug: input set to 0
v4l2 debug: device codec NV12 (YUV420 NV12) not supported
v4l2 debug: device codec NV16 (YUV422 NV16) not supported
v4l2 debug: device codec NV21 (YUV420 NV21) not supported
v4l2 debug: device codec NV61 (YUV422 NV61) not supported
v4l2 debug: device codec NV12 (YUV420 NV12) not supported
v4l2 debug: device codec NV16 (YUV422 NV16) not supported
v4l2 debug: device codec NV21 (YUV420 NV21) not supported
v4l2 debug: device codec NV61 (YUV422 NV61) not supported
v4l2 debug: device supports chroma RV24 [RGB3, RGB3]
v4l2 debug: device supports chroma RV24 [BGR3, BGR3]
v4l2 debug: device supports chroma I420 [YU12, YU12]
v4l2 debug: device supports chroma YV12 [YV12, YV12]
v4l2 debug: found default width and height of 640x480
v4l2 debug: will try to find optimal width and height
v4l2 debug: Driver requires at most 460800 bytes to store a complete image
v4l2 debug: Interlacing setting: progressive
v4l2 error: device does not support mmap I/O
main debug: no access module matching "v4l2" could be loaded
main debug: TIMER module_need() : 226.883 ms - Total 226.883 ms / 1 intvls (Avg 226.883 ms)
main error: open of `v4l2:///dev/video0' failed
main debug: finished input
main debug: dead input
main debug: changing item without a request (current 0/1)
main debug: nothing to play
qt4 debug: IM: Deleting the input



BTW, this article has been posted with Picuntu (Xubuntu) on the Measy U2C


RK3066 SDK board schematic

Look what I found googling around... the RK3066 SDK schematics!

For those that don't know, all this flood of RK sticks is due to Rockchip handing out those schematics to OEMs, which just remove the parts that don't fit their application (for example no G-sensor or no touchpad for a TV stick).

So, for the case of most RK3066 TV sticks around it is most usual to find the following chips inside them:

Power Management Unit: Texas Instruments TPS659102
Wifi: Mediatek MT5931
Bluetooth: Mediatek MT6622 (actually in the same bundle board with the Wifi chip)

Well, those are the chips depicted in this RK3066 SDK schematic (page 16 for Wifi+BT, and page 6 indicates TPS659102, even if WM8326 is mentioned in page 4).

For the case of my Measy U2C, which has an integrated webcam, the schematic part referring to the front camera (page 15) has also been of help (even if just to know it's rigged to I2C bus 3).

However the CODEC chip used here is the RK Jetta (i.e. RK610), not the RK1000 used in my stick.


UPDATE: Please note that above schematic is different and more recent (Jan 2013) than the one already known (Feb 2012), which uses PMU WM8326, Wifi+BT RK903 (BCM40183 - Broadcom 4330 Based Chipset).




Since my stick also has an A/V out (stereo headphone connection but with TV Out, missing on above schematic), an integrated microphone and a RK1000-S A/V CODEC chip, I've found this other old schematic that shows up how that part is likely set up on page 6 of this RK2818 schematic.




Why is this important?

Because for proper Linux support it is necessary to know which RK3066 pins are connected to what pins of other chips.
So it's not enough with having the source code of the Wifi MT5931 driver in order to enable it in Linux, you must also know how it is connected to the RK3066 CPU.


Also, since I'm currently debugging the unthinkable power consumption when the stick is turned "off" (from Android and Linux, so... kernel bug or PCB design catastrophe), the TPS659102 PMU connections along with its datasheet will shed some light on it.


Hopefully with these schematics we are another step closer to better Linux support.


BTW, if you are also working on supporting TV sticks in Linux (like for example Picuntu), drop me a line, we can probably help each other!



UPDATE 2: Reverse-engineering the Measy U2C stick


From a "high-megapixel" Measy U2C PCB inspection, trying to identify the remaining (tiny) chips, and by looking for SOT23 packages in the schematics, I've identified several other discrete components of  >2 pins:

- Another PM related [tiny] SOT23-6 chip, the Silergy SY8009B is U14 in the schematic (due to the nearby 3R3 inductor, or else it could've been U18) providing the VDD_LOG (1.1V) voltage that the original WM8326 regulator had (see p.4 of SDK schematic), but the TPS659102 doesn't (compare pp. 4 and 6). It's just below the MicroSD slot, marked "CU2UJ":

Image may be NSFW.
Clik here to view.
Measy U2C close up (in case you wonder, there is nothing under the GC2035)

- One SOT23 (3 pins) BAT54RS Schottky diode marked "LD3", just below the HDMI connector.

- Two SOT23 N channel [Enh. Mode] FET components of type DMN2170U labelled "21N" and found below the A/V out (which is above the HDMI). In my opinion, from their closeness to the HDMI connector, they are replacing Q14 and Q15, marked 2SK3018 in the schematic, and required for proper screen EDID reading.

- One/two SOT23 NPN transistor L8050QLT marked "1YC" to the right of the A/V out (right through, on the other side, there is another SOT23 that I think is the same type). If it weren't because these are NPN transistors, instead of FETs, I'd say they were stereo headphone related (so close to it!) and substituting the FETs Q12 and Q13, of type APM2306, in the RK1000 related schematic above. But my electronics are so far in the past that this could be blasphemy :)


Image may be NSFW.
Clik here to view.
BTW: no CPU heatsink for Measy :(

- A SOT23 chip marked "W41M" near the upper left corner of the Wifi+BT module (the brown board) that I haven't been able to identify yet.

Image may be NSFW.
Clik here to view.
MT6622 BT chip and MT5931 Wifi on the brown module and single antenna

Do you think those are many SOT23 components? Well, they are much less than those on the schematic!

Some are missing because there is no LCD and some others just because the system power comes from the USB, heavily simplifying the power part (or else it'd have to generate 5V for the USB OTG port).

However there are also unpopulated parts in the PCB and I am still missing some three pin components (like USB detection interrupt).



One particular component that I fear is missing is Q17, a FET for the PMU's PMIC_SLEEP with the following significative text (p. 7): "Note: Reduce the power consumption in deep sleeping. Place it near to crystal."

Maybe the "W41M" unknown component, which is not so far from the PMU could be this Q17? I hope so!


Rockchip RK1000-S


Brief post to explain my findings about the RK1000-S chip present on my Measy U2C RK3066 stick:

Image may be NSFW.
Clik here to view.
RK1000-S TV Out and Audio CODEC chip on Measy U2C stick


From the probable schematics of the Ramos W9, we see the video data lines (LCD_D*) coming out of the RK2818 CPU go to three different places:
- an LCD connector, uninteresting,
- a chip labelled ANX7150, whouse output is the HDMI connector
- the RK1000-S chip, whose outputs are the headphones and the TV Out

Hence, the RK1000-S, that up until now I had supposed was an HDMI transmitter, is actually only an Audio CODEC chip with TV Out functionality, with no HDMI capabilities whatsoever.

I should have arrived to this conclusion earlier, since the RK3066 actually is able to drive the HDMI output by itself (see p.14).

Flash on Picuntu Linux ARM


Until now I had been using Gnash, the extremely poor open substitute of Flash, which is actually unusable for any real purposes.


A couple weeks ago I read that it could be possible to have Flash on ARM by using the Flash Player that Adobe develops for the Chrome OS (used on the Samsung Chromebook ARM laptops).

So I found a page (see Reference below) that described what to do and, most importantly, provided the ARM compiled library that contains the official Flash Player.

Hence, the steps to have Flash up and running on the Chromium web browser in Picuntu (Xubuntu 12.10 for RK3066 devices) are:

1) Download compressed library
2) Copy the .so file to /usr/lib/
3) Change the Chromium shortcut from just:
chromium-browser
to the following single line:
chromium-browser --ppapi-flash-path=/usr/lib/libpepflashplayer.so --ppapi-flash-version=11.5.31.105 --ppapi-flash-args=enable_hw_video_decode=0,enable_stagevideo_auto=0,enable_trace_to_console=0 
4) Open Chromium and enjoy the real Flash, only limited by the maximum speed of your stick!



Reference
http://forum.xda-developers.com/showthread.php?t=2010440

3D HW acceleration on Picuntu Linux (Mali400)



I have ported olegk0's kernel (https://github.com/olegk0/rk3066-kernel) updates and Mali driver to Picuntu on my Picuntu kernel branch (https://github.com/Galland/picuntu-3.0.8-alok).

I'm testing and it seems very stable. glxgears reports now 85fps 3D, whereas before I was getting 5fps (3D in software), if I remember well. (glxgears is OpenGL, not OpenGL-ES, which is the HW accelerated one by Mali! thanks to Jean-Luc Aufranc for pointing it out) glmark2-es2 reports a glmark2 score of 80, and es2gears reports some 150fps.

Please note that Mali is the GPU on the RK3066, responsible for 2D/3D acceleration, not for HW video en/decoding! That's done by the VPU core, which is still unsupported.

Please note that, afaik, all of this is work done by olegk0 (see [1]) and I have just checked it does work on our Picuntu, so all cheers go to him, thanks for the great work, olegk0!

If you would like to test this too, grab my github kernel and follow the instructions on [1] or these Picuntu-targeted instructions here:

1) Get xorg.conf and place it on your Picuntu MicroSD's folder /etc/X11/

2) Get rk30fb_drv.so and place it on your Picuntu MicroSD's folder /usr/lib/xorg/modules/drivers/

3) Modify /etc/rc.local by commenting (precede with #) all lines that use "fbset" and adding the following line:
chmod 666 /dev/mali /dev/ump

4) Modify /etc/modules to add the following:
rk29-ipp
ump

disp_ump
mali
drm
mali_drm

5) Get the mali package, uncompress and install this file: mali400_2.1-13_armhf.deb

6)  Get my github kernel code and compile it, just make sure that you do this too:

- I'm using the Measy U2C stick, which has DDR3 1333 9-9-9 capable memory, but this may not be your case and may cause your system to not boot. So just before compiling ("make -j 4") do "make menuconfig" and get inside "System Type" and there set "DDR Memory Type" to "DDR3 (Type default)" and "DDR SDRAM frequence (in MHz)" [sic] to "333".

- Also please note that my kernel is set to Maximum CPU frequency of 1.6 GHz (instead of 1.2 GHz in stock Picuntu), so use at your own risk!!!!! For added safety you can make your CPU run cooler by setting (in above menuconfig) into "CPU Power Management" --> "CPU Frequency scaling" --> "Default CPUfreq governor" to "conservative" or "powersave", so it will rarely go to high frequencies (but it'll be slower). My CPU does fine with 1.6 GHz without any heatsink, and usually runs at 60-70 ºC, with 80+ spikes :S however voltage scaling is known to work on my stick (not on others I fear).

- You may also want to check on "Device Drivers" -> "Network device support" -> "Wireless LAN" that your Wifi chip/stick is selected there, for its driver to be compiled. My kernel is, currently, more up to date than others, and as you will see, there is a driver for the RK903 Wifi. However, since I don't own a stick that has it, I haven't been able to test. Please let me know if it works for you :)

- After compiling, you have to do "make modules" too, this is very important!

- Then do "make modules_install" and go to your PC's /lib/modules to grab the full "3.0.8+alok" folder and copy it to your Picuntu MicroSD's /lib/modules folder (or just do all this on your Picuntu Linux!!:), then boot up your Picuntu stick and type in a terminal "depmod -a" so it will parse the new modules and restart Picuntu.

- After doing that you can flash the recovery partition with the compiled kernel


This could sound complicated but kernel tinkering is actually pretty straightforward and works! :)  Hope it helps and check your temperature with: cat /sys/module/tsadc/parameters/temp*
Use at your own risk!!


UPDATE: If you get a poor es2gears score, then you may have to also do this:
mv /usr/lib/arm-linux-gnueabihf/mesa-egl/ /usr/lib/arm-linux-gnueabihf/.mesa-egl/ 

And if you run into an "Illegal instruction" error or a sudden reboot... your stick needs a heatsink... I spent the whole glmark2-es2 test blowing air to mine!
This is due to my overclocking the GPU from 266 MHz to its limit of 400 MHz, I'll probably undo this in the github kernel too :)


MK808 note: If you have a MK808 you may want to compile olegk0's kernel instead of mine, because MK808 uses a different "LCDC video port" for HDMI output (1 instead of 0), which requires some minor code changes. However my kernel is more up to date (less bugs, less power consumption, etc.) than his, so I must recommend it for other sticks.



Reference
http://www.slatedroid.com/topic/55626-my-version-of-the-linux-kernel-for-mk808/
http://linux-sunxi.org/Binary_drivers

Compiling the Mali HW accelerated driver (xf86-video-fbdev for RK3066)


Expert Linux developer olegk0 has made a framebuffer driver for the RK30 HDMI with Mali acceleration (rk30fb_drv.so). You can just download and use his .so to have 3D acceleration, or you can follow these instructions to compile it yourself and help debug it.

Among other things, like 2D/3D, it allows playing fullscreen videos with far less CPU usage, leaving the processor just for what your app requires to decode the videos. With "app" I mean Parole, VLC or, my strong recommendation, the excellent commandline utility: mplayer (which immediately takes advantage of the HW acceleration).

The downside is that it still has some bugs, like turning everything in the screen black (except the played video). Just move the mouse or a window around and everything gets redrawn again.
Another bug is that the video output becomes mangled when the video window touches the left or right sides of the screen.

In any case I love to be able to watch movies/videos on this stick with Linux, so what I do is open a terminal and type:
mplayer whatever-video.avi
And screen turns black except the video, I move the mouse a bit around (which causes the black parts to be redrawn) to find the corners of the mplayer video window and make it big enough to cover most of the screen, just without touching either left or right sides of the screen.


In any case, if you would like to give us a helping hand debugging the XVideo implementation (my suspect is ./xf86-video-fbdev/src/video.c) just follow these steps to tinker with the code and compile the driver to see the changes:

git clone git://github.com/olegk0/xf86-video-fbdev.git
sudo apt-get install xserver-xorg-dev

We must then fix a dangling symlinked folder at "./xf86-video-fbdev/src/ump" pointing to "../../../../../r3p1/ump/include/ump"

So go to http://malideveloper.arm.com/develop-for-mali/drivers/open-source-mali-gpus-ump-user-space-drivers-source-code-2/ and download the same revision (r3p1, until we get a first working driver; then we can try with a newer version), that is: Linux Kernel Device Driver r3p1-01rel1

Copy or symlink the uncompressed folder "./DX910-SW-99006-r3p1-01rel1/driver/src/ump/include/ump" to "./xf86-video-fbdev/src/ump"

And now just do:
./configure --prefix=/usr
make
sudo make install
There is a lot of debug information printed on /var/log/syslog every time you play a video with mplayer, which should help in the debugging.

Unofficial new 3.0.36+ kernel for Picuntu Linux

The kernel you can find on Picuntu releases is 3.0.8-alok+, but a few weeks ago I found a 3.0.36 kernel for RK devices in github, which was released by Spanish tablet maker bq (support them if you can by buying their devices).

I soon set out to compile it for use with Picuntu Linux (i.e. Xubuntu for Rockchip ARM CPUs), with some help from fellow developer Omegamoon, who is also doing a great work on OpenELEC XBMC Linux for RK devices.

Then, after adding some of the kernel fixes I've published in previous blogposts (to me the most important is the one that fixes support for 1080p monitors) as well as addingMali 3D HW acceleration support (thanks Olegk0 for your great work!) I tested this kernel and it's more stable than the previous.

I've also noticed that an issue with USB has disappeared (on kernel 3.0.8 I experienced USB dis-/re-connects very often, which disabled USB devices for several seconds).

Please note that I am so in love with the extreme low power nature of these devices and their noiselessness that I am using my Measy U2C as a "PC stick" and work with it as much as I can (using the excellent lightweight XFCE windows manager), since you can install all the SW in the Ubuntu Software Center plus any other programs can be compiled straight away for ARM from within Picuntu itself (no need for cross-compilers).

Image may be NSFW.
Clik here to view.
Picuntu kernel 3.0.36+ running with Mali 3D on my RK3066 stick

All my code changes and fixes are publicly available in my github repositories (in this case here) but, since many people are not too comfortable compiling the kernel from sources, I've decided to release a generic 3.0.36+ image and modules+firmware so you can enjoy too this new level of stability and performance with your Picuntu Linux.

You can find the 1080p kernel 3.0.36+ recovery imagehere (compressed with .7z)
and the 720p kernel 3.0.36+ recovery image here (compressed with .7z)
And the modules+firmwarehere (also .7z to be decompressed in the root folder of your Picuntu MicroSD).


My recommendation is to also install the following enhancements to your Picuntu MicroSD filesystem:
- Flash support for Chromium web browser
- Mali 3D HW XF86 drivers (the above kernel includes the necessary Mali modules, but to enable them you also need these steps, except the last step of kernel compilation!)
- If you are going to use your stick as a PC, I strongly recommend adding a swap file to avoid "deadlocking" your Linux due to lack of RAM, look for "swap" here


BTW, I've enabled RK903 Wifi driver on the kernel configuration. However, I don't own a stick with the RK903, so I can't test if it works. In any case don't expect Wifi chips that didn't work with previous kernel to work with this one, since nothing has changed there, afaik.

If you find any troubles, I usually answer questions on Miniand's Picuntu Linux forum, so don't hesitate to post your issues there :)



Disassembling .uu files

Quick post to not forget this procedure :)

Let's say we have a .uu file that is a "uu-encoded" (a kind of hex encoding of a binary file) compiled object file, for example:
https://github.com/Galland/rk3x_kernel_3.0.36/blob/master/arch/arm/mach-rk30/ddr.uu

In order to peek into its internals we would have to download it and:

1) Decode the file:
 uudecode rk3x_kernel_3.0.36/arch/arm/mach-rk30/ddr.uu -o ddr.o

2) Disassemble it with the specific ARM toolchain:
toolchains/android-toolchain-eabi/arm-eabi/bin/objdump -d ddr.o > disassembled-ddr.asm

The latest version (4.8) of the Linaro ARM toolchain can be downloaded from this place (thanks Omegamoon):

The result is at dissasembled-ddr.asm and, for the above ddr.uu, can be seen here.

Linux on RK3188 work in progress

Please note this is not a blog post, it's a my personal pastebin where I can put in writing to myself and other fellow developers the small things I find in the latest 3.0.36 kernel that supports rk3188 devices.



MALI and CONFIG_SYNC ( sync_fence_cancel_async )

Talking about Omegamoon's codebase (but with backported drivers folder from my previous one)

Once MALI is configured in as:

CONFIG_DRM=m
CONFIG_DRM_MALI=m
# CONFIG_ION is not set
CONFIG_MALI=y
CONFIG_MALI400=m
# CONFIG_MALI400_DEBUG is not set
# CONFIG_MALI400_PROFILING is not set
CONFIG_MALI400_UMP=y
CONFIG_UMP=m
# CONFIG_UMP_DEBUG is not set

And /include/drm/drm.h is backported to rk3x's version, that is, the first:
#if defined(__linux__)
becomes:
#if defined(__KERNEL__) || defined(__linux__)

Then compiling throws this new error:
drivers/gpu/mali/mali/common/mali_kernel_core.c:1084:4: error: implicit declaration of function 'sync_fence_cancel_async'

That function is called because now CONFIG_SYNC is forced by PLAT_RK and should be implemented in /drivers/base/sync.c (see http://lists.linaro.org/pipermail/linaro-mm-sig/2012-June/002050.html) but it's missing.
Hence, since MALI has worked without CONFIG_SYNC and a quick grep of the codebase shows it's the only driver talking about CONFIG_SYNC, my fix for this is removing the dependence with PLAT_RK by going to /arch/arm/Kconfig
and in the config for PLAT_RK commenting the following lines:

#select SYNC
#select SW_SYNC
#select SW_SYNC_USER


and then in the .config removing:

CONFIG_SYNC=y
CONFIG_SW_SYNC=y
CONFIG_SW_SYNC_USER=y


Also had to add this line at the top of /drivers/video/rockchip/rk_fb.c due to missing references to 'GET_UMP_SECURE_ID_BUF2':

#include "mali_def.h"


Measy U2C HW serial console pins

A hardware serial console is a little module soldered to at least two pin pads of a CPU (in this case the RK3066 of the Measy U2C stick) in order to transmit to a PC the stick's boot log sequence happening long before the screen turns on.

Naturally, if a kernel (like the latest one) refuses to boot and does not even get to turn on the screen, the only way to debug the reason is to use the serial console.

With the indications and the useful blogpost (for MK808) of fellow developer Omegamoon, I set out to find the two pins necessary to watch in my PC the boot sequence, that is:

- TXD: the pin where the CPU outputs the console text
- Ground: the necessary reference for the electrical levels in TXD

These had to be connected to the RXD and GND pins, respectively, of a hardware serial-to-USB module, that is then plugged to a PC's USB port. If anybody wonders about the CPU's RXD pin, it is not necessary unless you want to send commands to the stick once it's booted.

In the PC I myself use Ubuntu's CuteCom console app, connecting to serial port /dev/ttyUSB0 at 115200 bauds 8 bits data, 1 bit stop, no parity, and no handshake.


The way in which I found the RK3066's TXD pin was by trial and error. But since I saw there were small circular pads around the same area where Omegamoon had found his stick's TXD/RXD, I supposed mine should be close.

Hence, I first soldered the ground cable to the micro USB port on top of the RK3066 CPU and started very carefully making the serial-to-USB module's RXD pin's cable touch the different pads while powering on the stick, until I found the one that was transmitting data: TXD and proceeded to solder the cable and make the smallest possible hole in the Measy U2C's enclosure to get the two cables out of it while closed.

For reference, these are the places where the cables to the serial-to-USB are soldered
Image may be NSFW.
Clik here to view.
TXD pad of RK3066 (to RXD on serial-to-USB) and GROUND on the Micro USB connector

The TXD pad looks tiny but with a bit of care and a little bit of solder tin on the cable tip and the solder tip, you'll get good results.


Full RK3066 Technical Reference Manual found!

Viewing all 38 articles
Browse latest View live