18 Oct 2017

email PSA

(the following is meant to be humourous, with just a teensy bit of seriousness. anyone who is incapable of reading/understanding humour on the internet is kindly asked to please go back to facebook)

To all the Toms, Traceys, Tims, Todds, Tamaras, Tonys, Tinas, Troys, Taylors, (and others whose first name starts with "T").... of the world whose last name is "Woerner": please stop telling everyone your email address is twoerner at gmail dot com! It's not. That's my email address. I'm tired of receiving your pay stubs, flight itineraries, baby pictures, academic reports, "lady" pics, resumes, etc.

Recently someone asked me for my email address. What's funny is how confused and condescending she was when it didn't include numbers.

    "Are you sure?"
    Yes.
    "It's not 'twoerner' and then a year or some other numbers at gmail dot com?"
    No. Just 'twoerner' with no numbers at gmail dot com.
    "Uh huh".

I guess I come from the only generation whose gmail addresses don't need numbers. Apparently in my lifetime that's already becoming dated. Centuries from now historians will be able to tell my age and roughly what years I was alive based on the fact my email address is composed of: my first initial, plus last name, with no numbers, at gmail dot com. Thousands of years from now nobody will still be able to use twoerner @ gmail because some guy who died decades ago chose it.

That's me!
(You're welcome)
;-)

17 Oct 2017

FPGAs: Altera/Intel Tool on Linux

