ODROID forum members Monthly Award of June

Yesterday I have received news that my project has won the ODROID community Project Monthly Award! Yuppiee!!

One more reason to party :)

Many thanks again to mdrjr and Lisa from Hardkernel for this awesome award - this is really one of the best forum communities I have ever partecipated in. 

I always start trying to make something cool with Gimp, then I end up with some awkward graphics like this. Fair enough, I can't do better anyway :)

This means an extra U2 to play with :) However, I have already 2 and I am not greedy, so I started thinking what it would be the natural usage of such great dev board...

Got any idea?

RetroArch! I quickly decided to have the RetroArch project, in the person of Squarepusher, receive this hardware as a gift for the best of both our growing communities. I see potential for the combination ODROID+RetroArch and on the U2 RetroArch truly shines as a comet of power and great features (like the RGUI).

See how poetic and generous I become when I think about my beloved U2 and retro gaming? :)

More to see on this channel...

My commitment to ODROID community and RetroArch will now be even more motivated. I keep taking care of these releases and news because, as I said in the beginning, I would like to see a skilled development community grow up around these great hardware/software projects.

I have plans for better integrated releases and also tighter testing/development support of RetroArch cores..keep tuned and/or join the efforts if you feel the challenge :)

Duke Nukem 3D on ODROID

Chocolate Duke Nukem 3D: a sad story

I am a Duke Nukem 3D aficionado and I've recently read with interest Fabien Sanglard's review of Duke Nukem 3D source code. As he writes, the original source code was really horrible.

The Duke on his glorious cover - 3D Realms page here

Fabien also started a Chocolate port, so I grabbed it to try to run the Duke glories on ODROID/Linux.

I realized - in disappointment - that this was a quick hack to have it running on Mac, not a proper chocolate port.
Furthermore the provided Visual Studio solution files were referring to some previous version of the project, with non-matching paths and broken includes - making it also not possible to build it on Windows (this portable is not, my young padawan).

During my own quest to have it building properly on Linux I decided to use Canassa's patches, since they seemed to be done in the reasonable framework of a chocolate port, and then I wrote my own Linux makefiles because Canassa is apparently also a Mac user - thus no Linux portability efforts were added at any time.

My chocolate improvements

In my fork I have added proper CMake support, grab it here: Chocolate Duke Nukem 3D with Linux compile support

However the status of this codebase is almost hopeless:

• will not work on anything else than 32bit systems
• some glitch when player dies
• the 3D Realms logo has some palette quirk, doesn't look like it used to be

Me unhappy :(


If you try to run it on a 64bit system you get only the initial animation, then it goes on "Segmentation fault". That's kind of expected, given the waterfall of integer-to-pointer and pointer-to-integer warnings shown during compilation.

Next step: eduke32

I didn't start from this more advanced port because I wanted to use a faithful version of Duke Nukem 3D, however I am now pleased to see that customization of the built eduke32 is possible to an extent that most advanced features can be turned off.

This is perfect for our ODROID retro-goals! :)

I have done some fixes and prepared a build script, grab them here: eduke32 patch to run on ODROID + optimized build script

Diplomacy is the best feature of this game, as I remember

And enjoy Duke Nukem 3D - it runs flawlessly fast on my U2!

P.S.: I have added the eduke32 binary to release 0.7.3 of odroid-debian-wheezy, or you can download it from here (will only work with Debian Wheezy 7.1 ARM hardfloat)

odroid-wheezy-base (new image) & odroid-wheezy-retro release update

Time for release! A bugfix release for odroid-wheezy-retro and a new image, even smaller! :)

The new base image, odroid-wheezy-base, contains:

• debootstrapped Debian root filesystem
• wired network configured for DHCP
• SSH
• configured serial login on UART
• nothing else!

Download odroid-wheezy-base

This is ideal to setup a Debian server with your ODROID, or to kickstart any other customization project you might have. To name only a few: (web)servers, robotics, domotics, top-boxes, you name it!

Release update for odroid-wheezy-retro

The nasty network issue is solved in 0.7.2:

Download odroid-wheezy-retro 0.7.2 

The wildness of the network issue

Some users have reported network issues, however I was never able to reproduce them. At some point I did, and the nature of this issue manifested itself as a very nasty heisenbug.

On first boot the ethernet MAC address was randomly generated and the SSH keys regenerated; it turns out that some randomly generated MAC addresses would make the ethernet never come up, with an error like:

RTNETLINK answers: Cannot assign requested address
Listening on LPF/eth0/xx:xx:xx:xx:xx:xx
Sending on LPF/eth0/xx:xx:xx:xx:xx:xx
Sending on Socket/fallback
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 7
send_packet: Network is down
receive_packet failed on eth0: Network is down

Correlation is not causation

However, getting to the above conclusion was not easy because last week I observed the following and made wrong correlations:

1. downscaling issue with one of my customized wheezy-retro SD images (no reason yet verified for this issue, although it is specific that SD image)
2. network issue with the dedicated wheezy-retro SD image (this was due to the smsc95xx_mac_addr file), letting me for the first time verify the issue of users
3. found some corrupt (all null bytes) files in the dedicated wheezy-retro SD image

Since file corruption can "taint" everything it touches, I assumed that both the downscaling and network issue were correlated and caused by the first-time observed file corruption.

The lesson is that these issues should instead be considered separate (except 1 and 3 that still need to be verified for correlation), and I have applied mitigation (rsync checksum verification) for (3).

odroid-wheezy-retro 0.7.1 released: now with desktop icons

0.7.1 released

From the ChangeLog:

• added idesk as desktop manager
• added all quicklaunch icons (lxterm, glxgears, es2gears, glmark2-es2, retroarch)
• other minor improvements/fixes
• version bump (to 0.7)

Summary

In this version I am glad to introduce a nice & handy addition: desktop icons!

Looks much better now

Due to the constraints of this image (to be lightweight and development-oriented) I did not want to add any proper desktop environment and I fixed & compiled idesk instead. It draws icons. That's all I wanted for this image.

You can launch straight-ahead from desktop the following:

• LXterminal
• GLX gears demo
• ES2 gears demo
• glmark2-es2 benchmark suite
• RetroArch (with my patches)

Download

IDesk (fluxbox complement) forked

In odroid-debian-wheezy-retro I am using the great fluxbox as a very lightweight window manager. An useful addition would be icons on the desktop to quick-launch applications.

This is one of the screenshots found at original IDesk SourceForge project. Seriously? >.<

My first choice, fbdesk, is unfortunately broken, so I digged around and the available options for a lightweight desktop were rox-desktop and idesk. rox-desktop comes with a whopping 20 dependencies and idesk is outdated (2005).

The problem with adding so many depencies to a development-oriented distro is that it breaks the philosophy and goals behind it. Instead, by using the most lightweight choice (although less functional) you always leave the user the opportunity to easily make a choice and pick their own, and this is important.

I ended up picking up the orphaned codebase, applying a few patches and polishing it for 2013 :)

Here's my fork: https://github.com/neagix/idesk

I will be mantaining it for a while, so please feel free to use the github facilities to contribute with patches or issue reports.

The state of hardware acceleration on ODROID: 2nd round

Today I have repeated tests with current kernels:

Kernel	X11 Driver	Resolution	glxgears	es2gears	glmark2-es2	glmark2-es2 --fullscreen
3.0.80	ARM mali	1080p	~ 143 fps	~ 590 fps	137	35
3.0.80	ssvb sunxi	1080p	~ 140 fps	~ 615 fps	151	40
3.0.80	ARM mali	720p	~ 140 fps	~ 600 fps	142	81
3.0.80	ssvb sunxi	720p	~ 144 fps	~ 620 fps	156	92
3.8.13	ARM mali	720p	~ 136 fps	~ 226 fps	61	37
3.8.13	ssvb sunxi	720p	~ 143 fps	~ 226 fps	66	42

Performance seems still halved with 3.8 kernel.
The automated test suite will be released in odroid-wheezy-retro as a script.

odroid-wheezy-retro 0.0.7 released

0.0.7 released

In this release:

• kernel 3.0.79 (with disabled fan PWM kern.log verbosity)
• added xf86-video-sunxifb, you can enable it by copying /etc/X11/Xorg.conf-sunxi to /etc/X11/Xorg.conf
• added glmark2-es2 binary
• updated RetroArch binary
• enabled HDMI 1080p output, (advice: disable it and use instead 720p to use RetroArch)
• using EXT2 instead of EXT4
• fixed a few issues related to bootstrapping

ODROID models X/X2/Q are supported by replacing kernel and modules before flashing to SD card, you can get them from mdrjr's builder download area.

Download odroid-wheezy-retro-0.0.7

You can always check the ChangeLog and NextRelease (suggestions are welcome).
Official ODROID forum discussion here.