ODROID-C1 issues finally fixed.

When I decided to replace my beloved Raspberry Pi media center with something more powerful, I didn’t expect so many issues. I purchased Hardkernel’s ODROID-C1 and was rather excited. The Kodi Entertainment Center worked much smoother than before (especially since I compiled it to use the Framebuffer instead of X11). I’m even able to play a lot of retro games (not all though) at full speed via emulators for Sony Playstation, Sega Genesis, Dreamcast and Nintendo’s SNES, NES and N64 consoles.

But after some time, I figured there were still some problems that I were unable to fix on my own.

This super-annoying issue for example: Occasionally, the audio would drop for 1 or 2 seconds - sometimes only once or twice during a 2 hour movie, sometimes every 2 minutes. I was not the only one with this issue when I reported it at the start of February. But it took quite some time, until this was fixed. The main problem here: The hardware vendor, Amlogic, writes really crappy code. I had a look at their kernel sources and their code quality is so poor that I wonder why this stuff even works most of the time. At least, Amlogic seems to embrace Open Source Software (which can’t be said about some other vendors) and sent a patch to Hardkernel.

Another issue was fixed too. The CEC implementation on the C1 is kinda broken (hardware-wise), so you’re unable to control Kodi with your TV remote. You still can do this via the built-in IR receiver, but since my C1 sits inside a closed cupboard, this was not an option for me. You can fix the CEC-Issue yourself with some soldering, but fortunately, some devices even work without any soldering. All you need is to install RTC battery and hope for the best. In my case that worked.

Finally, after more than 4 month, I can finally use this little device as a fully-featured media center.

Working around UEFI madness on a HP ProBook 6465b

It’s past 6 o’clock in the morning and - while writing this blog post - I’m wondering why manufacturers seem unable to implement stuff properly. If I had known what pain UEFI would cause me, I would have sticked to my good ol’ BIOS boot setup.

But first things first: Since I wanted to play some games with my friends, I decided to boot the fallow Windows 7 partition that I had set up for this very purpose. I’m using ArchLinux almost exclusively, thus I never booted that partition after installation.

So Windows was booting… All of a sudden, the infamous Blue Screen of Death appeared and my Laptop rebooted. “Shoot!”, I thought. I still cannot think of any valid reason why this BSOD occured in the first place. How did Windows managed break down without even being booted? Anyway, after various failed attempts to fix it (including Windows Startup repair, safe mode and recovery console), I eventually gave up and faced the inevitable: I had to reinstall Windows.

After struggling with the Windows installer (which first refused to install to my GPT-partitioned hard disk because for some reason it always started in legacy BIOS mode), I finally succeeded. Unfortunately, Microsoft - as the ultimate authority of enlightenment - is destined to enforce their commandments, including “I am Windows thy OS, Thou shalt have no other OS before me”. Therefore, it just overwrote my existing boot manager rEFInd and replaced it with it’s own one, so that I was unable to boot into Linux.

Since I was using UEFI (mainly because I was curious, it doesn’t really make sense from a security standpoint), I was actually able to reboot and quickly press the F9 key on my HP ProBook 6465b to select a boot device. One of the options was to select an EFI file to boot, which at least enabled me to boot Linux at all, but than can only be a temporary solution.

Now the real pain began: First, I tried to get back rEFInd by using Windows’ bcdedit. I downloaded it and followed the steps here, but to no avail:

C:\> mountvol S: /S
C:\> cd \Users\jan\Downloads\refind-bin-0.8.7
C:\> xcopy /E Users\jan\Downloads\refind-bin-0.8.7\refind S:\EFI\refind\
C:\> S:
S:\> cd EFI\refind
S:\EFI\refind> rename refind.conf-sample refind.conf
S:\EFI\refind> bcdedit /set {bootmgr} path \EFI\refind\refind_x64.efi
S:\EFI\refind> bcdedit /set {bootmgr} description "rEFInd Boot Manager"

It kinda worked, and there was no error message, but Windows still kept booting instead of rEFInd.

So, I rebooted into Linux to restore my boot manager via efibootmgr. But that still didn’t work, because the new boot entry that I added immediately disappeared.

# efibootmgr -c -d /dev/sda -p 1 -L "rEFInd" -l /EFI/refind/refind_x64.efi

