Mali hardware acceleration on ubuntu on Chromebook

The diffs I needed to get chromebook-setup.sh to be writing and booting the correct partition (card identified as mmcblk0 on my build laptop is mmcblk1 on my chromebook, so I changed the boot_params to reflect mmcblk1p2 would be the root device when booting from SD) are on this gist: Chromebook-setup Diff -- those changes also addressed that a USB drive that might have been "sdc" with partitions "sdc1, sdc2", as an SD card, would be mmcblk0p1 and mmcblk0p2 -- very minor changes I was surprised you didn't run into in your testing, too.  This is enough to make the created image write out to a card and bootable.  That all worked OK for me with only these minor tweaks to the script.

The chromebook I'm targeting is an XE303C12-A01US Samsung Chromebook original "Series 3", aka "Exynos 5250 - Snow" with the T604 Mali hardware.

The guide I'm using is from:

Graphics and Compute Development on Samsung Chromebook - Mali Developer Center Mali Developer Center

I invoke the build script as:

./chromebook-setup.sh --variant=XE303C12 --storage=/dev/mmcblk0 do_everything

I have in the current dir when I do the build, downloaded r4p1 GLES drivers archives according to the link on the page for mali-t60x:

mali-t60x_r4p1-00rel0_linux_1+fbdev.tar.gz

mali-t60x_r4p1-00rel0_linux_1+x11.tar.gz

The build also fetches:

ubuntu-core-14.04-core-armhf.tar.gz

and

gcc-linaro-arm-linux-gnueabihf-4.8-2014.04_linux

I also get some git clones which I suppose are used for the build, in:

kernel/

vboot/

That all seems fine and when I have booted with the SD card in place and a Ctrl+U for "USB/SD external booting", I get dumped to a command line running from a root on the SD card, on a system with no wireless firmware (I needed to mount ChromeOS and copy over the firmware from /lib/firmware on mmcblk0p3) and no wireless support (so, I chroot in from the running ChromeOS and set up some DNS servers in /etc/resolv.conf, to do apt-get install wpasupplicant wireless-tools).  Finally I can boot again with Ctrl+U and bring up the wireless interface independently, follow the steps to run as root the script ./install-x11.sh, it succeeds, I then do startx, and I note that the terminal who comes up moves very slowly if I try dragging it around the screen by picking up the title bar.  This is my first hint that something is wrong.

At this point I noted the error messages issue mentioned about armsoc_dri.so in Xorg.0.log and I assume this means something is not set up correctly.  Now I am out of my element unfortunately.  Maybe I just need to configure Xorg to use a specific driver.  A quick search: https://www.google.com/search?q=armsoc_dri.so+does+not+exist show that I may have gone somewhere I shouldn't be, although I think I haven't strayed from the garden path in the tutorial.  I don't have the chromebook handy right now, only my build laptop which produced these images (Ubuntu 14.10 amd64), or I would post the exact error reported, but this should get pretty close.

Can I demonstrate somehow (lsmod? lspci? dmesg) that the kernel driver is really available for the Xorg driver's access?  Should there be a node in /dev somewhere that I can probe somehow if this really worked?

I will post again later tonight with more details when I am in front of the Chromebook.  Should I have a kernel of the same version as the Chromebook kernel (3.8.11?)  I think I did get that, again not sure; I know I saw the build script compiling a kernel, but I'm not sure it downloaded the kernel drivers.  They do seem to be already merged into the kernel git tree.  Without the Chromebook in front of me right now, unfortunately this is the most detail I can provide; if you need anything else it will have to wait for later.  I seem to have two patches applied over rev=1a6b9bf866357caafe68faabad56f60540841dc3

I appreciate your help!

Kingdon

The diffs I needed to get chromebook-setup.sh to be writing and booting the correct partition (card identified as mmcblk0 on my build laptop is mmcblk1 on my chromebook, so I changed the boot_params to reflect mmcblk1p2 would be the root device when booting from SD) are on this gist: Chromebook-setup Diff -- those changes also addressed that a USB drive that might have been "sdc" with partitions "sdc1, sdc2", as an SD card, would be mmcblk0p1 and mmcblk0p2 -- very minor changes I was surprised you didn't run into in your testing, too.  This is enough to make the created image write out to a card and bootable.  That all worked OK for me with only these minor tweaks to the script.

