Looking at this post
Graphics and Compute Development on Samsung Chromebook « Mali Developer Center Mali Developer Center
I have see that is possible to have Mali GPU hardware acceleration on Samsung ARM Chromebook with Ubuntu.
On the post you guide all the process to prepare an sd card to install ubuntu with mail support on chromebook, could you provide even the imagefile of the generated sd card?
Thanks
Hi robyinno,
I appreciate this would be ideal, but unfortunately to provide a downloadable sd card image introduces various legal complications as we would be directly bundling open source components. By following the procedure on the link this is avoided. Do let us know though if you have any issues with the procedure... it has recently been improved so any feedback would be very welcome.
Regards, Tim
Hi Tim,
thanks for the info, I have imagined this legal complications...
I will try the procedure and I keep you updated
Roberto
I tried the SD-card builder, and I was able to build Ubuntu images on SD cards that booted to 14.04 and 14.10, but either image fails to load acceleration. I always wind up with armsoc_dri.so turns up missing.
I made only minimal changes to the SD builder script so that it would boot -- on my x86_64 build host system, I only have mmcblk0 but the boot string for Chromebook had to point to a partition on mmcblk1... it boots, I copy over firmware from ChromeOS /lib/firmware, install wpasupplicant and wireless-tools by hand, then I am able to use the install-x11 script.
I can post more feedback later, I am not booted into the mali image now, just posting from ChromeOS. The mode of failure was pretty similar in 14.10, it doesn't seem like anything has changed, it just doesn't work for me. Not sure if I am missing kernel drivers or what.
Hi yebyen,
Could you give some details about what you are trying? The guide has been thoroughly tested and so I'm surprised you are experiencing any issues. You shouldn't need to make any changes to the build scripts at all to build and run the SD image successfully.
Which chromebook device are you targeting? Which OS does your host system run, and which commands are you using to run the build script to generate the SD image for the chromebook?
Thanks,
Rich
Certainly, I can post all of that information.
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 Xorg.0.log from startx just now:
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
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"
^ 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!
Hey,
Thanks for your offer to help. I think I am meant to Disable "glx" as mentioned in previous replies, a suggestion I found in other threads, and use the armsoc driver (as something decided by setting Driver "armsoc" in my /etc/X11/xorg.conf for me), then I don't get the armsoc_dri.so error, but the 2d rendering is abysmally slow (compared to fbdevhw?)
Not knowing what I'm really looking at, everything looks good until "(EE) ARMSOC(0): Failed driver-specific cursor initialization."
Ubuntu Pastebin
Disabling glx doesn't seem to do anything except making that one specific error message go away. This above Xorg.0.log is the result of that configuration.
I managed to compile the samples in Mali_OpenGL_ES_SDK_v2.4.0, and this is the (failure) result of trying to run samples/opengles_20/cube:
yebyen wrote: ...es2_info shows I'm using mesa with software rasterizer in every case.
yebyen wrote:
...es2_info shows I'm using mesa with software rasterizer in every case.
I believe you installed es2_info with sudo apt-get install which has therefore installed the mesa libs, and these are getting in the way of the mali GLES libraries on the platform. As you've found this is the same common issue as Help fix : Graphics and Compute Development on Samsung Chromebook. Could you confirm this by running ldd es2-info and pasting the result?
My advice would be to take a copy of any es2-info etc binaries that you want to run, then reflash the SD card so that it is clean with no mesa libs present. They should then give the correct output.
Chris
Yep, my story reads just like: ODROID Forum • View topic - [SOLVED] armsoc_dri.so is missing
The main issue that prevented me from getting anywhere was that the libs in /root/mali don't seem to be copied anywhere in the system library path. I actually had to put them in the search path myself.
I am running glmark2-es2 now and graphics look right with good speed. I copied my /root/mali/x11/* to /usr/local/lib, got rid of the libs mesa installed into /usr/lib/arm-linux-gnueabihf/mesa-egl, ran ldconfig, noted looking at ldd that some of the programs I was trying to run were looking for libEGL.so.1 (not libEGL.so), and libGLESv2.so.2 (not libGLESv2.so), made the needed symlinks, ldconfig again, and now the correct drivers are now loaded.
es2_info: http://paste.ubuntu.com/9076750/
I get a glmark2 score of 67
Thanks for the help! I will report back later if I was able to get a compositing window manager to work or not, my battery just ran out in the middle of testing.
While I have upgraded to 14.10 and installed e17 with EGL intact, found the compositor works great in software mode (even better in 14.10 than in 14.04)
I found chromium-browser --user-data-dir=./chrome --use-gl=egl and Smooth Scroll in chrome://flags which seems to do a lot better without the compositor than with it, but enabling it gets me a flickery mouse cursor and
I can't help but feel something is missing from this tutorial. Like I am missing the bigger picture. Maybe I need to start another thread, but, is there wayland support? e19? Aren't these from Samsung, and renound for EGL features? You'd think there would be a single build script for all of this in one fell swoop. Instead I'm contending with eina not found.
I'm trying to build it now, from nineteen.sh which I found on ubuntuhandbook.org. I think I missed something more fundamental though, forget any compositor, once I think I had configured EGL support securely, the performance of fairly simple things (I think?) like smooth opaque window transform in the default openbox performed just abysmally. They seemed to be not using whatever kind of acceleration we have enabled here.
Then glTexImage2D errors coming out of chromium, not sure if that is avoidable or not. I invite you all to try along with me and report back when your experiences have differed from mine.
Maybe I should end here and think about opening another thread, I did achieve the mali hardware acceleration as promised FWIW so
I think you've strayed further than we have in our testing we typically pull X up to the point that we can run windowed/fullscreen GLES apps, but that's about it. Maybe someone from our BSP team can comment further on what should/shouldn't work.
yebyen wrote: I think I missed something more fundamental though, forget any compositor, once I think I had configured EGL support securely, the performance of fairly simple things (I think?) like smooth opaque window transform in the default openbox performed just abysmally. They seemed to be not using whatever kind of acceleration we have enabled here.
I think I missed something more fundamental though, forget any compositor, once I think I had configured EGL support securely, the performance of fairly simple things (I think?) like smooth opaque window transform in the default openbox performed just abysmally. They seemed to be not using whatever kind of acceleration we have enabled here.
I think most window managers etc tend to use a GL backend, which Mali does not support, it supports GLES. This means they tend to revert to software rendering, which explains the poor perf of window transforms. GLES apps should still run at expected perf. There are a few GLES window managers out there to my knowledge, but you would probably need to pull them in without pulling in the mesa libs they almost always depend upon!
Hth,
Please see my response in this thread: I have few questions about guide which is Graphic and Compute development on Samsung chromebook.
Briefly, the install script doesn't aim to provide users with a fully hardware accelerated desktop environment, this is because almost no desktop environments on linux support OpenGLES as a back-end renderer. OpenBox which is installed during the setup process itself is NOT hardware accelerated and so performance when dragging windows around is poor as the compositing is done on the CPU. If you are running OpenGLES content within windows, however, this WILL be hardware accelerated to render which is the goal.
Having taken a brief look, I can see that KDE now seems to have a GLES implementation of kwin (https://wiki.archlinux.org/index.php/KDE#Configure_KWin_to_use_OpenGL_ES) which *should* give you the high performance desktop environment you seem to want if you are able to investigate this and get it working. This is something that I would be interested in looking into and potentially in future we could update the guide to install this by default. I do believe that the enlightenment desktop environment does also support hardware accelerated rendering using OpenGLES but I believe this is very much under active development. The main goal of the Chromebook developer guide is to quickly and easily create an environment on the chromebook where developers can run and test their GLES applications on linux running on Mali hardware.
As for the issues your originally experienced, the build script doesn't set up wifi in its current form and it is stated on the guide page under requirements: USB-Ethernet adapter to enable network communications. Adding wifi support from first boot is something we would like to add, but we haven't got around to it yet.
With regards to issues with X starting, I can only assume that early in the process you installed, whether as a dependency or not, mesa libs that did conflict with the mali binaries installed, I'm glad you appear to have fixed this issue though.
Hope this helps,
OK, so I am not seeing anything that I'm not expected or supposed to be seeing. Good.
I did not know about chromium-mali-opengles from the Bodhi project. Good tip also. Thanks. I still have high hopes for E19, the build script takes a decent while and is for trusty (14.04) while I already moved on with do-release-upgrade -d to utopic (14.10), so I haven't succeeded at building it yet as some minor changes as expected are needed from the trusty script to build it from git.
Of course this is totally out of scope for this thread, but I may now also try KDE from your advice. E19 had a stable release in September with "full wayland support" (which I may have misread as "much improved/fully supported OpenGLES compositor implementation".)
I had indeed installed mesa as you suspected, it was pretty easy to move the libraries out of the way once I found the specific list of libs I shouldn't have been linking with (and which versions were asked for by name in the software I was trying to use with now broken library links). Not sure how to build glmark2-es2 or es2_info/es2gears, they pulled in mesa when I installed mesa-utils-extra, the only libraries that seemed to be in conflict were the ones in /root/mali and those are "drop-in replacement" for the es2 libs of mesa.
Thanks for confirmations, I think you addressed all of the remaining oddities I was seeing, and everything is now as it should be expected to be! The tutorial should really take you all the way up to running (literally anything at all) with acceleration, because it ends at "type startx" and from what you've told me, there is nothing even remotely accelerated on or near the screen when you finally get to this point. My natural inclination once learning that plain GL is not supported was to install es2gears to see if it's really working, and that was exactly the wrong thing to do because it necessarily pulls in mesa.
Maybe that's too much garden path thinking, and you want that maybe your target audience should really be able to go on the forums and figure this out. I understand you are promoting Mali to devs, not Samsung Chromebook to end users, but nobody else can provide the drivers and even regular users need drivers sometimes bonus points to the thread you linked because you all mentioned "feh"
Works for me now. Hopefully this thread can also help someone else get here, too.