Tuesday, January 26, 2016

Hurrican 2D Platformer on i.MX6 Sabrelite

Hurrican is a retro/16-bit styled 2D platformer that I was able to build from source on an i.MX6 Sabrelite board with essentially zero effort, as it has already been ported to SDL 1.2 and GLES2.

Some background info may be of interest on the forum posting at Phoronix. Apparently Hurrican was entirely a Windoze game ported to Linux-SDL-GL by pickle who is pretty active on the Open Pandora Pyra community, which I have been looking at quite a bit lately to research games and GL stuff to try out on the i.MX6 board.

This one builds and runs "out of the box" as they say on my system, with great sound music, keyboard control and no obvious glitches.

Repository Root: svn://svn.code.sf.net/p/hurrican/code

sdl1.2 is installed from the distribution and apparently with GLES2 target enabled ...

apt-get install libsdl-mixer1.2-dev libsdl-image1.2-dev libsdl1.2-dev libmodplug-dev
cd hurrican-code/Hurrican/src/
make TARGET=linux_GL2  # this will link with -lGLESv2

I should get a screenshot of the thing running but even better is gratuitous nerdy console output showing all the startup logging gotta love it ...



More info on Hurrican over at Odroid forum.









Monday, January 25, 2016

mesa demos revisited on i.MX6

In my quest to better understand GL/GLES I previously setup an Debian environment on i.MX6 and installed Freescale support libraries to enable hardware accelerated GL functionality.

Download source for mesa-demos-8.3.0.

Build is done in native armhf environment on the i.MX6 Sabre-lite. With usr libraries and headers installed, the following error is seen in the build:

 /usr/include/EGL/egl.h:39,
                 from eglut.c:32:
/usr/include/EGL/eglvivante.h:242:2: error: #error "Platform not recognized"
 #error "Platform not recognized"

Use the following configure to define platform LINUX:

CFLAGS=-DLINUX ./configure --enable-vg=no