The chromebook I'm targeting is an XE303C12-A01US Samsung Chromebook original "Series 3", aka "Exynos 5250 - Snow" with the T604 Mali hardware.

The guide I'm using is from:

Graphics and Compute Development on Samsung Chromebook - Mali Developer Center Mali Developer Center

I invoke the build script as:

./chromebook-setup.sh --variant=XE303C12 --storage=/dev/mmcblk0 do_everything

I have in the current dir when I do the build, downloaded r4p1 GLES drivers archives according to the link on the page for mali-t60x:

mali-t60x_r4p1-00rel0_linux_1+fbdev.tar.gz

mali-t60x_r4p1-00rel0_linux_1+x11.tar.gz

The build also fetches:

ubuntu-core-14.04-core-armhf.tar.gz

and

gcc-linaro-arm-linux-gnueabihf-4.8-2014.04_linux

I also get some git clones which I suppose are used for the build, in:

kernel/

vboot/

That all seems fine and when I have booted with the SD card in place and a Ctrl+U for "USB/SD external booting", I get dumped to a command line running from a root on the SD card, on a system with no wireless firmware (I needed to mount ChromeOS and copy over the firmware from /lib/firmware on mmcblk0p3) and no wireless support (so, I chroot in from the running ChromeOS and set up some DNS servers in /etc/resolv.conf, to do apt-get install wpasupplicant wireless-tools).  Finally I can boot again with Ctrl+U and bring up the wireless interface independently, follow the steps to run as root the script ./install-x11.sh, it succeeds, I then do startx, and I note that the terminal who comes up moves very slowly if I try dragging it around the screen by picking up the title bar.  This is my first hint that something is wrong.

At this point I noted the error messages issue mentioned about armsoc_dri.so in Xorg.0.log and I assume this means something is not set up correctly.  Now I am out of my element unfortunately.  Maybe I just need to configure Xorg to use a specific driver.  A quick search: https://www.google.com/search?q=armsoc_dri.so+does+not+exist show that I may have gone somewhere I shouldn't be, although I think I haven't strayed from the garden path in the tutorial.  I don't have the chromebook handy right now, only my build laptop which produced these images (Ubuntu 14.10 amd64), or I would post the exact error reported, but this should get pretty close.

Can I demonstrate somehow (lsmod? lspci? dmesg) that the kernel driver is really available for the Xorg driver's access?  Should there be a node in /dev somewhere that I can probe somehow if this really worked?

I will post again later tonight with more details when I am in front of the Chromebook.  Should I have a kernel of the same version as the Chromebook kernel (3.8.11?)  I think I did get that, again not sure; I know I saw the build script compiling a kernel, but I'm not sure it downloaded the kernel drivers.  They do seem to be already merged into the kernel git tree.  Without the Chromebook in front of me right now, unfortunately this is the most detail I can provide; if you need anything else it will have to wait for later.  I seem to have two patches applied over rev=1a6b9bf866357caafe68faabad56f60540841dc3

I appreciate your help!

Kingdon

http://pastebin.com/raw.php?i=QReXsgXC

The whole log is included above, but...

parts of that which caught my attention:

[ 18.346] (II) LoadModule: "armsoc"

[ 18.346] (II) Loading /usr/lib/xorg/modules/drivers/armsoc_drv.so

[ 18.352] (II) Module armsoc: vendor="X.Org Foundation"

[ 18.352] compiled for 1.15.1, module version = 0.6.0

[ 18.352] Module class: X.Org Video Driver

[ 18.352] ABI class: X.Org Video Driver, version 15.0

[ 18.352] (II) ARMSOC: Driver for ARM compatible chipsets: Mali-4XX, Mali-T6XX

[ 18.352] (--) using VT number 7

...

[ 18.357] (WW) Falling back to old probe method for armsoc

[ 18.357] (II) No BusID or DriverName specified - opening /dev/dri/card0

[ 18.357] (II) Got BusID platform:exynos-drm:00

[ 18.478] (II) Opened DRM

