Posts Tagged ‘drivers’

Amlogic GPL Source Code Release – Kernel 3.10, U-Boot, and Drivers (Wi-Fi, NAND, TVIN, Mali GPU)

March 10th, 2014 13 comments

Last month, I noticed Amlogic provided links to the Android SDK for S802 / M802 on their open source website, but the only way to get the source was to share your SSH public with Amlogic, so that they give you access. It did not happen, but the company has released the source for Linux 3.10.10, U-boot 2011.03, Realtek and Broadcom Wi-Fi drivers, NAND drivers, “TVIN”drivers, and kernel space GPU drivers for Mali-400 / 450 GPU. There are also some customer board files for Meson 6 only (AML8726-MX / M6) but they do not seem to match the kernel…


If you want to build the kernel, including the drivers, you’ll need to download a bunch of files:


You’ll need to extract these tarballs in specific directories:

tar xvf arm-src-kernel-2014-03-06-d5d0557b2b.tar.gz
mkdir -p hardware/amlogic/
mkdir -p hardware/wifi/realtek/drivers
mkdir -p hardware/wifi/broadcom/drivers
mkdir -p hardware/arm/
cd hardware/amlogic
tar xvf aml_nand-2014-03-06-39095c4296.tar.gz
mv aml_nand-amlogic-nand nand
cd ../wifi/realtek/drivers
tar xvf ../../../../rtk8192du-2014-03-06-7f70d95d29.tar.gz
tar xvf ../../../../rtk8192eu-2014-03-06-9766866350.tar.gz
tar xvf ../../../../rtk8192cu-2014-03-06-54bde7d73d.tar.gz 
tar xvf ../../../../rtk8188eu-2014-03-06-2462231f02.tar.gz
mv rtk8188eu-8188eu 8188eu
mv rtk8192du-8192du 8192du
mv rtk8192cu-8192cu 8192cu
mv rtk8192eu-8192eu 8192eu
tar xvf ../../../../brcmap6xxx-2014-03-06-302aca1a31.tar.gz
cd ../../broadcom/drivers
mv brcmap6xxx-ap6xxx ap6xxx
cd ../../../arm
tar xvf ../../gpu-2014-03-06-0425a1f681.tar.gz
mv gpu-r3p2-01rel3 gpu
cd ..
mv aml_tvin-amlogic-3.10-bringup tvin

You can also extract the customer file into the kernel directory to add some drivers. As I said above I’m not sure the source code inside matches the Linux kernel 3.10.10, because there’s now device tree file for the boards. In arch/arm/plat-meson/Kconfig, there are (commented out) references to customer/meson/dt/Kconfig and customer/drivers/Kconfig. The device tree is not available, but the drivers is, so you could give a try in order to build the touchscreen and sensors drivers available in the customer tarball:

cd ../linux-amlogic-3.10-bringup
tar xvf ../aml_customer-2014-03-06-76ce689191.tar.gz 
mv aml_customer-master customer

Finally, the development tree is ready to build the kernel. There must surely be a script somewhere to do that… I haven’t used the file wifi-fw-2014-03-06-d3b2263640.tar.gz, as the kernel did not complain about it, and it looks like it’s just for Android Kit Kat. There are four scripts to build the kernel:, mk_m6tv,, and The first three are for meson6 (dual core processor), and the last one meson8 (quad core S802/M802).

Let’s go with M8 build:

make ARCH=arm meson8_defconfig

Please not that I had to change, as it should just make computer hand requiring a hard reset. The culprity was the line:

make uImage -j

The manpage indicates “If the -j option is given without an argument, make  will  not  limit  the number of jobs that can run simultaneously”.  It does not seem like a good idea… ,s so I changed that to

make uImage -j8

Upon successful build, the end of log you look like:

UIMAGE arch/arm/boot/uImage
Image Name: Linux-3.10.10
Created: Mon Mar 10 11:48:52 2014
Image Type: ARM Linux Kernel Image (lzo compressed)
Data Size: 7099978 Bytes = 6933.57 kB = 6.77 MB
Load Address: 00008000
Entry Point: 00008000
Image arch/arm/boot/uImage is ready
/home/jaufranc/edev/AMLogic/s802/linux-amlogic-3.10-bringup/scripts/amlogic/ /home/jaufranc/edev/AMLogic/s802/linux-amlogic-3.10-bringup/arch/arm/boot/dts/amlogic/meson8_skt.dtd
DTD_FILE: /home/jaufranc/edev/AMLogic/s802/linux-amlogic-3.10-bringup/arch/arm/boot/dts/amlogic/meson8_skt.dtd
the middle dts file: /home/jaufranc/edev/AMLogic/s802/linux-amlogic-3.10-bringup/arch/arm/boot/dts/amlogic/meson8_skt.dts
process file /home/jaufranc/edev/AMLogic/s802/linux-amlogic-3.10-bringup/arch/arm/boot/dts/amlogic/meson8_skt.dts start
processing... please wait...
process file /home/jaufranc/edev/AMLogic/s802/linux-amlogic-3.10-bringup/arch/arm/boot/dts/amlogic/meson8_skt.dts end

CC scripts/mod/devicetable-offsets.s
GEN scripts/mod/devicetable-offsets.h
HOSTCC scripts/mod/file2alias.o
HOSTLD scripts/mod/modpost
DTC arch/arm/boot/dts/amlogic/meson8_skt.dtb
rm /home/jaufranc/edev/AMLogic/s802/linux-amlogic-3.10-bringup/arch/arm/boot/dts/amlogic/meson8_skt.dts
-rw-r–r– 1 jaufranc jaufranc 11244948 Mar 10 11:48 ./m8boot.img
m8boot.img done

If you want to get U-boot code it’s not quite as messy, you jut need to download and extract two files:

tar xvf uboot-2014-03-06-323515c056.tar.gz
cd uboot-next
tar xvf ../aml_uboot_customer-2014-03-06-09887e87b4.tar.gz
mv aml_uboot_customer-next/ customer

Then just select a board in customer/board/ to build U-boot for your hardware. For example:

make m8_k03_M102_v1_config CROSS_COMPILE=arm-linux-gnueabihf-
make CROSS_COMPILE=arm-linux-gnueabihf- -j8

The build failed for me, but it might be I may need to use another compiler, e.g. arm-none-eabi-gcc.

