2013-05-05

RetroArch on ODROID-U2, revisited

After my previous blog post I am considering creating a stand-alone, auto-updating modified Linaro image for RetroArch on ODROID-U2, but don't hold your breath for this now :)


Tip: listen to this great song while reading and hacking your ODROID+RetroArch setup

Update 7 May 2013: I released neagix' excellent (and unofficial) Debian Wheezy for Development&Emulation (with X11 hardware acceleration), get it while it's hot!

Some general advices for people approaching console emulation on ODROID-U2:
  • there is currently no known way to natively exploit the ODROID framebuffer (Exynos 4), thus we have to go through Xorg to run any emulator
  • composing desktop environments are bad for you, so no Unity/Compiz/you-name-it, use instead LXDE or XFCE
  • I have experienced kernel panic/oops/alignment trap issues when using my own compiled version of the kernel, thus I advice to stick to kernel 3.0.63 for now (this has proven to be stable so far) issue was due to PSU
  • remove xscreensaver and other screensaver packages, then modify xorg.conf to not automatically turn off DPMS and other screen blank settings
  • RetroArch runs fine with GL video driver and SDL input
  • be kind with your MCC/SD support, it's not like a regular hard disk and wearout factor is present. Nothing to be scared of, but consider moving write-often directories to external mountpoints
  • create a backup script and run it regularly. You don't know when, but your SD/MMC will one day wake up and tell you "So long, thanks for all the fish..."
  • use nobootwait in your fstab mountpoints, and if you are using NFS mountpoints specify an option for short timeout, like timeo=5
  • disable the long timeouts in /etc/init/failsafe.conf, and feel free to comment lines 34-35
  • if you are using lxdm as login manager, consider enabling autologin by uncommenting autologin=username in /etc/lxdm/lxdm.conf (username shall be your actual username)
  • if you are using LXDE, edit/create ~/.config/lxsession/LXDE/autostart and add a single line @retroarch (retroarch binary must be in your $PATH for this to work), this way once you boot ODROID you will be presented with retroarch
Suggested settings block for  ~/.retroarch.cfg:

video_driver = "gl"
video_fullscreen = "true"
video_windowed_fullscreen = "true"
video_aspect_ratio = "1.33333333333333"
audio_enable = "true"
audio_driver = "alsa"
audio_sync = "true"
input_driver = "sdl"
input_joypad_driver = "sdl"


Please note that only the first definition in the configuration file will be read, so I advise to remove duplicate definitions to reduce confusion.

Some patches for RetroArch

After my unsuccessful attempts at contributing RetroArch I've decided to publish these patches in my retroarch fork, hopefully they will be useful by people affected by my same problems.
Issue: when using RGUI and loading a saved state the button release is passed to the underlying core, causing all weird undesired actions

Fix: wait for all input to be released before starting the core, commit patch here

Issue: rather difficult to troubleshoot input issues might be related to wrong joystick configuration, that is also difficult to detect without a jstest-like program

Fix: enable logging of input events directly in retroarch, commit patch here
Feature: halt the system from RetroArch menu, commit patch here

Leaderitis acutis in open source

Leaderitis acutis

In the last days I wanted to contribute to an open source project with some feedback and bugfix/enhancement patches. Although I fully recognize my non-excellent C++ skills, I found the project to be affected by one of the most common diseases in the FOSS world: leaderitis acutis.

This is a purely fictional disease that I just invented and that I have been thinking about recently (I later found out it's used in american politics jargon, although I don't know how closely matches by what I describe here).

I have always been interested in open source philosophy (and also in free software to a lesser extent), thus I always find it appalling deludent when open source projects do not meet the essential expectations (that is very often for the smaller projects around these days).