[ 18.479] (II) DeviceName is [/dev/dri/card0]

[ 18.479] (II) bus_id is [platform:exynos-drm:00]

[ 18.479] (II) DriverName is [exynos]

[ 18.479] (II) version is [1.0.0]

...

[ 18.710] (II) ARMSOC(0): [DRI2] Setup complete

[ 18.710] (II) ARMSOC(0): [DRI2] DRI driver: armsoc

[ 18.710] (==) ARMSOC(0): Backing store enabled

[ 18.710] (==) ARMSOC(0): Silken mouse enabled

[ 18.713] (II) ARMSOC(0): HW cursor init()

[ 18.714] (EE) ARMSOC(0): ERROR: Failed driver-specific cursor initialization

...

[ 18.735] (EE) AIGLX error: dlopen of /usr/lib/arm-linux-gnueabihf/dri/armsoc_dri.so failed (/usr/lib/arm-linux-gnueabihf/dri/armsoc_dri.so: cannot open shared object file: No such file or directory)

[ 18.735] (EE) AIGLX: reverting to software rendering

[ 18.852] (II) AIGLX: Loaded and initialized swrast

Are these indications that I've loaded the wrong driver, or normal messages?

What can I do, if you do happen to recognize the problem

Thanks,

Kingdon

I found this thread: Bug #1085596 “Graphics acceleration not working in ubuntu deskto...” : Bugs : Cross distro support for Samsung Chromeboo…

Seems to be tackling a similar issue.  I followed and read down to the point where they suggested that GLX was not supported and should be disabled, like:

Section "Module"

Disable "glx"

EndSection

I generated an xorg.conf with Xorg -configure and copied it over the minimal xorg.conf in /etc/Xorg to put this section in.

This takes care of my "(EE) AIGLX error: dlopen of /usr/lib/arm-linux-gnueabihf/dri/armsoc_dri.so failed (/usr/lib/arm-linux-gnueabihf/dri/armsoc_dri.so: cannot open shared object file: No such file or directory)", but does not seem to have fixed anything else.

Then I tried for kicks, change the driver from "armsoc" to "exynos" -- bazinga!

Suddenly es2gears and friends can spring to life with decent framerates.  Turning back on Load "glx" in the xorg.conf gives even better performance for small windows at least with glxgears, I render over 130fps in the default size glxgears.  Making this change, to read the Xorg.0.log seems to indicate that I've reverted to software rendering with (EE) AIGLX: reverting to software rendering, and es2gears gives this output before it starts rendering to the small window at 70fps:

libEGL warning: DRI2: failed to authenticate

EGL_VERSION = 1.4 (DRI2)

vertex shader info:

fragment shader info:

info:

... maybe this has something to do with the fact that I'm running with root, but I've disabled glx for now.  Actually, now that I check, I get that error from es2_info as well as es2_gears, regardless of whether glx is enabled or disabled.  And es2_info shows I'm using mesa with software rasterizer in every case.  glmark2-es2 won't render any frames.

So, I think I'm closer, but still doing something wrong!  Any ideas?

In: Help fix : Graphics and Compute Development on Samsung Chromebook

it looks like a common problem is just what I've now found, falling back to mesa.

It looks like I get the same results (better, no error about missing driver "exynos") if I just remove the default xorg.conf:

Section "Device"

Identifier "mali"

Driver "armsoc"

EndSection

^ This may have been set by the install-x11.sh script.  I did not put it there, but it seems to load the wrong driver and prevent a fallback.

I think I fooled myself, nothing is fixed, hope this deluge of information is helpful.  Here is another more recent link:

Bug #1100067 “Samsung Chromebook uses software rendering when ha...” : Bugs : “nux” package : Ubuntu

I don't reach this stage:

chromebook:~$ es2_info

EGL_VERSION = 1.4 Midgard-"r1p2-00bet0"

EGL_VENDOR = ARM

I'm not sure where to start, if the advice is to recompile the es2 utils with the DDK headers.  Is there a tutorial for that?  I'm still not sure I've even loaded the drivers correctly.  I think my system is running in "fb" mode, I can post another Xorg.0.log or wait for your advice.

Thanks!

Kingdon