[Update: arm-none-eabi-gcc does seem to go further, but you'll also need an arc compiler as shown in my previous Amlogic U-boot build instructions].

Thanks to M][sko for the tip.

Digg This
Reddit This
Stumble Now!
Buzz This
Vote on DZone
Share on Facebook
Bookmark this on Delicious
Kick It on
Share on LinkedIn
Bookmark this on Technorati
Post on Twitter

Intel Bay Trail Graphics Overview – FOSDEM 2014

February 17th, 2014 No comments

Bay Trail SoCs are new low power Intel ICs for tablets (Bay Trail-T, Z3000 series), mobiles (Bay Trail-M, N2800, N2900 and N3500 series), desktops (Bay Trail-D, J1800, J1900 and J2900 series) and embedded / industrial platforms (Bay Trail-I, E3800 series). Many Atom processors used to features PowerVR GPU, but it has now been replaced by Intel HD graphics in Bay Trail SoC.

Jesse Barnes, working at Intel on software and drivers for Intel graphics devices, gives a presentation about Bay Trail SoCs with a focus on graphics. After an overview, and some ARM bashing regarding performance (Nvidia Tegra 4 and Qualcomm Snapdragon 800), and even power consumption (Tegra 4 only), he describe further details about Intel HD graphics found in the new Intel processors. Everything is basically in mainline, and you’ll need Linux 3.10 or greater, Mesa 9.2 or greater, and libva 1.2.1 or greater for proper support. Some initial GPU benchmarks showed somewhat disappointing results, but in this talk, Jesse explains some parts of the drivers still need performance improvements, as they only run at half the expected speed. VP8 support (hardware decode?) is work in progress in VP8.

He also mentioned available hardware platform with Windows 8.x tablets already available, and Android tablets becoming available later this year, except in China where you can already buy Bay Trail Android tablets…

Presentation slides are not available.

Digg This
Reddit This
Stumble Now!
Buzz This
Vote on DZone
Share on Facebook
Bookmark this on Delicious
Kick It on
Share on LinkedIn
Bookmark this on Technorati
Post on Twitter

Cute Embedded Nonsense Hacks, Nouveau Driver for Tegra K1, and Android Defaults to ART

February 1st, 2014 4 comments

There’s been some news at the end of this week that may not warrant a full article, but are still fun and/or interesting nonetheless: comments by the lead developer of Fedora ARM  led to “Cute Embedded Nonsense” meme on Google+, preliminary commit for open source drivers for Tegra K1′s GPU, and Android Open Source Project defaults to ART instead of Dalvik.

Cute_embedded_Nonsense_HacksIf you have a Google+ account, and circled a few people involved in ARM Linux, you must have seen a few postings about “Cute Embedded Nonsense Hacks” in your feed. It all started when Jon Masters posted about Red Hat’s ARM SBSA platform requirements, and in particular one comment that reads:

I am all for people installing their own kernels if they want to. I support aggressively defined standard platforms (not cute embedded nonsense hacks) but not locked platforms. You can keep both parts when it breaks, of course.

This generated quite a buzz in Google+, with ARM Linux developers getting upset, and Jon Masters later apologized, and promised $100 to the charity of choice to the best “graphics” representation of “Cute Embedded Nonsense Hacks”. You can even buy a T-Shirt.

Separately, if you’ve been frustrated by the lack of open source drivers for GPUs used in ARM SoC, there’s some hope, as initial support for Tegra K1′s GPU, codenamed GK20A, has been added to the Nouveau drivers, which are open source drivers for Nvidia GPUs. Here’s an excerpt of the commit email:

GK20A is the Kepler-based GPU used in the upcoming Tegra K1 chips. The following patches perform architectural changes to Nouveau that are necessary to support non-PCI GPUs and add initial support for GK20A. Although the support is still very basic and more user-space changes will be needed to make the full graphics stack run on top of it, we were able to successfully open channels and run simple pushbuffers with libdrm (more testing including rendering is in progress as we get more familiar with Nouveau’s user-space interface).

This work should be considered as a RFC and a proof-of-concept for driving future Tegra GPUs with Nouveau. Some design choices need to be discussed and quite a few inelegant shortcuts were purposely taken to minimize the size of this first set. Or said otherwise, apart from the changes that add support for non-PCI GPUs, remarkably little code needs to be added to get GK20A to a point where it is actually running. This is very encouraging, and it will be interesting to keep improving this support and see where this gets us.

Android_ART_DalvikYou can get the full details @

With the release of Android 4.4 (Kitkat), Google added ART (Android Runtime) as an alternative Android runtime that can run instead of Dalvik virtual machine. Dalvik is based on JIT (just in time) compilation, which means the code is translated into machine code each time it runs. ART is based on AOT (ahead of time) compilation, and translates Java bytecode into an architecture dependent binary during installation so that apps will start and run much faster when in actual use. One drawback is that ART takes a bit more storage compared to Dalvik, as it needs to store the machine-code binaries.

The Android 4.4 Kitkat firmware you have in your device still defaults to Dalvik, as ART breaks some of the apps. But good progress must have been made, as a recent commit into AOSP now makes ART the default runtime. So I’d assume Android 4.4.3 will come with ART by default. Via Liliputing.

Digg This
Reddit This
Stumble Now!
Buzz This
Vote on DZone
Share on Facebook
Bookmark this on Delicious
Kick It on
Share on LinkedIn
Bookmark this on Technorati
Post on Twitter

GCW Zero Handheld Console Runs 3D Games via Open Source Vivante GPU Drivers (Etnaviv)

December 16th, 2013 1 comment

GCW Zero is an open source handheld gaming console featuring Ingenic JZ4770 MIPS processor with Vivante GC860 GPU, 512MB RAM, 16GB internal storage, and a 3.5″ LCD with 320×240 pixels. The device runs Linux (OpenDingux) , and retro games and emulators. GCW Zero had a successful kickstarter campaign, and is now available in a few shops such as ThinkGeek (US), DragonBox (EU) for $150 / 125 Euros.

GCW_ZeroToday, I’m writing about this console, not because of amazing specs, nor price, but because it could be the first  device with an embedded SoC that retails with an open source GPU driver. In September of this year, GCW Zero received a firmware update with Etnaviv GPU driver for Vivante GC860 adding support for 3D games via OpenGL ES support. The video below shows Quake 3 Arena running on the game console with the Etnaviv drivers.

Lots of OpenGL ES1 and 2 features are supported as you can see from the release notes for the latest firmware (October), but some may still needs to be implemented including loops in shaders, GLSL (OpenGL Shading Language) “texture” bias parameter and “textureLod”, and a few more more. Beside Quake 3D arena, D2X (Descent 2 rebirth), Dark Places, and Hurrican are some of the few 3D games that have successfully been tested on the platform.

That means any platform based on Vivante GC600, GC800, GC860, GC880, and GC1000 should be able to support OpenGL ES via the open source Etnaviv drivers in Linux or Android. Vivante GC2000, as used in Freescale i.MX6 Quad, is not yet supported mainly because multiple pixel pipes support is missing, although progress has been made.

Etnaviv appears to be mainly a one person effort by Wladimir J. van der Laan, and despite this, progress has been very fast for the last year or so. The hard parts have been done, i.e. reverse-engineering and 3D drivers, but there’s still more work to be done, such as integrating the Mesa stuff into DRI/DRM, upstreaming, and X11 2D driver.

If you are interested in contributing to the project, trying it out, or simply watch the progress of the project, you can do so on Wladimir’s blog, or on #etnaviv IRC channel on freenode. For source code and documentation, visit the project’s github repo.

Digg This
Reddit This
Stumble Now!
Buzz This
Vote on DZone
Share on Facebook
Bookmark this on Delicious
Kick It on
Share on LinkedIn
Bookmark this on Technorati
Post on Twitter

Linux 3.9 Release

April 29th, 2013 No comments

Linus Torvalds has announced the release of Linux Kernel 3.9:

So the last week was much quieter than the preceding ones, which makes me suspect that one reason -rc7 was bigger than I liked was that people were gaming the system and had timed some of their pull requests for just before the release, explaining why -rc7 was big enough that I didn’t  actually want to do a final release last week. Please don’t do that.

Anyway. Whatever the reason, this week has been very quiet, which makes me much more comfortable doing the final 3.9 release, so I guess the last -rc8 ended up working. Because not only aren’t there very many commits here, even the ones that made it really are tiny and not pretty obscure and not very interesting.

Also, this obviously means that the merge window is open. I won’t be merging anything today, but if you start sending me your pull requests (Konrad already sent in his Xen pull request for the 3.10 merge window a week ago), tomorrow the flood gates start opening..

Linux 3.8 brought file systems enhancement for Btrfs, XFS and ext-4, introduce F2FS file system, memory management improvement, and the removal for i386 support.

Linux 3.9 brings the following key changes (Sources H-Online and Phoronix):

  • File-system improvements:
    • Btrfs has experimental RAID5/6 support and fsync performance improvements.
    • EXT-4 bug fixes for corruption issue, and JBD2 journaling layer issue which affected performance.
    • Various improvements for F2FS file-system.
  • Added ability to use SSDs as hard-disk cache.
  • Update the latest LZO compression implementation within the kernel. Decompression and compression performance has been massively improved and x86 and ARM targets.
  • Improved power management, including “lightweight suspend” (aka “suspend freeze”) mode.
  • Improved ARM SoC support
    • Added Nvidia Tegra 4 support including support for Dalmore and Pluto development boards.
    • Added Nvidia Tegra 3 Beaver Board support
    • Kernel-based Virtual Machine (KVM) support for ARMv7 (Cortex A15 required)
  • Mainlining of Google’s Goldfish virtual CPU.
  • Initial ARC Linux support. See commit.
  • Added support for Imagination Meta ATP (Meta 1) and HTP (Meta 2)
  • Graphics drivers updates – Nouveau, the open-source reverse-engineered NVIDIA Linux graphics driver, is faster for some Linux OpenGL games. There’s also some Intel OpenGL performance changes.
  • Support for Intel 7000 Wi-Fi components supporting 802.11ac.
  • CONFIG_EXPERIMENTAL kernel configuration option has been removed

More details about Linux 3.9 will be available on (which is currently down).

Digg This
Reddit This
Stumble Now!
Buzz This
Vote on DZone
Share on Facebook
Bookmark this on Delicious
Kick It on
Share on LinkedIn
Bookmark this on Technorati
Post on Twitter

Ubuntu Linaro 12.11 with 2D/3D Mali-400 GPU Acceleration on ODROID-X Development Board

February 19th, 2013 36 comments

A few days ago, Hardkernel released the first version of Ubuntu 12.11 (Linaro) with Mali-400 GPU support for their ODROID boards (ODROID-X/X2, ODROID-U/U2). This is still WIP (Work in Progress), but this is one of the few boards together with Pandaboard, Origen and Snowball that can support 2D/3D GPU acceleration in Ubuntu Quantal. Since I have an ODROID-X development board, I decided to give it a try. There are different ways to install it. I chose the way that is most convenient for me (LCD display instead of HDMI), and likely to yield more performance (eMMC instead of SD Card). The current installation instructions to eMMC are extremely cumbersome and you have to go through 5 main steps:

  1. Install Android (yes, seriously) in the eMMC
  2. Install Ubuntu in the SD Card
  3. Install Ubuntu to the eMMC
  4. Upgrade Ubuntu to the latest version
  5. Install the Mali drivers

In this post I’m going to go through all those steps, and do some testing for eMMC and 2D/3D performance. If you just want to boot Ubuntu from SD, simply skip steps 1 and 3. For eMMC installation, I followed the “eMMC Ubuntu” guide on odroid forums, as well as the instructions on the release post to install Mali drivers, and enable 2D/3D acceleration in Ubuntu. Similar instructions are also available for ODROID-X2 and ODROID-U2.

You’ll need an 8GB SD Card or greater to complete all the steps.

Installing Android to ODROID-X

  • Insert the SD card in a Linux PC, and find your SD card device:
sudo blkid
/dev/sda1: UUID="9c042788-fa75-4fc4-9b12-598c809410e8" TYPE="ext4"
/dev/sda5: UUID="fa4d6d7d-311a-4570-a498-96394b828e01" TYPE="swap"
/dev/sdb1: LABEL="SEAGATE EXTENSION" UUID="C0588ADB588AD018" TYPE="ntfs"
/dev/sdc: LABEL="Ubuntu_ODROID-X" UUID="f04f2d56-86a6-44ad-9b63-854714ab78fd" TYPE="ext4"
  • Download & extract the Android Installer, and write it to your SD card with dd or script:
sudo if=emmc_installer_for_odroidx.img of=/dev/sdc

If you use Windows, do it with Win32DiskImager. Back in the times when I still used Windows and Win32DiskImager, I never had problems myself, but some people apparently have, and Hardkernel released an improved version of Win32DiskImager to verify the copy.

Then insert the SD card in your ODroid-X board, connect a Jumper on SD/MMC connector (JP2) to boot from SD card, and install the latest version of Android. During installation I had no display on the 10″ LCD display, and the board simply powered itself off after a while. Not sure this is normal, but after removing the Jumper, I could boot to Android (3-Jan-2013 build) from the eMMC.

Installing Ubuntu 12.11 for ODROID-X to the SD card

Now take the SD card back to your Linux computer to copy the Ubuntu image:

  • For LCD display:
  • For HDMI Display:

I’ll carry on with the LCD image since this is what I use, but the step for HDMI are the same, just replace the filename:

7z x odroidx_20130128-linaro-ubuntu-desktop_SD_with_LCD.img.xz
sudo if=odroidx_20130128-linaro-ubuntu-desktop_SD_with_LCD.img of=/dev/sdc

Inset the SD card in ODroid-X board, insert the Jumper in JP2 to boot from SD card to verify Ubuntu 12.10 boots correctly.

Install Ubuntu to ODROID-X eMMC Module

Once you’ve verified Ubuntu boots correctly from the SD Card, put the SD card back in your PC and copy odroidx_20130128-linaro-ubuntu-desktop_SD_with_LCD.img.xz to the rootfs. In my PC running Ubuntu 12.04, it will automount it to /media/rootfs:

sudo cp odroidx_20130128-linaro-ubuntu-desktop_SD_with_LCD.img.xz /media/rootfs
umount /media/rootfs

Once umount is successfully (which means the data is fully written to the SD card), you can insert it back into your ODroid-X board to install Ubuntu 12.10 to your eMMC. First locate your eMMC device with:

ls /dev/mmcblk*

The eMMC is the device with with boot0/boot1, as well as p1/p2/p3/p4. In my case, it’s mmcblk0. Once you know this, copy Ubuntu to the eMMC by using the following command in a terminal:

sudo xzcat /odroidx_20130128-linaro-ubuntu-desktop_SD_with_LCD.img.xz | sudo dd of=/dev/mmcblk0 bs=4M

Once sync is complete, power off the board, remove the Jumper on JP2, and start Ubuntu.

Ubuntu Quantal in ODROID-X Board

Ubuntu Quantal in ODROID-X Board

Upgrading Ubuntu (15 Feb)

Before we can use Mali-400MP4 GPU in Ubuntu, you must install an update for Ubuntu (Feb 15, 2013):

tar xvfz linux-3.0.63-odroidx_20130215.tar.gz
cd linux-3.0.63-odroidx_20130215
sudo ./
sudo reboot

If you are using the Wi-Fi module from Hardkernel (and probably others), run those 2 commands:

sudo depmod -a
sudo reboot

Installing Mali Drivers for ODROID-X Board

Mali-400MP4 drivers are not included in the image, most probably for legal reasons, and you have to accept an End-User-License-Agreement (EULA) during installation (dkpg). Let’s do this:

tar xvfz mali_packages.tar.gz
cd mali_packages
sudo dpkg -i mali400_2.1-13_armhf.deb
sudo dpkg -i mali400-dev_2.1-13_armhf.deb
sudo dpkg -i xf86-video-mali_1.0.1-7_armhf.deb
sudo rm -fr /usr/lib/arm-linux-gnueabihf/mesa-egl

If you are outputting to an HDMI monitor, the installation should be complete at this stage. In my case I could only the 4 tux and nothing else showed up on the display. I could however access the command line via the serial console. After further reading, I found out I had to modify /usr/share/X11/xorg.conf.d/99-hkl_mali.conf to make it work with the LCD display as follows:

Option   "fbdev"          "/dev/fb0"
DefaultDepth   24

Ubuntu Linaro 12.11 Performance in ODROID-X

The first thing I’ve noticed is that Ubuntu feel snappy with this hardware, at least snappier than in my Atom netbook running Ubuntu 12.04, and it’s the first time I could see myself using this platform as a desktop replacement. Booting from power off takes 15 to 20 seconds. There are still some issues though. Once of them is that software-center is not working when run from the eMMC (SD card is OK). Even though this post is mainly about GPU support, I’ve compared startup times from eMMC and SD card with Libreoffice Writer, Software Center, and Firefox

Libreoffice Writer was not pre-installed, so I installed it first:

sudo apt-get install libreoffice-writer
Firefox Software Center Libreoffice Writer
SD Card 5s 18s 11s
eMMC 3s Does not start 5s

Each program was started after a reboot. We can notice there’s a significant advantage of using eMMC instead of SD card when it comes to startup time.

I’ve also done several 2D/3D tests.

I started with es2gears, which comes in the provided Ubuntu image:

EGL_VERSION = 1.4 Linux-r3p2-01rel0
vertex shader info:
fragment shader info:
483 frames in 5.0 seconds = 96.561 FPS
427 frames in 5.0 seconds = 85.230 FPS
395 frames in 5.0 seconds = 78.827 FPS
394 frames in 5.0 seconds = 78.580 FPS
379 frames in 5.0 seconds = 75.664 FPS
373 frames in 5.0 seconds = 74.570 FPS
363 frames in 5.0 seconds = 72.585 FPS
352 frames in 5.0 seconds = 70.245 FPS
332 frames in 5.0 seconds = 66.387 FPS
317 frames in 5.0 seconds = 63.273 FPS
297 frames in 5.0 seconds = 59.341 FPS
298 frames in 5.0 seconds = 59.469 FPS
279 frames in 5.0 seconds = 55.722 FPS
280 frames in 5.0 seconds = 55.855 FPS
263 frames in 5.0 seconds = 52.505 FPS
260 frames in 5.0 seconds = 51.875 FPS
251 frames in 5.0 seconds = 50.090 FPS
237 frames in 5.0 seconds = 47.230 FPS

It appears to work, but the window background is transparent, and although the frame rate starts at 96.651, it just decreases which each iteration… Not sure what that means…

I’ve also installed glmark2-es2

sudo apt-get install glmark2-es2

glmark2-es2 2D/3D GPU Benchmark in ODROID-X Development Board

glmark2-es2 2D/3D GPU Benchmark in ODROID-X Development Board

run it, and got a score of 54:

linaro@linaro-ubuntu-desktop:~$ glmark2-es2
glmark2 2012.08
OpenGL Information
GL_RENDERER:   Mali-400 MP
GL_VERSION:    OpenGL ES 2.0
[build] use-vbo=false: FPS: 52 FrameTime: 19.231 ms
[build] use-vbo=true: FPS: 54 FrameTime: 18.519 ms
[texture] texture-filter=nearest: FPS: 57 FrameTime: 17.544 ms
[texture] texture-filter=linear: FPS: 57 FrameTime: 17.544 ms
[texture] texture-filter=mipmap: FPS: 57 FrameTime: 17.544 ms
[shading] shading=gouraud: FPS: 57 FrameTime: 17.544 ms
[shading] shading=blinn-phong-inf: FPS: 57 FrameTime: 17.544 ms
[shading] shading=phong: FPS: 54 FrameTime: 18.519 ms
[bump] bump-render=high-poly: FPS: 46 FrameTime: 21.739 ms
[bump] bump-render=normals: FPS: 58 FrameTime: 17.241 ms
[bump] bump-render=height: FPS: 57 FrameTime: 17.544 ms
[effect2d] kernel=0,1,0;1,-4,1;0,1,0;: FPS: 56 FrameTime: 17.857 ms
[effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: 56 FrameTime: 17.857 ms
[pulsar] light=false:quads=5:texture=false: FPS: 58 FrameTime: 17.241 ms
[desktop] blur-radius=5:effect=blur:passes=1:separable=true:windows=4: FPS: 40 FrameTime: 25.000 ms
[desktop] effect=shadow:windows=4: FPS: 53 FrameTime: 18.868 ms
Error: Requested MapBuffer VBO update method but GL_OES_mapbuffer is not supported!
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=map: Unsupported
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=subdata: FPS: 37 FrameTime: 27.027 ms
Error: Requested MapBuffer VBO update method but GL_OES_mapbuffer is not supported!
[buffer] columns=200:interleave=true:update-dispersion=0.9:update-fraction=0.5:update-method=map: Unsupported
[ideas] speed=duration: FPS: 53 FrameTime: 18.868 ms
[jellyfish] <default>: FPS: 56 FrameTime: 17.857 ms
Error: SceneTerrain requires Vertex Texture Fetch support, but GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS is 0
[terrain] <default>: Unsupported
[conditionals] fragment-steps=0:vertex-steps=0: FPS: 57 FrameTime: 17.544 ms
[conditionals] fragment-steps=5:vertex-steps=0: FPS: 57 FrameTime: 17.544 ms
[conditionals] fragment-steps=0:vertex-steps=5: FPS: 57 FrameTime: 17.544 ms
[function] fragment-complexity=low:fragment-steps=5: FPS: 57 FrameTime: 17.544 ms
[function] fragment-complexity=medium:fragment-steps=5: FPS: 57 FrameTime: 17.544 ms
[loop] fragment-loop=false:fragment-steps=5:vertex-steps=5: FPS: 57 FrameTime: 17.544 ms
[loop] fragment-steps=5:fragment-uniform=false:vertex-steps=5: FPS: 58 FrameTime: 17.241 ms
[loop] fragment-steps=5:fragment-uniform=true:vertex-steps=5: FPS: 57 FrameTime: 17.544 ms
glmark2 Score: 54

Some test failed. I’m not sure if it’s because those are not implemented yet, or simply not supported by Mali-400. One interesting point is that ODROID-U2 users reports that Xubuntu is twice as fast as Ubuntu in glmark2-es2, and the culprits appear to be Unity and Compiz.

I’ve done another test to check whether WebGL would work, and I’ve got between 0 to 1 fps on both Firefox and Chromium with WebGL Aquarium. A final comment, since many people still seem to be confused with GPU and video decoding. The Mali-400 does not handle video decoding, this is done normally done by the Video Processing Unit (VPU), and AFAIK this is not currently supported in Linux on ODROID boards.

Digg This
Reddit This
Stumble Now!
Buzz This
Vote on DZone
Share on Facebook
Bookmark this on Delicious
Kick It on
Share on LinkedIn
Bookmark this on Technorati
Post on Twitter

A Selection of FOSDEM 2013 Events

February 1st, 2013 No comments

FOSDEM is a 2-day (or 3 if you include Friday beer event) event where over 5,000 members of open source communities meet, share ideas and collaborate. It’s free to attend, and there’s no registration, so you just show up to attend. FOSDEM 2013 takes place on Feb 2-3 (yep, this week-end) in Brussels

There are 7 main tracks where sessions are organized:

  • fosdem logoOperating systems
  • Open source challenges
  • Security Janson
  • Beyond operating systems
  • Web development
  • Miscellaneous
  • Robotics

There are also keynotes and devroom for a total of 488 sessions. Developers rooms that may particularly be of interest to readers of this blog are:

All in all that’s a lot of sessions, and even though I won’t attend, I’m going to select a few from the main tracks:

This talk introduces the Fedora ARM Project and in particular the work we are doing to bring Fedora to emerging 64-bit ARM server systems.

Where are we today, one year after the unveiling of the Lima driver. This talk will cover the Lima driver (ARM Mali 200/400), but also other open source GPU driver projects such as the freedreno driver (Qualcomm Adreno), open source driver for Nvidia Tegra, etnaviv project (Vivante GC) and cover the status for Broadcoms Videocore and Imaginations PowerVR GPUs.

Based on the speaker’s experience of getting the support for the new Armada 370 and Armada XP ARM processors from Marvell into the mainline Linux kernel, this talk will detail the most important steps involved in this effort, and through this, give an overview of those changes and summarize the new rules for ARM Linux support.

  • Sunday 11:00 – 11:50 – Firefox OS by Jonas Sicking

Firefox OS is the next product being developed by Mozilla. It’s an open source OS based on the web and following the principals which have made the web a success. A phone running recent builds of Firefox OS (it’s not a finished product yet) will be demoed, and  the technologies and ideas behind Firefox OS will be discussed.

The systemd project is now two years old (almost three). It found adoption as the core of many big community and commercial Linux distributions. It’s time to look back what we achieved, what we didn’t achieve, how we dealt with the various controversies, and what’s to come next.

How Aldebaran Robotics is using open source on their NAO robot.

This talk will provide an overview of the Robot Operating System (ROS), an open software integration framework for robots.

This talk describes how the automotive industry has moved to embedded Linux and Open Source to develop the next generation of In-Vehicle Infotainment (IVI) and how it has met the challenges along the way.

What, why, when, where and how SecureBoot changes the way we build F/LOSS


Digg This
Reddit This
Stumble Now!
Buzz This
Vote on DZone
Share on Facebook
Bookmark this on Delicious
Kick It on
Share on LinkedIn
Bookmark this on Technorati
Post on Twitter