Symptoms

  1. Project has very few developers and it has not been exposed to the beneficial strength of the "many eyes"
  2. The most prominent developers use the project to foster all their favourite code smells and anti-patterns (lack of comments, cryptic/mangled code, Baklava code, you-name-it)
  3. Issues, patches and any feedback is negatively considered as a critic or even as an offence (although this might have roots deep into cursed developers' personality)
    Sketch by 3-3 studios
  4. The attitude towards any form of feedback that is not a plain compliment is "Sheesh! This is my little precious, you won't touch it!", missing the point that open source is not your own thing, not even when you start it or are the main contributor
  5. As a last resort solution to any civil and logic argument, developers/mantainers will assert that you have no right to express your opinion, or that your opinion is not supposed to be worth anything in first place. To justify this assertion and enforce the paradigm that they should be trusted as superior, God-gifted owners of truth, they will either:
  • specify that your total contributions amount to 0% and their contributions to 99%, cheerfully living in a chicken-and-egg paradox (or simply barring entry to potential contributors to mantain their sphere of influence untouched)
  • possibly try with any form of personal attack like "you make mistakes, thus your opinions are not trustable".

Cure

There is no known cure for leaderitis acutis, although progress has been verified with personal growth of the involved developers and mantainers that generally happens when time tells them that open source is not about going solo/berserk.

2013-04-15

RetroArch on ODROID-U2 (with hardware acceleration, yes!)

ODROID-U2

I have tried to run decent console emulation on Raspberry Pi, without success.

So I recently got my hands on an ODROID-U2 (that comes with a respectable more powerful hardware) and that can potentially carry out my console emulation and preservation dreams.

In the below pictures you can see it shily coming out of the box:

A small package to rule them all

Better use a fan if you want to overclock this little beast!


















This development board comes with 4 ARM Cortex A9 CPUs and the Mali 400 GPU (more about this later); when choosing a development board you should really pay attention to the planned shelf life, the expected community size and the GPU driver support. There's really nothing else that will matter more for you than the open source/closed source drivers.

In these regards the vendor, Hardkernel, gets my kudos as I see they are working hard to deliver the best to the community that's aggregating around ODROID (but keep in mind that it's not yet very big right now, so weaponize yourself for all cases!).

As far as I understood the driver is partly closed-source, for longer term dreams (full open source Mali400 driver) you could check out the Lima project, although nothing usable is available at time of writing.

I was expecting some geeky adventures to achieve my goal, and I wasn't disappointed. In the last few days I had to learn all my way through forums, IRC, blog posts and generally fragmented and incomplete information - but finally after a few strong machete cuts I have been able to see the light!

Do-it-yourself

I didn't want to release the result of my efforts as Debian packages or complete SD images (update: I did!), so I will provide you with a walkthrough and the necessary steps.
The reasons are:
  • possible licensing concerns, it is not fully clear to me if I am entitled to release these (for example the vendor-provided drivers);
  • releasing concerns, once you release something you should take care to mantain it;
  • philosophy: if you are using a development board you should really get in touch with all the layers to better understand how things work.

I used this blog post as starting point and also other resources here and there; in this blog post I am focusing only on SD card booting and ODROID-U2 specifically.
Although I didn't follow it originally, you might also want to read the official post about ODROID-U2 and then come back for the other steps about Xorg configuration and RetroArch.

Update 7 May 2013: I released neagix' excellent (and unofficial) Debian Wheezy for Development&Emulation (with X11 hardware acceleration). I advise to use the image as information in this post might be obsolete.

Prerequisites

In the following steps I aim to provide an aid at getting a fully functional RetroArch on ODROID-U2.

If you can use debian apt-get/aptitude and SSH you should be able to follow it. Also you might want to use Google in case of some strange error that is not covered by this tutorial.

This is not a from-scratch tutorial for complete newbies, so please don't expect so.

Update 25-April-2013: the more advanced cores will not exhibit a great performance, but you should be fine with emulation of 16bit (and less) consoles

Step 1 - booting the device


Insert the microSD in a Linux PC, then check with dmesg|tail what is the dev node. On my PC it was /dev/mmcblk0. Please take note of the root device, not the partition device (that would be /dev/mmcblk0p1 and so on).

Now download a prepared ODROID-U2 Ubuntu image and flash it to the microSD card.