Altera/Intel provides "free" tools (Quartus Prime Lite) in very much the same way as Xilinx (ISE/Vivado). They're "free" in the sense no money is exchanged. But you do need to register; you need to be logged into their website in order to download the installer; and, when run, these tools do communicate details back to the "mother ship". For Xilinx this "feature" is called WebTalk, for Altera/Intel this "feature" is called TalkBack. Unlike Xilinx, Altera/Intel doesn't seem to provide a FAQ or website with information or details about TalkBack (or, at least, my google-foo wasn't strong enough to find it).

The download for Quartus Prime Lite is just a simple tar (it is not compressed). The download for version 17.0.2.602 (the latest as of this writing) is 6.1GB. At first it seems odd that the tar is not compressed, but when I compress it with xz, the resulting file is 8.1GB! In any case, this large download causes me the same issues I had with Xilinx's ISE. Since a registration is required, and I have to be logged in to download the installer, and the webpage likes to automatically log me out after a period of inactivity, and my internet download speed is slow, I ended up having to make several attempts to download the complete 6.1GB file.

On the plus side, however, installing Quartus Prime Lite doesn't involve any license shenanigans. If you download the correct flavour (i.e. the "lite" version) there's no need to mess around with obtaining, installing, and managing a license file. Presumably, this would make it easier to install the software on a different machine and continue development. In contrast, the required license file for ISE/Vivado is locked to an ethernet MAC, so if you move the software or the MAC goes away, you'd be locked out of your Xilinx tools until you rectify the situation.

Another plus for the Quartus Prime Lite software is that this one tool handles all the Altera products. There's no need for one tool to do one set of products, and another tool for newer products.

One of the ironic things about the install is that at one point it asks me if I want to enable the TalkBack "feature". Of course I don't want to enable TalkBack, but the install likes to tease me into thinking that I might be able to install the product without this feature. I can, of course, not install/enable TalkBack, but then I'd need a paid license/subscription. To use the "free" tool, TalkBack must be enabled. By default this "Do you want to enable TalkBack?" button is not checked, forcing me to explicitly turn it on (because I so very much want to enable this "feature"!!).

Other than the above, the install is pretty straight-forward. No libraries need to be deleted (as is required with the Xilinx ISE install), no other "gotchas". Just give it a place to install itself, tell it which products you intend to use, enable TalkBack (yay!), and it does the rest.

16 Oct 2017

FPGAs: Papilio One

One of the first FPGA boards I bought is the Papilio One from Gadget Factory. What I like about the Papilio project is its creator's (Jack Gassett) focus on learning and openness. In addition to Jack's guides and tutorials, a fellow named Mike Field (aka Hamster) wrote a free "Introduction to Spartan FPGA" book based around the Papilio and the LogicStart MegaWing (also from Gadget Factory). Then, along came Álvaro Lopes who created the ZPUino which is a 32-bit Arduino-type soft CPU for the Papilio, complete with Wishbone peripherals and an Arduino-style library and IDE. Also, Make's FPGA book uses the Papilio (among other boards) for some of its projects.

After you've installed Xilinx's ISE, Jack provides a great guide to creating your first VHDL project for the Papilio One. His guide uses a slightly older version of ISE so there are some differences between his guide and what you'll find in ISE 14.7, but nothing that can't be figured out. Generating the bitfile completes successfully for me. Now to upload it to the device.

To upload a bitfile to the Papilio One requires the use of the Papilio-Loader program. Clone the project to your local machine. The cmdline version of the loader program (which is all I'm interested in) is found in the papilio-prog subdirectory; therefore move to that location. Since the papilio uses an FTDI chip for serial communications (via USB), you'll need to install the FTDI devel package; on openSUSE its name is "libftdi1-devel". The build system for papilio-prog is the autotools, and it requires pkg-config to be installed (you'll need to figure out how to do that on your system). After the pkg-config package is installed, you'll need to find where it installed its pkg.m4 file. For me this file was installed to /usr/share/aclocal/pkg.m4. With this information I need to edit the top-level Makefile.am to include the path leading up to the pkg.m4 file:

diff --git a/papilio-prog/Makefile.am b/papilio-prog/Makefile.am
index a0ef45a..a31e9c3 100644
--- a/papilio-prog/Makefile.am
+++ b/papilio-prog/Makefile.am

@@ -1,3 +1,4 @@
+ACLOCAL_AMFLAGS = -I /usr/share/aclocal
 bin_PROGRAMS = papilio-prog

 papilio_prog_SOURCES = butterfly.cpp \

I also modified the top-level configure.ac as follows:
diff --git a/papilio-prog/configure.ac b/papilio-prog/configure.ac
index 230add6..35b428a 100644
--- a/papilio-prog/configure.ac
+++ b/papilio-prog/configure.ac

@@ -14,7 +14,7 @@ if test -n "$host_alias" ; then
        AC_DEFINE([WINDOWS], 1, [Cross-compiling for windows])
        LIBS="$LIBS -L. -lftd2xx -static-libgcc -static-libstdc++"
 else
-       PKG_CHECK_MODULES([libftdi1], [libftdi >= 0.19],
+       PKG_CHECK_MODULES([libftdi1], [libftdi1 >= 0.19],
                [CPPFLAGS="$CPPFLAGS $libftdi1_CFLAGS";
                LIBS="$LIBS $libftdi1_LIBS"])
 fi

With those adjustments in place, building was a simple matter of:

$ ./autogen.sh
Generating build system...
$ ./configure
...
$ make
...

Install the resulting papilio-prog to someplace in your $PATH. Plug the Papilio-One into your computer via a USB cable (you only need to connect the USB cable for both communication and power, no need to plug anything into the power barrel jack).

When the papilio is plugged in, you should find an extra USB device on your system:
$ lsusb
...
Bus 001 Device 067: ID 0403:6010 Future Technology Devices International, Ltd FT2232C Dual USB-UART/FIFO IC
...

Then, once you've located your bitfile, you can perform the following to upload it to your device:
# papilio-prog -f Webpack_Quickstart.bit
Using built-in device list
JTAG chainpos: 0 Device IDCODE = 0x41c22093     Desc: XC3S500E
Created from NCD file: Webpack_Quickstart.ncd;UserID=0xFFFFFFFF
Target device: 3s500evq100
Created: 2017/09/30 00:55:28
Bitstream length: 2270208 bits

Uploading "Webpack_Quickstart.bit".

Note that I'm running papilio-prog as root. If I wanted to get fancy I could create a udev rule to set this device's file mode to 0666.

When I plug my papilio into my machine, the following shows up in my system logs:
kernel: usb 1-4.4.4: new full-speed USB device number 69 using xhci_hcd
kernel: usb 1-4.4.4: New USB device found, idVendor=0403, idProduct=6010
kernel: usb 1-4.4.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
kernel: usb 1-4.4.4: Product: Dual RS232
kernel: usb 1-4.4.4: Manufacturer: FTDI
kernel: ftdi_sio 1-4.4.4:1.0: FTDI USB Serial Device converter detected
kernel: usb 1-4.4.4: Detected FT2232C
kernel: usb 1-4.4.4: FTDI USB Serial Device converter now attached to ttyUSB1
kernel: ftdi_sio 1-4.4.4:1.1: FTDI USB Serial Device converter detected
kernel: usb 1-4.4.4: Detected FT2232C
kernel: usb 1-4.4.4: FTDI USB Serial Device converter now attached to ttyUSB2
mtp-probe[24662]: checking bus 1, device 69: "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-4/1-4.4/1-4.4.4"
mtp-probe[24662]: bus: 1, device: 69 was not an MTP device
As you can see, two USB devices get created. The second one can be used for serial logging. The test bitfile provided for the Papilio One demonstrates this feature: Papilio One 500K QuickStart bit file. Opening up a terminal emulator (e.g. minicom) on the second USB device (9600 8N1) will show what is being logged over the serial port.



My final verdict for this board is positive! The Spartan 3E is an older chip, but there is a 500k version (which is a pretty good size for a beginner). The tools install and work on Linux. It's possible to upload bitfiles to the board using Linux. The price of the board is reasonable. Plus, there are lots of learning materials targeted at this board specifically.





FPGAs: Xilinx Tools on Linux

Historically the "free" tool from Xilinx to work with Xilinx FPGAs is ISE Webpack (or just ISE). That tool is still around, is still "free", and still works in Linux (I'll explain later why I write "free" in quotes). For the past few years, however, Xilinx has created a newer tool, Vivado, for working with Xilinx products. Although ISE is still available, it hasn't received any updates for the past couple years (since 2013). But here's the funny part: Vivado doesn't support the older chips. So if you're working with older Xilinx chips (Spartan 3 or Spartan 6) you have to use the old, hasn't been updated since 2013, ISE. If you want to play with any of Xilinx's newer chips (Zynq, Artix, or UltraScale) you'll need to use Vivado. So if you happen to have projects involving both chips, you'll need to download and install two separate tools.

One small issue that messed me up occurred while I was trying to download the install package for ISE. The 14.7 version of the ISE Linux installer is 6.1GB. I live way out in a rural area, so my internet connection is slow. In order to download the installer, I had to be logged into the Xilinx site for the entire duration of the download. After a period of inactivity, Xilinx's site will log out out automatically. Since my download hadn't completed before the website automatically logged me out, my download would fail. One solution is to start the download early in the morning and to make sure you play around on the Xilinx website throughout the day to keep yourself from getting logged out automatically. Another possibility is to just let it download as long as possible, when it fails, re-login to Xilinx's site, then restart the download. Firefox's downloader is smart enough to continue the download (as opposed to requiring the entire download to be started again from scratch).

In contrast, the download for installing Vivado is only about 85MB which is easier to download over a slow connection before getting logged out. However, during the installation you'll need to make sure you stay logged in because the remainder of the download occurs during the installation itself, which could cause it to fail if you get automatically logged out.

Whether you're installing ISE or Vivado, one of the biggest headaches is the licensing. If you want to unlock features above-and-beyond the base, "free" features you'll need to pay for a license. This gives you a file you need to install, which unlocks the features for which you've paid. That all makes sense. However, even if you don't want any of those fancy paid features and are only using the "free" things, you still need to generate a license file and install it. In theory the installer is supposed to handle all the licensing for you. In practice it doesn't seem to work that well on Linux. Therefore a special trip to Xilinx's website is required to create the license file and download it. Then it has to be installed manually after the install itself has completed before you can hope to run the application.

Installing and running ISE can succeed, but only with a fair amount of work. Rob Landley has an excellent, detailed, step-by-step post on how to get ISE installed and running on a Linux host. I won't bother reproducing it here, but simply point you to it.

Installing and running Vivado on Linux follows, roughly, the same steps. Once you've done one, the other will be familiar. It appears as though there are no issues having both installed and running on the same host at the same time. The Vivado install also didn't require any libc files to be manually deleted, so that's a good thing. But all the same license shenanigans are still required to unlock the "free" features.

So why do I keep writing "free" in quotes? Xilinx's definition of "free" means "no money exchanged". But in exchange for not paying money Xilinx does want to collect information about you and your projects... lots of information.

First off, in order to download ISE or Vivado, you need to register an account on their website. I know that many (most?) people don't consider providing a name and such other information as much of a "cost". But data is worth a lot of money, and I wish more people would stop thinking that providing information doesn't have an associated cost. I've downloaded the Linux kernel, Linux-based distributions, and other GNU/Linux software thousands of times in the past and never needed a registration in order to do so. Besides, the fact Xilinx requires a registration has been the cause of my download headaches (as I've pointed out above).

Secondly, and more to the point, whenever you use their "free" tools, those tools communicate information about your machine and your project back to the "mother ship". Although Xilinx tries to provide full information about this feature (called WebTalk), it does seem rather insidious to me. They have a page that answers most questions about WebTalk, but since the communication is all proprietary, I guess we'll just have to take their word when they say they're not being evil.

Finally, all this license nonsense requires a lot of fiddling and so forth should you ever want to move to a different machine.

All this effort wasted on handling and managing licensing, plus all the gobs of data that is provided to Xilinx (both explicitly and implicitly) does not feel "free" to me!

Oh well, I guess I should be grateful I can work with Xilinx parts using an all-Linux environment. Yay!

Starting FPGAs

Learning FPGAs has been on my "TODO" list for a while.

Many years ago I had the opportunity to work on a new project that involved embedded Linux and FPGAs. As the "Linux software person" I worked entirely on the Linux software. But I had the good fortune to work with some brilliant FPGA people. I was blown away. It was amazing to sit down with these people and say "I could really use a register that works like <this>" and a couple hours later be emailed a new bitfile, load it in, and find a register that did exactly as I wanted! Brand new, custom designed hardware... on a whim! The development of the product progressed hand-in-hand in this way, and it was a very successful endeavour!

It didn't take long, however, for me to wish that I could work both sides of the coin: I can do the Linux stuff (user-space apps, device drivers, creating images, etc) but it would be great to also be able to "play" with the FPGA side as well. Although I wasn't able to find the time to learn FPGAs back then, I did make sure to ask lots of questions of these experts while I was around them. The two most basic questions that quickly come up are: What hardware (vendor) should I use? Should I learn VHDL or verilog (or something else)?

What I found interesting about their answers is that they readily admitted that their choice of vendor and language today was based entirely on whatever technology they were taught at university. It's not about vendor lock-in per se, it's about the tendency to learn a tool, becoming proficient at it, then developing a reluctance to want to build the same proficiency in another tool (or language) for no apparent gain. The same things can be done, roughly, in both languages. The capabilities of the hardware from the various vendors is, roughly, on par. There is no clear winner in either category (or so is my understanding).

At this point I have no idea how proficient (or not) I might become in actually developing my own projects. My point, for now, is to know enough to be able to play with existing things I find (e.g. OpenCores). For my purposes, in terms of VHDL vs verilog, I see lots of interesting projects that are done using both; both languages seem to be equally popular. Ideally it would be nice to have some familiarity of both. There are also a couple projects that try to bring things like C or Python to the world of digital development. Those might be interesting to explore as well.

My thoughts regarding hardware are similar to how I feel about HDLs. I would rather become somewhat knowledgeable on a bunch of them rather than to be good at only one. Also, since I do all my development work on a Linux machine, one thing that will be important for me is how well the development workflow of the various vendors supports Linux. How easy (or hard) is it to develop for vendor A's product in Linux (including getting the result into real hardware) versus vendor B, C, or D?


FPGAs have always been an interesting and fascinating technology. Coupling them with Linux in an embedded environment, I think, is an amazing partnership. Linux is great, and real-time Linux is amazing. But, let's face it, nobody can realistically promise absolute strict timing as long as a software scheduler is involved. When done well, using an FPGA can cover those things that absolutely need very strict timings. FPGAs also provide a decent place to "hide" the magic sauce of your project. Also, with good profiling, it's possible to find those processing-intensive parts of your design and potentially move them out to hardware.

I think FPGA companies have sold as many FPGAs to EEs as they're going to. Their next wave is going to come from software developers :-)

24 Jun 2017

etnaviv/vivante Update

Lucas Stach suggested I also run the test (glmark2-es2) with --off-screen. Here are those results from a recent build.

Note that the etnaviv test
  • will sometimes segfault (usually somewhere in the [conditionals] tests)
  • the [ideas] test sometimes will cause a GPU hangcheck
  • and the [terrain] test complains saying "etna_draw_vbo:199: compiled shaders are not okay"



wandboard
GL_VENDORVivante Corporationetnaviv
GL_RENDERERVivante GC880Gallium 0.4 on Vivante GC880 rev 5106
GL_VERSIONOpenGL ES 3.0 V5.0.11.p8.41671OpenGL ES 2.0 Mesa 17.1.1
glmark2 score116521934756138
/proc/loadavg0.410.150.150.260.500.15
--fullscreen--off-screen--fullscreen--off-screen
[build]20414145180136437
[build]25915871384160614
[texture]20111452376108294
[texture]20211349276100286
[texture]1991094787597259
[shading]20512239281119335
[shading]170611847076160
[shading]10839111515297
[shading]813083423969
[bump]124551285769119
[bump]230722817898236
[bump]203612237073163
[effect2d]621568332647
[effect2d]2352314916
[pulsar]1858441475102372
[desktop]31931151018
[desktop]10433122423971
[buffer]483253303346
[buffer]493252293247
[buffer]553562363851
[ideas]4444435100
[jellyfish]611962292338
[terrain]101212
[shadow]9229107383462
[refract]2092010811
[conditionals]209773836978169
[conditionals]611965332647
[conditionals]204763476576159
[function]11436130494790
[function]341135302442
[loop]10534119494688
[loop]10534119494588
[loop]551869302442

9 Jun 2017

GPU Support with OpenEmbedded (etnaviv/vivante)

 Introduction

This series of articles assumes some familiarity with OpenEmbedded, but if you haven't used it before, hopefully you can follow along. If you've never used OpenEmbedded before and would like to give these build instructions a try, start off by reading and trying the examples in The Yocto Project's Quick Start Guide. Hopefully that will get you and your machine setup.

There are many SoCs that incorporate the Vivante GPU. I happen to have the Wandboard Dual, so that's the board I'll be using for my tests.

Build Setup

To begin an OpenEmbedded build (assuming your Linux build machine has all the necessary packages), we need to choose some place on our computer to which we have rwx access, and grab the necessary metadata. The first chunks of metadata contains all the base, generic things:

$ git clone git://git.openembedded.org/openembedded-core
$ git clone git://git.openembedded.org/meta-openembedded

Then we need to add BSP metadata. Most BSPs consist of one layer, but in the case of the Wandboard we need the generic freescale BSP layer (meta-freescale) and the BSP that specifically supports the Wandboard (meta-freescale-3rdparty). The Wandboard has an i.MX6 SoC on it which was made by Freescale. In 2015 NXP merged with Freescale. Although the i.MX6 is, technically, an NXP SoC, the layer retains the "freescale" name.

$ git clone https://git.yoctoproject.org/git/meta-freescale
$ git clone https://github.com/Freescale/meta-freescale-3rdparty

How did I possibly know I needed those two layers? By consulting the layer index. The layer index is where layer maintainers go to make their layers known, and it's a great place for users to go to find support machines, software, distros, etc. If you're not working with the Wandboard, then you'll need to consult the layer index to figure out which layers you need for your specific hardware.

Now we need the tool that uses all this metadata and actually performs the build:

$ git clone  git://git.openembedded.org/bitbake

Now that we have all the pieces in place, we setup our shell

$ . openembedded-core/oe-init-build-env build bitbake/
You had no conf/local.conf file. This configuration file has therefore been
created for you with some default values. You may wish to edit it to, for
example, select a different MACHINE (target hardware). See conf/local.conf
for more information as common configuration options are commented.

You had no conf/bblayers.conf file. This configuration file has therefore been
created for you with some default values. To add additional metadata layers
into your configuration please add entries to conf/bblayers.conf.

The Yocto Project has extensive documentation about OE including a reference
manual which can be found at:
    http://yoctoproject.org/documentation

For more information about OpenEmbedded see their website:
    http://www.openembedded.org/


### Shell environment set up for builds. ###

You can now run 'bitbake <target>'

Common targets are:
    core-image-minimal
    core-image-sato
    meta-toolchain
    meta-ide-support

You can also run generated qemu images with a command like 'runqemu qemux86'

This creates the build directory ("build") that was specified on the shell setup line. Now we tell bitbake about our additional layers:

$ bitbake-layers add-layer ../meta-freescale
Parsing recipes: 100% |#########################################################| Time: 0:00:12
Parsing of 925 .bb files complete (0 cached, 925 parsed). 1408 targets, 149 skipped, 0 masked, 0 errors.
$ bitbake-layers add-layer ../meta-freescale-3rdparty
Parsing recipes: 100% |#########################################################| Time: 0:00:07
Parsing of 962 .bb files complete (0 cached, 962 parsed). 1445 targets, 185 skipped, 0 masked, 0 errors.
$ bitbake-layers add-layer ../meta-openembedded/meta-oe
Parsing recipes: 100% |#########################################################| Time: 0:00:13
Parsing of 1614 .bb files complete (0 cached, 1614 parsed). 2226 targets, 265 skipped, 0 masked, 0 errors.

Vivante Build

 By default, the "freescale" BSP layers assume the user wants to build an image using the vivante binary blob. This blob isn't "free", so in order to use it, you have to agree to its EULA. To do that, you have to read the "EULA" file you'll find at the top-level of the meta-freescale BSP that was cloned earlier. Once you've read that file and agreed to it, you can proceed with this build. If you don't or can't agree to the EULA, then you can proceed directly to the Etnaviv build.

When you setup your shell, earlier, it created a boilerplate configuration file for you. From the "build" directory that was created for you during setup, open the conf/local.conf file with your favourite text editor and add the following lines at the top (be sure to leave the rest of the file as-is!):

ACCEPT_FSL_EULA = "1"
CORE_IMAGE_EXTRA_INSTALL += "openbox glmark2"
DISTRO_FEATURES_append = " opengl x11"
IMAGE_FEATURES += "x11"

Once that's done you can run your build:

$ MACHINE=wandboard bitbake core-image-full-cmdline
Parsing recipes: 100% |#########################################################| Time: 0:00:14
Parsing of 1614 .bb files complete (0 cached, 1614 parsed). 2226 targets, 249 skipped, 0 masked, 0 errors.
NOTE: Resolving any missing task queue dependencies

Build Configuration:
BB_VERSION        = "1.34.0"
BUILD_SYS         = "x86_64-linux"
NATIVELSBSTRING   = "opensuse-42.2"
TARGET_SYS        = "arm-oe-linux-gnueabi"
MACHINE           = "wandboard"
DISTRO            = "nodistro"
DISTRO_VERSION    = "nodistro.0"
TUNE_FEATURES     = "arm armv7a vfp thumb neon callconvention-hard cortexa9"
TARGET_FPU        = "hard"
meta              = "master:186882ca62bf683b93cd7a250963921b89ba071f"
meta-freescale    = "master:98d57b06d88cb22129bd417a9a3edbaf24612460"
meta-freescale-3rdparty = "master:fd3962a994b2f477d3e81fa7083f6b3d4e666df5"
meta-oe           = "master:41cf832cc9abd6f2293a6d612463a34a53a9a52a"

Initialising tasks: 100% |######################################################| Time: 0:00:04
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
NOTE: Tasks Summary: Attempted 4369 tasks of which 2317 didn't need to be rerun and all succeeded.

From this successful build we'll find our device image located at:

tmp-glibc/deploy/images/wandboard/core-image-full-cmdline-wandboard.wic.gz

If you unzip this wic file, it can be dd'ed directly to a microSD card, this microSD card can be inserted into the Wandboard, which can then be powered up.

$ gzip -d < tmp-glibc/deploy/images/wandboard/core-image-full-cmdline-wandboard.wic.gz > core-image-full-cmdline-wandboard.wic
$ su
Password:
# dd if=core-image-full-cmdline-wandboard.wic of=/dev/sdi bs=10M
21+1 records in
21+1 records out
222298112 bytes (222 MB, 212 MiB) copied, 85.6691 s, 2.6 MB/s

I like to interact with embedded boards via a serial console. On the Wandboard, this means using a DE-9 serial cable. Once the board boots up I login and run the benchmark application:

OpenEmbedded nodistro.0 wandboard /dev/ttymxc0

wandboard login: D-BUS per-session daemon address is: unix:abstract=/tmp/dbus-fd5NI0apUa,guid=772b87be1cee0f1d2acde6c25938e674
Using calibration data stored in /etc/pointercal.xinput
Invalid format 42060
unable to find device EETI eGalax Touch Screen
INFO: width=1920, height=1080
Obt-Message: Failed to open an Input Method
Openbox-Message: X server does not support locale.
Openbox-Message: Cannot set locale modifiers for the X server.

root
root@wandboard:~# uname -a
Linux wandboard 4.1.15-1.1.0-ga-wandboard+g8b015473d340 #1 SMP PREEMPT Wed Jun 7 23:42:49 EDT 2017 armv7l armv7l armv7l GNU/Linux
root@wandboard:~# export DISPLAY=:0
root@wandboard:~# glmark2-es2
=======================================================
    glmark2 2014.03
=======================================================
    OpenGL Information
    GL_VENDOR:     Vivante Corporation
    GL_RENDERER:   Vivante GC880
    GL_VERSION:    OpenGL ES 3.0 V5.0.11.p8.41671
=======================================================
[build] use-vbo=false: FPS: 206 FrameTime: 4.854 ms
[build] use-vbo=true: FPS: 246 FrameTime: 4.065 ms
[texture] texture-filter=nearest: FPS: 200 FrameTime: 5.000 ms
[texture] texture-filter=linear: FPS: 200 FrameTime: 5.000 ms
[texture] texture-filter=mipmap: FPS: 199 FrameTime: 5.025 ms
[shading] shading=gouraud: FPS: 205 FrameTime: 4.878 ms
[shading] shading=blinn-phong-inf: FPS: 170 FrameTime: 5.882 ms
[shading] shading=phong: FPS: 108 FrameTime: 9.259 ms
[shading] shading=cel: FPS: 81 FrameTime: 12.346 ms
[bump] bump-render=high-poly: FPS: 124 FrameTime: 8.065 ms
[bump] bump-render=normals: FPS: 220 FrameTime: 4.545 ms
[bump] bump-render=height: FPS: 203 FrameTime: 4.926 ms
libpng warning: iCCP: known incorrect sRGB profile
[effect2d] kernel=0,1,0;1,-4,1;0,1,0;: FPS: 62 FrameTime: 16.129 ms
libpng warning: iCCP: known incorrect sRGB profile
[effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: 23 FrameTime: 43.478 ms
[pulsar] light=false:quads=5:texture=false: FPS: 183 FrameTime: 5.464 ms
libpng warning: iCCP: known incorrect sRGB profile
[desktop] blur-radius=5:effect=blur:passes=1:separable=true:windows=4: FPS: 31 FrameTime: 32.258 ms
libpng warning: iCCP: known incorrect sRGB profile
[desktop] effect=shadow:windows=4: FPS: 103 FrameTime: 9.709 ms
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 49 FrameTime: 20.408 ms
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=subdata: FPS: 49 FrameTime: 20.408 ms
[buffer] columns=200:interleave=true:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 57 FrameTime: 17.544 ms
[ideas] speed=duration: FPS: 44 FrameTime: 22.727 ms
[jellyfish] <default>: FPS: 61 FrameTime: 16.393 ms
[terrain] <default>: FPS: 1 FrameTime: 1000.000 ms
[shadow] <default>: FPS: 92 FrameTime: 10.870 ms
[refract] <default>: FPS: 20 FrameTime: 50.000 ms
[conditionals] fragment-steps=0:vertex-steps=0: FPS: 209 FrameTime: 4.785 ms
[conditionals] fragment-steps=5:vertex-steps=0: FPS: 61 FrameTime: 16.393 ms
[conditionals] fragment-steps=0:vertex-steps=5: FPS: 203 FrameTime: 4.926 ms
[function] fragment-complexity=low:fragment-steps=5: FPS: 114 FrameTime: 8.772 ms
[function] fragment-complexity=medium:fragment-steps=5: FPS: 34 FrameTime: 29.412 ms
[loop] fragment-loop=false:fragment-steps=5:vertex-steps=5: FPS: 105 FrameTime: 9.524 ms
[loop] fragment-steps=5:fragment-uniform=false:vertex-steps=5: FPS: 105 FrameTime: 9.524 ms
[loop] fragment-steps=5:fragment-uniform=true:vertex-steps=5: FPS: 55 FrameTime: 18.182 ms
=======================================================
                                  glmark2 Score: 115
=======================================================

Some of the relevant packages in this build include:
  • libegl-mesa_2:17.1.1
  • libgles2-mesa_2:17.1.1
  • libgl-mesa_2:17.1.1
  • xserver-xorg_2:1.19.3
  • kernel-4.1.15-1.1.0-ga-wandboard+g8b015473d340
  • libc6_2.25
  • glmark2_2014.03+0+7215c0f337
  • cross-compiler: gcc-6.3.0

Etnaviv Build

Switching to a build that uses etnaviv isn't very hard. Keeping the bottom part of the configuration file as it was found, modify the top of conf/local.conf so that it looks like:

MACHINEOVERRIDES .= ":use-mainline-bsp"
CORE_IMAGE_EXTRA_INSTALL += "openbox glmark2"
DISTRO_FEATURES_append = " opengl x11"
IMAGE_FEATURES += "x11"

Since you're no longer using the binary blob, agreeing to the EULA is no longer required. Telling the build you want to switch to more "upstream" components is just a matter of adding the MACHINEOVERRIDES line.

Building:

$ MACHINE=wandboard bitbake core-image-full-cmdline
Parsing recipes: 100% |#########################################################| Time: 0:00:17
Parsing of 1614 .bb files complete (0 cached, 1614 parsed). 2226 targets, 265 skipped, 0 masked, 0 errors.
NOTE: There are 199 recipes to be removed from sysroot wandboard, removing...
NOTE: Resolving any missing task queue dependencies

Build Configuration:
BB_VERSION        = "1.34.0"
BUILD_SYS         = "x86_64-linux"
NATIVELSBSTRING   = "opensuse-42.2"
TARGET_SYS        = "arm-oe-linux-gnueabi"
MACHINE           = "wandboard"
DISTRO            = "nodistro"
DISTRO_VERSION    = "nodistro.0"
TUNE_FEATURES     = "arm armv7a vfp thumb neon callconvention-hard"
TARGET_FPU        = "hard"
meta              = "master:186882ca62bf683b93cd7a250963921b89ba071f"
meta-freescale    = "master:98d57b06d88cb22129bd417a9a3edbaf24612460"
meta-freescale-3rdparty = "master:fd3962a994b2f477d3e81fa7083f6b3d4e666df5"
meta-oe           = "master:41cf832cc9abd6f2293a6d612463a34a53a9a52a"

Initialising tasks: 100% |######################################################| Time: 0:00:07
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
NOTE: Tasks Summary: Attempted 4396 tasks of which 1407 didn't need to be rerun and all succeeded.

Unpack the wic file, dd it to a microSD card, and boot it up on the Wandboard:

OpenEmbedded nodistro.0 wandboard /dev/ttymxc0

wandboard login: Error: No calibratable devices found.
Obt-Message: Failed to open an Input Method
Openbox-Message: X server does not support locale.
Openbox-Message: Cannot set locale modifiers for the X server.

root
root@wandboard:~# uname -a
Linux wandboard 4.9.21-fslc+gb69ecd63c123 #1 SMP Thu Jun 8 02:34:26 EDT 2017 armv7l armv7l armv7l GNU/Linux
root@wandboard:~#
export DISPLAY=:0
root@wandboard:~# glmark2-es2
=======================================================
    glmark2 2014.03
=======================================================
    OpenGL Information
    GL_VENDOR:     etnaviv
    GL_RENDERER:   Gallium 0.4 on Vivante GC880 rev 5106
    GL_VERSION:    OpenGL ES 2.0 Mesa 17.1.1
=======================================================
[build] use-vbo=false: FPS: 81 FrameTime: 12.346 ms
[build] use-vbo=true:[   59.956033] random: crng init done
 FPS: 91 FrameTime: 10.989 ms
[texture] texture-filter=nearest: FPS: 80 FrameTime: 12.500 ms
[texture] texture-filter=linear: FPS: 78 FrameTime: 12.821 ms
[texture] texture-filter=mipmap: FPS: 75 FrameTime: 13.333 ms
[shading] shading=gouraud: FPS: 87 FrameTime: 11.494 ms
[shading] shading=blinn-phong-inf: FPS: 68 FrameTime: 14.706 ms
[shading] shading=phong: FPS: 51 FrameTime: 19.608 ms
[shading] shading=cel: FPS: 42 FrameTime: 23.810 ms
[bump] bump-render=high-poly: FPS: 57 FrameTime: 17.544 ms
[bump] bump-render=normals: FPS: 74 FrameTime: 13.514 ms
[bump] bump-render=height: FPS: 66 FrameTime: 15.152 ms
libpng warning: iCCP: known incorrect sRGB profile
[effect2d] kernel=0,1,0;1,-4,1;0,1,0;: FPS: 34 FrameTime: 29.412 ms
libpng warning: iCCP: known incorrect sRGB profile
[effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: 14 FrameTime: 71.429 ms
[pulsar] light=false:quads=5:texture=false: FPS: 75 FrameTime: 13.333 ms
libpng warning: iCCP: known incorrect sRGB profile
[desktop] blur-radius=5:effect=blur:passes=1:separable=true:windows=4: FPS: 15 FrameTime: 66.667 ms
libpng warning: iCCP: known incorrect sRGB profile
[desktop] effect=shadow:windows=4: FPS: 42 FrameTime: 23.810 ms
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 30 FrameTime: 33.333 ms
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=subdata: FPS: 29 FrameTime: 34.483 ms
[buffer] columns=200:interleave=true:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 34 FrameTime: 29.412 ms
[ideas] speed=duration:[  253.131165] etnaviv-gpu 130000.gpu: hangcheck detected gpu lockup!
[  253.137434] etnaviv-gpu 130000.gpu:      completed fence: 11419
[  253.143413] etnaviv-gpu 130000.gpu:      active fence: 11420
[  253.150061] etnaviv-gpu 130000.gpu: hangcheck recover!
[  257.691146] etnaviv-gpu 130000.gpu: hangcheck detected gpu lockup!
[  257.697403] etnaviv-gpu 130000.gpu:      completed fence: 11420
[  257.703374] etnaviv-gpu 130000.gpu:      active fence: 11421
[  257.709247] etnaviv-gpu 130000.gpu: hangcheck recover!
[  263.931124] etnaviv-gpu 130000.gpu: hangcheck detected gpu lockup!
[  263.937380] etnaviv-gpu 130000.gpu:      completed fence: 11423
[  263.943352] etnaviv-gpu 130000.gpu:      active fence: 11425
[  263.949221] etnaviv-gpu 130000.gpu: hangcheck recover!
[  269.131129] etnaviv-gpu 130000.gpu: hangcheck detected gpu lockup!
[  269.137383] etnaviv-gpu 130000.gpu:      completed fence: 11425
[  269.143355] etnaviv-gpu 130000.gpu:      active fence: 11427
[  269.149324] etnaviv-gpu 130000.gpu: hangcheck recover!
 FPS: 0 FrameTime: inf ms
[jellyfish] <default>: FPS: 29 FrameTime: 34.483 ms
[terrain] <default>:error: compile failed!
etna_draw_vbo:199: compiled shaders are not okay
error: compile failed!
etna_draw_vbo:199: compiled shaders are not okay
error: compile failed!
etna_draw_vbo:199: compiled shaders are not okay
error: compile failed!
etna_draw_vbo:199: compiled shaders are not okay
error: compile failed!
etna_draw_vbo:199: compiled shaders are not okay
error: compile failed!
etna_draw_vbo:199: compiled shaders are not okay
error: compile failed!
etna_draw_vbo:199: compiled shaders are not okay
error: compile failed!
etna_draw_vbo:199: compiled shaders are not okay
error: compile failed!
etna_draw_vbo:199: compiled shaders are not okay
error: compile failed!
etna_draw_vbo:199: compiled shaders are not okay
error: compile failed!
etna_draw_vbo:199: compiled shaders are not okay
error: compile failed!
etna_draw_vbo:199: compiled shaders are not okay
error: compile failed!
etna_draw_vbo:199: compiled shaders are not okay
error: compile failed!
etna_draw_vbo:199: compiled shaders are not okay
error: compile failed!
etna_draw_vbo:199: compiled shaders are not okay
error: compile failed!
etna_draw_vbo:199: compiled shaders are not okay
error: compile failed!

etna_draw_vbo:199: compiled shaders are not okay
error: compile failed!
etna_draw_vbo:199: compiled shaders are not okay
error: compile failed!
etna_draw_vbo:199: compiled shaders are not okay
error: compile failed!
etna_draw_vbo:199: compiled shaders are not okay
error: compile failed!
etna_draw_vbo:199: compiled shaders are not okay
error: compile failed!
etna_draw_vbo:199: compiled shaders are not okay
error: compile failed!
etna_draw_vbo:199: compiled shaders are not okay
error: compile failed!
etna_draw_vbo:199: compiled shaders are not okay
error: compile failed!
etna_draw_vbo:199: compiled shaders are not okay
error: compile failed!
etna_draw_vbo:199: compiled shaders are not okay
 FPS: 2 FrameTime: 500.000 ms
[shadow] <default>: FPS: 39 FrameTime: 25.641 ms
[refract] <default>: FPS: 10 FrameTime: 100.000 ms
[conditionals] fragment-steps=0:vertex-steps=0: FPS: 70 FrameTime: 14.286 ms
[conditionals] fragment-steps=5:vertex-steps=0: FPS: 33 FrameTime: 30.303 ms
[conditionals] fragment-steps=0:vertex-steps=5: FPS: 65 FrameTime: 15.385 ms
[function] fragment-complexity=low:fragment-steps=5: FPS: 50 FrameTime: 20.000 ms
[function] fragment-complexity=medium:fragment-steps=5: FPS: 30 FrameTime: 33.333 ms
[loop] fragment-loop=false:fragment-steps=5:vertex-steps=5: FPS: 49 FrameTime: 20.408 ms
[loop] fragment-steps=5:fragment-uniform=false:vertex-steps=5: FPS: 49 FrameTime: 20.408 ms
[loop] fragment-steps=5:fragment-uniform=true:vertex-steps=5: FPS: 30 FrameTime: 33.333 ms
=======================================================
                                  glmark2 Score: 47
=======================================================

Some of the relevant packages in this build include:
  • libegl-mesa_2:17.1.1
  • libgles2-mesa_2:17.1.1
  • libgl-mesa_2:17.1.1
  • xserver-xorg_2:1.19.3
  • kernel-image-4.9.21-fslc
  • libc6_2.25
  • glmark2_2014.03+0+7215c0f337
  • cross-compiler: gcc-6.3.0

Results

My test currently consists of running glmark2-es2 (i.e. the OpenGL ES2 version of glmark2). As of today, the etnaviv support isn't as full-featured as the binary blob. However, using etnaviv doesn't require any EULAs, and it lets you use a newer kernel. Thanks to how well the freescale layers are organized/maintained, switching between the two builds is quite easy.

Here's a side-by-side comparison:

vivanteetnaviv
GL_VENDORVivante Corporationetnaviv
GL_RENDERERVivante GC880Gallium 0.4 on Vivante GC880 rev 5106
GL_VERSIONOpenGL ES 3.0 V5.0.11.p8.41671OpenGL ES 2.0 Mesa 17.1.1

glmark2(-es2) is a set of individual tests that are run back-to-back. They can be run individually, but calling "glmark2-es2" by itself simply invokes all of them sequentially.

vivanteetnaviv
glmark2-es2 score11547
[build]20681
[build]24691
[texture]20080
[texture]20078
[texture]19975
[shading]20587
[shading]17068
[shading]10851
[shading]8142
[bump]12457
[bump]22074
[bump]20366
[effect2d]6234
[effect2d]2314
[pulsar]18375
[desktop]3115
[desktop]10342
[buffer]4930
[buffer]4929
[buffer]5734
[ideas]44(hangcheck)
[jellyfish]6129
[terrain]12 (shader compile failed)
[shadow]9239
[refract]2010
[conditionals]20970
[conditionals]6133
[conditionals]20365
[function]11450
[function]3430
[loop]10549
[loop]10549
[loop]5530