Next step: Compiling the EFI Shell v2 in order to use bcfg to edit my boot entries. After compiling, rebooting, pressing F9 and selecting the shellx64.efi file, the next disappointment awaited me: ASSERT_EFI_ERROR (Status = Not Found)

After some googling, I found the cause of this: The UEFI implementation my ProBook uses is too old to be compatible with the EFI Shell v2. Using EFI Shell v1 was no option either, since it lacks the bcfg tool that was the reason to boot the shell in first place.

Now I was a bit baffled to say the least.

After massive googling, I finally found the single most ridiculous way I can think of to get my beloved rEFInd setup back: **drum roll**

Some very bad UEFI implemtations apparently expect the *.efi file to boot at EFI/Microsoft/Boot/bootmgfw.efi. So I mounted my EFI System Partion at /esp:

# mkdir /esp
# mount -t vfat /dev/sda1 /esp

Then I moved my Windows *.efi files to a newly created folder, moved my refind to EFI/Microsoft/Boot/bootmgfw.efi and renamed refind_x64.efi to bootmgfw.efi:

# cd /esp/EFI/Microsoft
# mkdir Windows
# mv Boot Windows
# mv ../refind Boot
# mv Boot/refind_x64.efi Boot/bootmgfw.efi 

And - to my surprise - it actually worked. Simple as that. Wow. I just needed to adapt my refind.conf to the new path of the Windows bootloader (since I disabled to autodetection of efi files in favor of manual entries), but that’s it. I finally finished getting my usual boot setup back.

I still don’t know who I should condemn more: Microsoft for still replacing the boot manager without even asking or HP for putting such a crappy UEFI implementation into my Laptop. But one thing I know: Next time I reinstall my PC, I’ll choose Legacy BIOS instead of UEFI.

ODROID-C1 post-installation tips

Some weeks ago I decided you replace my old and rusty Raspberry Pi (serving as a media center) with something faster (and less likely to suddenly lose ethernet connection). I stumbled over the dirt-cheap ODROID-C1, which outruns the Raspberry Pi (and even the brand-new Raspberry Pi 2) thanks to its Amlogic S805 ARM Quad Core Cortex™-A5 processor and Dual Core Mali-450 GPU. And it’s also supported by ArchLinuxARM.

If you’ve also purchased that little device, here are some solutions to problems I encountered upon first boot (after setting up basic stuff like timezone, hostname, locale, etc.), so I hope that these tips help you, too.

Blacklisting the Dallas 1-Wire interace

In case you’re not going to use the 1-wire interface, you might want to blacklist the kernel module. Otherwise, it’ll keep scanning all day long for attached sensors. Create /etc/modprobe.d/blacklist-w1.conf and insert:

# Disable the 1-wire interface
blacklist w1_gpio

Enabling the Hardware Random Number Generator

Use the hardware RNG instead of haveged. You need to install rng-tools and make sure that /etc/conf.d/rngd contains:

RNGD_OPTS="-o /dev/random -r /dev/hwrng"

Then, you can enable the rngd service via systemd:

$ sudo systemctl stop haveged
$ sudo systemctl start rngd

To keep using the hardware RNG after a reboot:

$ sudo systemctl disable haveged
$ sudo systemctl enable rngd

HDMI-related stuff

Getting video working

If you’ve configured everything correctly, but you still get no image on your display, chances are that you bought a non-standard HDMI cable that misses the group pin. Either go buy another cable (it’s rumoured that the AmazonBasics HDMI-to-Micro-HDMI cable works) or short the shell of the Micro-HDMI with the (grounded) Micro-USB-shell. I used a paperclip to do this. Have a look at this post in the ODROID forum.

Getting audio working

Install pulseaudio. You need to edit Pulseaudio’s default.pa, so either edit /etc/pulse/default.pa in-place or copy it to ~/.config/pulse/default.pa of the respective user.

Search for these lines:

#load-module module-alsa-sink
#load-module module-alsa-source device=hw:1,0

And replace them with:

load-module module-alsa-sink
load-module module-alsa-source device=hw:0,1

Important: Make sure that it’s hw:0,1 and not hw:1,0!

Also, do not forget that your user need to be part of the audio group to use the sound device.