wget http://www.mdrjr.net/odroid/mirror/ODROID-U2/Ubuntu/odroidu2_20121231-linaro-ubuntu-desktop-uSD.zip
7z x odroidu2_20121231-linaro-ubuntu-desktop-uSD.zip
sudo dd if=odroidu2_20121231-linaro-ubuntu-desktop-uSD.img of=/dev/mmcblk0 bs=24M

Update 14 July 2013: use instead the odroid-wheezy-retro image, instructions here

At this point I advice to eject/insert the microSD card, then run the following:

sudo resize2fs /dev/mmcblk0p2

This will resize the linux partition to the maximum available space on your SD card.

Before proceeding to next step you might want to mount the /dev/mmcblk0p2 partition and change some files there for easier initial setup (like wired network, for example).

And now...ready for the show! Put the SD card back in the ODROID device and boot your device.

Step 2 - First boot operations

The first time you boot you should connect through SSH to your device, default users have the following usernames/passwords:

root / root
user / user

As first operation change those passwords, and possibly you might want to use usermod to rename 'user' to something else.

After that re-generate the SSH keys:

sudo rm /etc/ssh/*_key /etc/ssh/*.pub
sudo dpkg-reconfigure openssh-server

Modify /etc/rc.local by adding these lines before the last exit 0 line (reported for reference):

cpufreq-set -g ondemand -d 200Mhz
chown .video /dev/ump
chown .video /dev/mali
chmod 0660 /dev/ump
chmod 0660 /dev/mali


Install now cpufrequtils package if you are not going to do Step 3.

Also make sure that your user is in the following groups:
user adm cdrom sudo audio dip video plugdev lpadmin pulse

Step 3 - Trimming down the installation (optional)

In this optional step (that is also untested!) I explain how to remove a lot of packages that come by default installed with Linaro Ubuntu, you can skip it if you prefer to customize it by yourself.

Download odroid-u2-slim-package-selections.txt and then restore the selections by running:

sudo apt-get install dselect
sudo dpkg --clear-selections
sudo dpkg --set-selections < odroid-u2-slim-package-selections.txt
sudo apt-get -y update
sudo apt-get dselect-upgrade

A lot of packages will be removed and you should get XFCE installed in place of Unity (although I advise using LXDE).

When you have finished, please run:

sudo dpkg-reconfigure -a

To go through all necessary configuration steps.

Please note that the display manager will also not work! So don't expect any output on HDMI yet. Real men/women use terminal ;)

Step 4 - Getting the bare metal hardware (acceleration)!

It is necessary to update the kernel to use proper Mali400 hardware-accelerated GPU drivers.

We will use the 13th February release:

wget http://dn.odroid.com/Ubuntu_U2/20130213/linux-3.0.63-odroidu2_20130213.tar.gz
tar xvfz linux-3.0.63-odroidu2_20130213.tar.gz
cd linux-3.0.63-odroidu2_20130213
rm fstab
sudo ./install.sh


At this point a reboot is necessary to make the new kernel effective, I will ask you for such reboot at a later step.

Now we will install the vendor-provided mali400 drivers:

wget http://dn.odroid.com/MALI400_R3P2/20130222/mali_packages.tar.gz
tar xvfz mali_packages.tar.gz
cd mali_packages
sudo dpkg -i mali400_2.1-13_armhf.deb mali400-dev_2.1-13_armhf.deb xf86-video-mali_1.0.1-7_armhf.deb
sudo rm -rf /usr/lib/arm-linux-gnueabihf/mesa-egl /usr/share/X11/xorg.conf.d/99-hkl_mali.conf


Please note that we are removing 2 objects here:
  • mesa-egl, because would prevent you from getting the Mali EGL acceleration
  • 99-hkl_mali.conf, that is the default Mali configuration and consitutes just a source of confusion (it always overrides your xorg.conf)

Step 5 - Build your own xf86-video-mali (optional)

This step is optional e.g. you don't need it, I am keeping it here for reference.
Install xorg-dev, xutils-dev, automake, autoconf and libtool, then download the sources from ARM website (I've used release of 11 March 2013 called Linux EXA/DRI2 and X11 Display Drivers r3p2-01rel1), then enter the proper directory and run the following script build.sh:

#!/bin/bash
set -e
ODFLAGS="-DUMP_LOCK_ENABLED=1 -mfpu=neon -mfloat-abi=hard"

autoreconf -rfi
CFLAGS="$ODFLAGS" ./configure --prefix=/usr
CFLAGS="$ODFLAGS" ASFLAGS="-mfpu=neon -mfloat-abi=hard" make -j5

This will quickly deliver an usable xf86-video-mali that you can use in conjunction with the mali400 driver package from step 4.

NOTE: on some older versions of autoconf you can only do autoconf -fi

Step 6 - Starting XFCE4

If you have not before, reconfigure X11 to allow any user:

sudo dpkg reconfigure x11-common

Make sure that "Anybody" is selected and save.

Now let's setup /etc/X11/xorg.conf:

Section "Device"
        Identifier "Mali-Fbdev"
        Driver  "mali"
        Option  "fbdev"           "/dev/fb6"
        Option  "DRI2"            "true"

        Option  "DRI2_PAGE_FLIP"  "false"
        Option  "DRI2_WAIT_VSYNC" "false"

        Option  "UMP_CACHED"      "true"
        Option  "UMP_LOCK"        "false"
EndSection

Section "Screen"
        Identifier   "Mali-Screen"
        Device       "Mali-Fbdev"

EndSection

Section "DRI"
        Mode 0666
EndSection


Please note the DRI2_PAGE_FLIP setting above, set to disabled. If you enable it your applications performance will start to thrash after a couple of minutes. For example RetroArch had a constantly falling down FPS because of this. I have also experienced instant crashes (SEGFAULT) with fullscreen applications using it.
Update 13 July 2013: The segfault was due to using the setting "DefaultDepth 16", and DRI2_PAGE_FLIP does no more show a negative behaviour, actually a positive one - so feel free to enable it. VSYNC can be enabled but it's not effective, see also this post

Update 05 May 2013: I have provided with a more recent version of xorg.conf here in this post, that adds only turning off DPMS

Now we're ready again. Reboot the system (and check that you are running kernel 3.0.63 through uname -a), then run:

startxfce4

XFCE4 will display in all its glory. Your Xorg.0.log will contain:

(EE) AIGLX error: dlopen of /usr/lib/arm-linux-gnueabihf/dri/Mali DRI2_dri.so failed (/usr/lib/arm-linux-gnueabihf/dri/Mali DRI2_dri.so: cannot open shared object file: No such file or directory)
(EE) AIGLX: reverting to software rendering
(II) AIGLX: Screen 0 is not DRI capable
(II) AIGLX: Loaded and initialized swrast
(II) GLX: Initialized DRISWRAST GL provider for screen 0

You can completely disregard the above as hardware acceleration will instead work, and we are now going to verify it.

Bit depth

By specifying a DefaultDepth of 24 you will get a segfault right after the GET_UMP_SECURE_ID_BUF1 line in the log.

Update 18 April 2013: libv has personally sent a patch to mdrjr so that HDMI output up to 32bit will be supported, stay tuned! :)
Update 21 April 2013: by recompiling the 3.0 kernel (provided by Hardkernel) with CONFIG_VIDEO_EXYNOS_24_FORCE=y you can use HDMI in 24 bit mode, many thanks to libv for the patch

Step 7 - Rotating horses and crates!

Now it's time to see hardware acceleration in action.

You can use 3 programs to check the status of hadware acceleration on your ODROID:
  • glxgears, a classic tool to test GLX
  • es2gears, for ES2 testing
  • glmark2-es2, that is actually a benchmark and you will score 92 if everything went right
If your hardware acceleration is enabled you will see FPS above 100 in all of them (although not in all glmark2-es2 tests).

If you verify hardware acceleration to be working, feel free to continue to step 7.

Step 8 - Time for RetroArch

Unfortunately I have not been able to use KMS with Mali 400, I think it's not supported, but I managed to use RetroArch in accelerated X11.

Let's download and compile RetroArch:

git clone https://github.com/Themaister/RetroArch.git
mv RetroArch retroarch 
cd retroarch
CFLAGS="-mfpu=neon -mfloat-abi=hard" ./configure --enable-x11 --enable-gles --enable-alsa --disable-oss --disable-jack --disable-pulse --disable-kms --disable-vg
ASFLAGS="-mfpu=neon -mfloat-abi=hard" make -j5


If you get gcc errors about virtual memory exhausted or other weird corruptions, try to set the governor to userspace for the length of compilation operations.

At this point you should have a compiled retroarch binary, we are ready for Step 8.

NOTE: I have only a small patch, you might want to use it in you have an error there (compiling with VG support):
diff --git a/gfx/vg.c b/gfx/vg.c
index c5b92e0..bbfc3a8 100644
--- a/gfx/vg.c
+++ b/gfx/vg.c
@@ -99,7 +99,7 @@ static void *vg_init(const video_info_t *video, const input_driver_t **input, vo
    RARCH_LOG("Detecting screen resolution %ux%u.\n", vg->mScreenWidth, vg->mScreenHeight);

    vg->driver->swap_interval(video->vsync ? 1 : 0);
-   vg->driver->update_window_title(true);
+   vg->driver->update_window_title();

    vg->mTexType = video->rgb32 ? VG_sXRGB_8888 : VG_sRGB_565;
    vg->mKeepAspect = video->force_aspect;
@@ -387,7 +387,7 @@ static bool vg_frame(void *data, const void *frame, unsigned width, unsigned hei
    if (msg && vg->mFontsOn)
       vg_draw_message(vg, msg);

-   vg->driver->update_window_title(false);
+   vg->driver->update_window_title();

    RARCH_PERFORMANCE_STOP(vg_fr);
    vg->driver->swap_buffers();


Step 9 - We need a core


RetroArch cannot do anything if you have no cores. Let's build snes9x-next.

git clone https://github.com/libretro/snes9x-next.git
cd snes9x-next
mv snes9x-next libretro-snes9x-next
make -j5 -f Makefile.libretro


Now you will have snes9x_next_libretro.so, take note of the path to this file by copying the output of:

ls $PWD/snes9x_next_libretro.so

Now let's go back into retroarch's working directory and run RetroArch:

DISPLAY=:0 ./retroarch -L /your/complete/path/snes9x_next_libretro.so SNES9X\ Demo\ V1.16\ \(PD\).smc

If you are typing this into an XFCE terminal, then you can omit the DISPLAY=:0 part.

Now you should see the ROM being emulated with FPS count on the window title bar.
You can install the other cores manually (one by one) or by using the libretro-super scripts.

Step 10 - Packing up together


It is advised to use different CPU settings when running retroarch; for this reason I use a script similar to this snes9x.sh:

#!/bin/bash
sudo cpufreq-set -g ondemand --min 1.6Ghz
DISPLAY=:0 ./retroarch -L /your/complete/path/snes9x_next_libretro.so $@
sudo cpufreq-set -g ondemand --min 200Mhz

This script will effectively change the minimum frequency when you are using RetroArch, and then restore it back when you exit (unless you use Ctrl+C, so don't!).

You can even use a higher minimum frequency if you experience slowdowns, however please pay attention that a fan might be needed when overclocking! Please refer to official ODROID information regarding this.

Step 11

SNES9X Demo ROM (Public Domain)

Enjoy it! :)

Conclusions


I think that ODROID-U2 has a lot of potential, I plan to do other interesting things in future with this development board.

Please let me know your feedback if there are errors or possibility of improvements by using the official ODROID forums discussion thread.

2013-03-29

Monodevelop rules!

I recently gave another look at Monodevelop. Wow. Just wow. A lot of progress has been done since last time I tried it.

Look at it, in all its XFCE glory:
Elegant and well-designed


And there is even NuGet support:
 
Look ma! Without hands!

I like the auto-completion even better than Visual Studio. It's a pity the IDE detects LINQ syntax and 'var' as errors, but still I can live with that.

A small edit

A change which I did was to modify /usr/share/liteide/litebuild/gosrc.xml regarding the build working directory, see highlighted part:


Conclusion

I usually don't have these nice words for most of the UIs I use on Linux, so compliments to all contributors and Xamarin for this quality open source product!

2013-02-10

Go-SDL with callback support: done!

It is always fashioning to discover the type of big challenges that can arise from an apparently trivial task, like porting an ncurses game to Go! language. It's like watching the unexpected chessboard developments that can happen between two beginners.

This time I wanted to add support for sound through SDL_Audio, so I came up with a decent square-wave generator and started using this Go-SDL fork for audio output.
Problem: SDL audio works with samples or callbacks, and my samples are generated on the fly, being simple PC-buzzer-like sounds.

Strangely enough, that Go-SDL package I found uses a very complex architecture of mutexes and hard-coded hacks to simulate possibility of sending audio synchronously from Go, and only continuous streaming is supported, no custom samples playing, although the API fingerprint seems like it could support it.

Without continuous playback, my game was condemned to display
ALSA lib pcm.c:7339:(snd_pcm_recover) underrun occurred
 from time to time during gameplay. And that sucks.

The cage of Love where Go
is currently held prisoner without
proper support of C integration
I came in contact with author, and the end of a short discussion I wanted to roll my own version using CGO callbacks, easy done, but then I met this guy:
runtime: cgo callback on thread not created by Go.
runtime: signal received on thread not created by Go.
I digged a bit and found out the reason behind it, basically Go language is not (yet) that well-integrated with C language.
However, thanks to Roger Peppe's callback package it is possible to use C callbacks in Go, like Gordon K. did for PortAudio. It is a hack, but a nice one.
At this point I was going to use PortAudio because it already uses that callback package, but PortAudio has an extra "feature": incredible garbage in the console terminal, and that was not going to be bearable for my little ncurses game.

So I armed my fingers and started coding a fix, here's the result:
https://github.com/neagix/Go-SDL
I removed most mutexes and synchronization black magic and I am now using a single synchronous channel for samples mixing, and it has also support of custom sound-generation callbacks. The cherry on top is that it comes with a nice PC-speaker buzz sound simulator, for all you nostalgic BEEP guys :)

Talk about how much you can learn with a such a simple game :)

At the end of this coding adventure I have to agree with Otstol that it is a huge limitation (to usage&adoption) that Go! language does not sport better callbacks support. I am quite sure all these fireworks will soon be obsolete because the Go Authors will fix this ;)

* = the game in question is Langwar, my battering ram used to discover the Go! language and also bring back what I recognize with some nostalgia as a classic game useful for learning programming

Update 16 June 2013: thanks to G. Klaus for letting me know about Go having fixed the issue, I have now updated my fork of Go-SDL

2013-02-03

The sorry status of Go! IDEs

It is indeed the IDE which makes a developer feel powerful or powerless in front of common modern development challenges; I have used the most common IDEs, amongst the best I recall Visual Studio 6, Borland Delphi and NetBeans, that I still use nowadays.

In my recent adventure at using Go! language to port a simple game, I've found that Go! does not (yet) have an IDE made with love and care for the language.

I've tried Go-IDE (horrible MDI, will reopen the same file and cause crosswrites), NetBeans with the (in)famous plugin (IDE will not search into .go extension files, no Ctrl+click support, no nothing, just syntax highlighting) and then reverted back to my good old Geany.

 
Actually I've found that with the changes explained here:

http://go-lang.cat-v.org/text-editors/geany/

It becomes a really good deal. Now back to coding ;)

Update 29 March: I found what I was looking for, golangide, awesome! :)