(configure detects "vg" available on my system but throws many compile errors which I don't care to deal with for now so use --enable-vg=no   to avoid additional errors)

The following modules are automatically enabled from the above configure line ... one outcome I didn't check for was situation with GL support (what any header files are supplied with support libraries):
checking for GLEW... yes
checking for GLU... yes
checking for EGL... yes
checking for GLESV1... yes
checking for GLESV2... yes
checking for OSMESA... no
checking for DRM... yes
checking for X11... yes
checking for GBM... yes
checking for FREETYPE2... yes

The following error is seen in the build  ... assume at least in this case it is a benign side affect of co-mingling locally built packages with chip vendor support libraries:

/usr/bin/ld: warning: libGL.so.1, needed by /usr/lib/gcc/arm-linux-gnueabihf/4.9/../../../arm-linux-gnueabihf/libGLEW.so, may conflict with libGL.so.1.2

Demos in src/egl/opengles1src/egl/opengles2 working.
Some in src/demos working, some not, some real slow.
Most in src/tests apparently not ... glutfx full screen but otherwise not interesting.
I noticed from eglinfo that there is no 'gl' context so don't expect anything from src/egl/opengl to work.

debian@arm:~/src/mesa/mesa-demos-8.3.0/src/egl/opengl$ DISPLAY=:0 LIBGL_DEEBUG=verbose ./eglinfo -info
EGL API version: 1.4
EGL vendor string: Vivante Corporation
EGL version string: 1.4
EGL client APIs: OpenGL_ES OpenVG
EGL extensions string:
    EGL_KHR_reusable_sync EGL_KHR_fence_sync EGL_KHR_image
    EGL_KHR_image_base EGL_KHR_image_pixmap EGL_KHR_gl_texture_2D_image
    EGL_KHR_gl_texture_cubemap_image EGL_KHR_gl_renderbuffer_image
    EGL_KHR_lock_surface EGL_KHR_create_context
    EGL_EXT_create_context_robustness EGL_EXT_buffer_age
EGL client extensions string:
Configurations:
     bf lv colorbuffer dp st  ms    vis   cav bi  renderable  supported
  id sz  l  r  g  b  a th cl ns b    id   eat nd gl es es2 vg surfaces 
---------------------------------------------------------------------
0x01 12  0  4  4  4  0  0  0  0 0 0x21--      a     y  y     win,pb
0x02 12  0  4  4  4  0  0  8  0 0 0x21--      a     y  y     win,pb


src/xdemos/glxgears is good to go: 

debian@arm:~/src/mesa/mesa-demos-8.3.0/src/xdemos$ DISPLAY=:0 LIBGL_DEBUG=verbose ./glxgears
libGL: OpenDriver: trying /usr/lib/dri/vivante_dri.so
drmOpenByBusid: Searching for BusID platform:Vivante GCCore:00
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 4, (OK)
drmOpenByBusid: drmOpenMinor returns 4
drmOpenByBusid: drmGetBusid reports platform:Vivante GCCore:00
748 frames in 5.0 seconds = 149.467 FPS
752 frames in 5.0 seconds = 150.196 FPS
^CProcess termination by interupt!
debian@arm:~/src/mesa/mesa-demos-8.3.0/src/xdemos$   


This patch against mesa-demos-8.3.0 incorporates these various hacks and fixes including one known issue regarding undefined reference to `glWindowPos2iARB'.



Good luck!

Sunday, January 24, 2016

HP Omen i7 Quadcore + Ubuntu 15.10 AMD 64

Finally a new computer, first one in a few years.

HP - OMEN 15.6" Touch-Screen Laptop - Intel Core i7 - 8GB Memory - 256GB Solid State Drive on sale at Best Buy.

How annoying is it, machine is unusable until you activate Windows 8 with a Microsoft registration. No matter, here comes Ubuntu 15.10 AMD 64 ...

Using usb-creator, configured a USB flash drive for installing Ubuntu 15.10 AMD 64 ISO.

On power up hold keys FN-F10-ESC, then F9 accesses "Boot Device Options" ().
  • Select "USB Hard Drive (UEFI) - SanDisk Cruzer"
  • On the flash disk Ubuntu boot menu, select "Try Ubuntu without installing" (from "Install Ubuntu" it would not consistently boot from the USB)
All 4 USB ports are on the back of the machine which is occasionally annoying. Several tries to get machine booted from USB, and the boot makes a lot of noise about "Nouveau PIBUS 0xbadf1100" on startup console which seem to hang the machine. When the machine finally booted it locked up several times for no apparent reason and had to be forcibly rebooted. Doesn't seem to be any consistency to this so I suspect (and hope) merely a quirk related to the USB bootable system.

Hang in there and eventually the thing gets booted - waited to plug in HP supplied USB-Ethernet adapter until the machine successfully made all the way to the desktop. Finally, select "Auto Ethernet" from the connections menu (interface is reported by ifconfig as enx0050b67d3ecc).


As far as for configuring the AC 7260 WiFi ... this doesn't seem to work until only after making the modification to modules configuration as shown below (so after OS install this can certainly be fixed,  but use of WiFi during install from Ubuntu 15.10 environment booted from USB stick may be possible by rmmod'ing acer_wmi and related modules and re-configuring the wlo1 interface).


Selected "Download updates while installing".
Did not select "Install the third party software".



Not my screen shot here but as I recall the default partitioning of the 256 Gb SSD drive left about 120 Gb available for a Ubuntu partition - and presumably I won't have problem erasing Windows and re-partitioning and reclaiming 100 or so Gb of SSD. As unpacked out of the box, there is a Windows 8.1 un-activated install - selecting option to Install alongside; subsequent (re)installation attempts do not encounter this dialog but rather the following one (Installation type)  ...


"Installation type" ... "Erase Ubuntu 15.10 and reinstall"


With the following added to /etc/modprobe.d/blacklist.conf, AC 7260 WiFi is working on wlo1 :

blacklist acer_wmi

(Edit: In the live CD environment, rmmod acer_wmi to unload the kernel modules, then restart networking with the command service network-manager restart).

After a bumpy start installing Ubuntu 15.10, once the install process is done it only takes a few seconds to boot the machine. On sporadic occasions the machine fails to boot and returns to the BIOS boot manager a few seconds after attempting Linux boot from the GRUB menu.

One final observation is that on power up the machine always stops at Boot Manager requiring the manual selection of "OS boot Manager (UEFI) - ubuntu (SanDisk SD6PP4M-256G-1006)".

Update: after significant frustration with erratic system hangs, and also reverting to Xubuntu 14.04 in the process, I did some webbing for laptop-suspend problems and got the impression those problems were often related to display drivers. Searching the device "NVIDIA Corporation Device 139b" as reported by lspci yielded some helpful info and having upgraded the video driver from the xorg-edgers ppa the (resume from) suspend seems to work.

Saturday, January 9, 2016

Debian on i.MX6q with GL/GLES

Update notes from previous post - install root file system on i.MX6 from Debian jessie distro and configure GL/GLES. Other people got this working a while before I did so it's mostly a matter of putting all various notes in order. To begin with, keeping links to a few references handy, some resources require registration on Freescale website (as of about 12/2015 will need to update links to NXP domain).

Setup root filesystem

This is for system boot from SD card - with the card already prepped i.e. partitioned, bootloader intsalled, ext4 fs, and mounted e.g. /dev/sda. A suitable debootstrap command to install base Debian root filesystem onto SD card might be:

sudo debootstrap jessie  /media/sda1

On the SabreSD board, I have upgraded to kernel imx_3.14.38_6qp_ga (link to source snapshot tarballs) ... this kernel provides Galcore version 5.0.11. To configure the kernel, I start with 'make imx_v7_defconfig', then make the following additions to .config:

 CONFIG_DRM=m
 CONFIG_DRM_VIVANTE=m

 CONFIG_FHANDLE=y
 CONFIG_EXPORTFS=y
 CONFIG_DEBUG_LL=y
 CONFIG_DEBUG_IMX6Q_UART=y
 CONFIG_EARLY_PRINTK=y

 CONFIG_USB_SERIAL_PL2303=m  # a Prolific USB serial port I'm using

Finish kernel installation to rfs:
 cp arch/arm/boot/zImage  arch/arm/boot/dts/imx6q-sabresd.dtb  /boot/
 echo vivante >> /mnt/sda/etc/modules

Install udev rules configuration file for imx (allow group access to /dev/galcore):
 cp 10.imx-rules /etc/udev/rules.d

Reboot, confirm modules loaded (vivante, drm):
dmesg  | grep Galcore
[    2.421028] Galcore version 5.0.11.33433
ls -l /dev/galcore 
 crw-rw---- 1 root video 199, 0 May 12 21:48 /dev/galcore

I built patched .deb packages for libdrm, mesa, xorg-server to incorporate a critical patch from Freescale for the i.MX6. The idea is that only the packages affected by xfor86drm.h are locally built, and the rest installed from Debian distribution as normal. (Run grep across sources of libdrm, mesa, and xorg-server to see affected files). I'm sure there are more elegant strategies to finesse the local built packages onto the system, but here is a series of commands below demonstrate one attempt to install distribution packages along with local built .debs in the right order to meet package dependencies.  Note -provide simple compile link test for DRM_CAS  defined for arm in running system as well as build environments). Also note latest versions, at this time running X.org X Server 1.16.4 - which seems to work perfectly well without any noticeable incompatibilies (refer to comments regarding Vivante EXA driver below and ignore any instructions on my old blogs to pin the distribution to any previous iteration of snapshot.debian.org).

Create entries in /etc/apt/preferences.d to make apt respect locally built/installed packages e.g. essentially enumerating all the local  debuilded .deb packages:

sabrehd@sabresd:~$ find /etc/apt/preferences.d/
/etc/apt/preferences.d/
/etc/apt/preferences.d/libdrm
/etc/apt/preferences.d/xorg-server
/etc/apt/preferences.d/mesa

Versions of local packages built installed with dpkg and packages apt-getted are all as downloaded  from http://ftp.us.debian.org/debian at the time this system was built and indicated in commands below. To being with, all can be installed from libdrm even though the drm drivers installed have nothing to do with the arm architecture but are harmless and still needed by other modules on the sytem anyway ... dpkg -i `ls libdrm/*\.deb` is of course one way to do it or you could try:

 dpkg -i ./libdrm-freedreno1_2.4.58-2_armhf.deb  libdrm-nouveau2_2.4.58-2_armhf.deb  libdrm-radeon1_2.4.58-2_armhf.deb  libdrm2_2.4.58-2_armhf.deb

At the end there should be a nice xfce4 desktop (a little script might be nice here):

 apt-get  install libllvm3.5  libexpat1 libelf1

 dpkg -i  mesa/libgl1-mesa-dri_10.3.2-1+deb8u1_armhf.deb

 apt-get   install x11-common   libxaw7 libxkbfile1 libxt6 libepoxy0 libpciaccess0 libpixman-1-0 libxfont1 libxshmfence1    xkb-data x11-xkb-utils

 dpkg -i xorg-server/xserver-common_1.16.4-1_all.deb

 apt-get  install keyboard-configuration libx11-xcb1 libxcb-dri2-0 libxcb-dri3-0 libxcb-glx0 libxcb-present0 libxcb-sync1 libxdamage1 libxfixes3 libxxf86vm1   libxcb-render0 libxcb-shape0 libxcb-xfixes0   libwayland-client0 libwayland-server0

 dpkg -i mesa/libglapi-mesa_10.3.2-1+deb8u1_armhf.deb
 dpkg -i mesa/libgbm1_10.3.2-1+deb8u1_armhf.deb
 dpkg -i mesa/libgl1-mesa-glx_10.3.2-1+deb8u1_armhf.deb
 dpkg -i mesa/libegl1-mesa_10.3.2-1+deb8u1_armhf.deb
 dpkg -i ./xorg-server/xserver-xorg-core_1.16.4-1_armhf.deb

 apt-get install  xserver-xorg-video-fbdev xserver-xorg xinit
 apt-get install xfce4

It should be possible to startx at this point. However there are more dev packages to be installed as  the EXA driver for Vivante GPU is also going to be native-built on this system farther below - it's not necessary to native build it (I just don't bother setting up cross-tools), but it must be built I think against the version of X.org release intending to run on the rfs.

 apt-get install libpixman-1-dev x11proto-core-dev x11proto-input-dev x11proto-xext-dev x11proto-video-dev x11proto-randr-dev  x11proto-render-dev x11proto-dri2-dev  x11proto-gl-dev

 apt-get install  x11proto-fonts-dev x11proto-xinerama-dev  x11proto-kb-dev x11proto-xf86dri-dev x11proto-resource-dev x11proto-scrnsaver-dev  x11proto-xf86bigfont-dev  x11proto-dri3-dev x11proto-present-dev

 apt-get install libxkbfile-dev libpciaccess-dev

 dpkg -i ./mesa/mesa-common-dev_10.3.2-1+deb8u1_armhf.deb
 dpkg -i xorg-server/xserver-xorg-dev_1.16.4-1_armhf.deb

Here is the origin of most of the complexity of this system! Note the locations of packages to installed from the FSL Community BSP which can also slightly more conveniently be download directly from yocto project:

http://downloads.yoctoproject.org/mirror/sources/
http://downloads.yoctoproject.org/mirror/sources/xserver-xorg-video-imx-viv-5.0.11.p7.1.tar.gz
http://downloads.yoctoproject.org/mirror/sources/imx-gpu-viv-5.0.11.p7.1-hfp.bin

xserver-xorg-video-imx-viv is source code of Vivante EXA driver (build steps to follow in sections below). imx-gpu-viv is Freescale's implementation of GL/GLES associated runtime libraries and development headers and more or less takes the place of any existing libdrm and mesa implementations on the system - therefore it is likely that installed versions of some of these libs and header files are already on the system. Note that Debian the package management system already installs libGL* and friends to /usr/lib/arm-linux-gnueabihf/, while imx-gpu-viv will wind up in base of /usr/lib which as higher search precedence with ldconfig (the distro versions are not removed).

I used tar to create an archive of imx-gpu-viv-5.0.11.p7.1-hfp/gpu-core/usr/ and to extract the contents over the /usr/ filesystem e.g. resulting in /usr/lib/libGL.so etc. The updated header files are found in /usr/include/GL (should not have any mesa dev packages installed from the distro).

Explanation for the sym-linking scheme, which is done as a way to switch between X11, Wayland or framebuffer versions of the libraries, seems to have been dropped from recent versions of the documentation (i.MX 6Dual/6Quad Linux Reference Manual, Rev. L3.0.35_4.1.0 page 81) but most people in i.MX6 land seem to already be aware of it by now.

On X11 systems, the symbolic links to these libraries need to be redirected. This can be
done using the following sequence of commands:

> cd /usr/lib
> sudo ln -s libGAL-x11.so libGAL.so
> sudo ln -s libEGL-x11.so libEGL.so
> sudo ln -s libEGL-x11.so libEGL.so.1
> sudo ln -s libVIVANTE-x11.so libVIVANTE.so

On directFB backend, the symbolic links to these libraries need to be redirected. This can
be done using the following sequence of commands:

> cd /usr/lib
> sudo ln -s libGAL-dfb.so libGAL.so
> sudo ln -s libEGL-dfb.so libEGL.so
> sudo ln -s libEGL-dfb.so libEGL.so.1
> sudo ln -s libVIVANTE-dfb.so libVIVANTE.so

Note dpkg apt and company have an annoying habit of completing package installs with an invocation of ldconfig which clobbers the links ("sbin/ldconfig.real: /usr/lib/libOpenVG.so is not a symbolic link").

By changing the sim links it should be possible to run some demos on the framebuffer display (imx-gpu-viv-5.0.11.p7.1-hfp/gpu-demos/opt/viv_samples/vdk/) . It is in fact possible to run these in a chroot environment - be sure to use mount -o bind to setup /dev /proc etc. and also, permission 660 on /dev/galcore as mentioned previously allows non-root access to device for owning group (video).

xserver-xorg-video-imx-viv provides the Vivante EXA driver as source code - it must be built against the version of X.org release intending to run on the rfs, and in addition depends on Freescsale's version of libraries and system headers from imx-gpu-viv-5.0.11.p7.1-hfp.bin. The following compile line should work and some additional notes may be useful for troubleshooting problems:

./fastbuild.sh  XSERVER_GREATER_THAN_13=1 BUILD_HARD_VFP=1 BUSID_HAS_NUMBER=1

So what could go wrong?

No such file or directory #include "xorg-server.h" ... this is fixed by installing xserver-xorg-dev (installed from local built .deb) ... note this and other references may need to be modified to #include "xorg/xorg-server.h".

One compile problem that may be encountered in  xserver-xorg-video-imx-viv-5.0.11.p7.1.tar.gz is path to drm.h ... easily corrected in EXA/src/makefile.linux i.e. /usr/include/libdrm/drm.h

Previous versions of xserver-xorg-video-imx tended to have many more compile problems when built against newer versions of X.org, e.g. as shown in the notes below in case the information is useful to anybody. In fact any failures building DRI_1.10.4 can probably be ignored, as this is probably by now already provided by X.org server and is no longer distributed with 5.0.11 series (fastbuild may still try to build it and errors out).

gcc -mfpu=vfp -mfloat-abi=hard -fvisibility=hidden -fPIC -DPIC -I. -I.. -I//usr/include -I//usr/include/xorg -I//usr/include/pixman-1 -I../../EXA/src/vivante_gal -march=armv7-a -marm -o dri.o -c dri.c
dri.c:42:18: fatal error: xf86.h: No such file or directory
 #include "xf86.h"
(Also may need to be changed to "xorg/xf86.h")

makefile.linux:71: recipe for target 'dri.o' failed

DRI_1.10.4/src/drm.h
                 from dri.c:52:
./drm.h:620:26: fatal error: drm/drm_mode.h: No such file or directory


If you got through all that then finally, install the driver, configure X.org server:

 cp src/xserver-xorg-video-imx-viv-3.10.31-1.1.0-beta/EXA/src/vivante_drv.so  /usr/lib/xorg/modules/drivers/
 cp Download/sys/xorg.conf  /usr/share/X11/xorg.conf.d/

... and then hopefully enjoy a successful startx moment:
$ grep VIVANTE:  /var/log/Xorg.0.log
[   188.626] (II) VIVANTE: driver for vivante fb: VivanteGC500, VivanteGC2100,
sabrehd@sabresd:~/Downloads$ 


For bonus points, debuild and install mesa-utils and maybe at least one prerequisite:
sudo dpkg -i mesa/libgles2-mesa_10.3.2-1+deb8u1_armhf.deb
sudo dpkg -i mesa-utils/mesa-utils-extra_8.2.0-1_armhf.deb

Enjoy!