Now you can check if everything worked by running:

$ paplay /usr/share/sounds/alsa/Front_Center.wav 

Getting CEC working

Unfortunately, that’s a hardware issue. The guys at Hardkernel are working on it, so chill. You’ll probably need to RMA your device or do some soldering yourself, though. Check out this thread in the ODROID forum.

Adblock on your router

A lot of people already use Adblockers in their desktop browser, but what if you’re using your phone, tablet or an alternative browser? Getting rid of annoying ads is simple: Block them with your router.

The idea is simple: when the DNS server on your router receives queries, we’ll sort out queries that ask for the A Resource Records of ad servers and return 127.0.0.1 instead of the ad server’s IP address.

There are loads of scripts out there to accomplish something like that. IMHO, some are too complex (like changing the FORWARD chain in iptables), some do stuff I don’t like (e.g. manipulating stuff in /etc/) and some even pose a security threat, because they download config files and use them without checking their content.

This is why I wrote such a script myself. What It does:

  • download a list of ad servers in dnsmasq config file format from yoyo.org
  • check if the file only contains address statements that assign the IP address 127.0.0.1 to some domain name (with grep)
  • save the file as /tmp/dnsmasq.d/adblock.conf
  • restart dnsmasq

You need at least OpenWRT revision 39312 to use it.

Enough talk, let’s get going: Simply SSH to your router, download this script:

# mkdir -p /opt/bin
# curl "https://gist.githubusercontent.com/Holzhaus/ed4ac1675a57f11c3057/raw/6a2b59ce046ad6da5f9eac48db925f0afb292a00/adblockupdater.sh" > /opt/bin/adblockupdater.sh
# chmod +x /opt/bin/adblockupdater.sh
# /opt/bin/adblockupdater.sh

To update the server list on a regular basis, add the line 0 0 */1 * * /opt/bin/adblockupdater.sh to your crontab by typing crontab -e.

Congrats, you now have adblock on your router!

Note: If you can’t download the script, because you’re getting curl: (51) Cert verify failed: BADCERT_NOT_TRUSTED, you’re probably missing CA certificates. Run:

# opkg update
# opkg install ca-certificates

Also check if export SSL_CERT_DIR=/etc/ssl/certs is in your /etc/profile and add it, if neccessary. Run source /etc/profile and retry.

Ogg videos on RPi/Kodi

I recently wanted to play an OGG video on my Raspberry Pi with XBMC (which has been renamed to Kodi recently). Unfortunately, it didn’t work out of the box. This is how I solved the problems.

Problem 1: Ogg video file not recognized.

If you try to open your file by using the file browser in Kodi’s video section, it won’t be displayed. This is because Kodi assumes that files with the *.ogg extension are audio files.

Solving this is easy: Simply rename somefile.ogg to somefile.ogv (somefile.ogm is also possible). For the sake of completeness: Your Ogg audio files can have *.ogg or *.oga as file extension.

Although you can also change the way Kodi detects files and make *.ogg a video file extension, I do not recommend this. That extension is much more common with audio files and renaming Ogg videos to *.ogv makes audio and video files distinguishable by just reading the filename.

Now you can see the Ogg video file in Kodi’s file browser. You hit enter and …. have another problem.

Problem 2: Ogg video file playback is audio-only

Now the file actually plays and you can hear the sound, but there’s no video. This is probably because the RPi’s GPU does not know how to decode the video. GPU accelerated software codecs are only available from start_x.elf.

Open /etc/profile/ and append /opt/vc/bin to your $PATH:

# Set our default path
PATH="/usr/local/sbin:/usr/local/bin:/usr/bin:/opt/vc/bin"

Then add this to your /boot/config.txt:

start_file=start_x.elf
fixup_file=fixup_x.dat

That causes the RPi to load testing versions of the GPU firmware. These enable potentially unstable/not-fully-tested/hacky functionality - currently, using these files instead of the usual fixup.dat/start.elf will cause extra video codecs to become available.[1]

Note that you should set your GPU memory to at least 128 MB:

gpu_mem_256=128 # If you have 256 MB RAM (Model A)
gpu_mem_512=128 # If you have 512 MB RAM (Model B)

Et voilà. Kodi is now able to play Ogg video files (hopefully)!