3D hardware acceleration on FatdogArm Beta

FatdogArm beta hits another milestone today: I've got 3D hardware acceleration running on Mele/Cubieboard2 and Odroid-U2. As it happens all of them use the Mali GPU variants.

It's quite cool to watch es2gears and glmark2-es2 running on all these boards.
As a reference, here are their glmark2-es2 scores:
Mele A1000 (A10) - 53
Cubieboard2 (A20) - 63
Odroid-U2 (Exynos4412) - 123

Remember that FatdogArm Beta is built with VFPv3-d16 (just like Debian armhf) and no NEON.

The 3D acceleration on all these uses the same Xorg driver (fbturbo) and the appropriate version of Mali blobs, all coming from sunxi-mali (from linux-sunxi repository).

All of this is made possible by the hard work of linux-sunxi folks; especially Siarhei Siamashka (ssvb) who maintains xf86-video-fbturbo (formerly xf86-video-sunxi), Luc Verhaegen (libv) who maintains the sunxi-mali repo (Luc is also the man behind the Lima open-source Mali driver effort), and Dmitriy Beykun (rzk) who ported version 20 of Mali kernel interface from upstream to Odroid kernel.

Thanks guys!

Note: I managed to get 3D acceleration done (but not tested) on XOs much earlier last year (with dovefb/libgfx-marvell); but in FatdogArm beta it will ship disabled by default as enabling it will corrupt the display on some circumstances.


Posted on 26 Feb 2014, 5:57 - Categories: FatdogArm Linux Arm
No comments - Edit - Delete


Connecting machines behind NATs

One of my friend asked me on how to use VNC when both the client and the server are behind NAT routers. He knows that he can re-configure the router to do port-forwarding and such, but it is not good enough because not everyone is comfortable (or competent) enough to do it.

So I looked into the matter and found out that yes it is possible to do so without re-configuring anything. I've written a wiki article to document the process using commonly available tools, it is located here. While it talks specifically about VNC, the methods discussed is readily extendable to any other protocols.

I hope it is useful for others who have similar problems.

Posted on 25 Feb 2014, 6:23 - Categories: Linux General
No comments - Edit - Delete


Fatdog64 630 Final is released

You have may heard it elsewhere first because I forgot to announce it here: Fatdog64 630 Final was released on 11 February 2014.

For those who have followed the 630 RC releases; the changes look minor, it is mainly software updates (but important - and I would like to thank kirk for doing most of the heavylifting). For those who stayed on the "stable" path, however, the changes from Fatdog64 621 to 630 is oustanding. You can check the full list here.

Fatdog64 630 would probably be the last and final release of Fatdog64 600 series. By the time of 630 release, the 600 series is fully two years old - an eternity in computer age; and it does show its age here and there.

This doesn't mean Fatdog64 will end. I and kirk have been discussing on the path toward Fatdog64 700; but this will not happen soon, so enjoy 630 while it lasts.

You can download it from the usual places: http://distro.ibiblio.org/fatdog/iso. For Europeans, nluug.org mirror is probably faster. For those in Australian soil, aarnet.edu mirror is for you.

Posted on 25 Feb 2014, 2:54 - Categories: Fatdog64 Linux
No comments - Edit - Delete


Food for thoughts

Interesting blog post from IgnorantGuru, the developer of SpaceFM file manager: http://igurublog.wordpress.com/2014/02/17/biography-of-a-cypherpunk-and-how-cryptography-affects-your-life/

You may or may not like what he said; and the conclusion he stated may or may not be true; but the facts he stated are indeed true.

Posted on 25 Feb 2014, 0:41 - Categories: Linux General
No comments - Edit - Delete


Find duplicate files

I happen to see a request in the Puppy forum on how to find duplicate files. Sure, there are specialised tools to do that (fdupes, doubles, etc) but what if you don't have access to them?

Turns out it's not difficult at all. This will do it:
find / -type f -print0 | xargs -0 md5sum | sort -k1 | awk '{ if ($1==prevmd5) { if (prevfile) print prevfile; print $0; prevfile=""} else { prevmd5=$1; prevfile=$0 }}'


What the code above does is basically find all files under / (which you can change to something else, e.g. /mnt/sda1, a mountpoint of your disk), then compute the md5sum of these files (you can use sha1sum if you wish, or any other hash programs); and sort the results based on the hashes, and display those that have identical hashes.

Of course, running through all files in your filesystem and computing the md5sum of *all* of them are going to take quite sometime, grind your harddisks, saturate your I/O, and tax your CPU.

And having identical hashes doesn't always mean that the files are identical (although the chance that they aren't are very little); so if you do this with the intent of deleting duplicate files you may want to extend the code a little bit to do full file-comparison when the hashes match.



Posted on 19 Feb 2014, 19:34 - Categories: Linux General
No comments - Edit - Delete


The way udev deprecates keymap

This, this, this, and this epitomises what is wrong with development of systemd/udev in general.

The first post outlined the idea of a major change (and the reason for that), the second post informed that the code is now available, the third post said that the old code is now gone, and the last post said that documentation is needed.

Ok, what's wrong with all that?

1. The reason for change is wrong: keymap rules aren't really that long.

2. The duration between the initial new code commit and the removal of existing functionality is 4 days. We're talking about major change here, breaking previous udev rules that have been working for years.

3. By the time the old code was removed; the new code wasn't complete yet (the data files required for new code was still work in progress - "Martin is still working on it...").

4. In case somebody wanted to help, well ... let's wait until someone volunteered to write the documentation first, shall we? Of course, this was after removal of existing, working code.

I'm not against new functionality. New functionality, new way of thinking are always good (and even if they turn out not to be; they are still worthwhile as they show that the old way of doing thing is still better). What I'm against is major feature change that breaks configurations that have been working for years at the snap of the finger. What's wrong with backward compatibility? It isn't like hwdb and keymap can't be made to co-exist together.

Did they consider this?

5. The new hwdb keyboard mapping depends on DMI. How about platform that don't expose DMI? Didn't think of that, do we? Or perhaps they can screw themselves? Or is it "the kernel bug - ask the kernel team to surface DMI for those platforms"? Yeah, sure. We heard them before. Linux kernel deprecates many features over the years. Not a single one of them was deprecated in four (4) days without co-existence of some sort - especially one that breaks existing functionality in userspace.

Lastly, not so important but still annoying: There is a reason why keymap files are separated into many different files. It is called "ease of maintenance". The new hwdb format for keyboard mapping? Oh it just a giant keymap file, with all the information combined (indexed by DMI/USB ids). It is so much easier to edit a giant file and run "udevadm hwdb --update" than keeping the information in separate files, one for each keyboard type, isn't it? There is a reason why applications that handles large diversity uses separate files (e.g. terminfos, printer definition files) - could you imagine if the maintainer of these combine all those data into one giant file?

I'm not buying the idea, so here is the udev-keymap tarball from old udev, re-packaged to build as an independent package (no udev required). It will work with udev; it will co-exist with the new "keyboard handling" (provided the rules don't clash); it will work with your previous keymapping rules. My only contribution was the new Makefile to make it build. The rest come from here.

An another note - it is a sad day that Debian finally caved in and went with systemd. The problem with systemd is not only technical; it's also about the attitude - as this example illustrate.


Posted on 11 Feb 2014, 19:00 - Categories: Linux
No comments - Edit - Delete


FatdogArm Beta reaches parity with Alpha4 today

As the title says. The (unreleased) Beta version of FatdogArm reaches functional parity with Alpha4 today. All that is needed to be done now is testing on all the supported platforms; then we should be good for release.

Posted on 9 Feb 2014, 3:41 - Categories: FatdogArm Linux Arm XO
No comments - Edit - Delete


FatdogArm Alpha4 for Odroid-U2 - fixed

I had a major fumble. My instructions and the FatdogArm kernel package for U2 didn't work. The reasons are double whammy:
1. I built the latest u-boot, but that latest u-boot doesn't work on U2.
2. I gave the wrong instructions for installing the boot loader.

Both have been fixed now - I have updated the U2 kernel package with the latest working u-boot version (commit 286a81158f01dcb08e16d77790c21fd2a40afc6c) and I have also updated the boot-loader installation instructions: basically, do not use bs=1024 for U2.

Thanks for Mick who directed me to this conclusion. He also more or less confirms that Alpha4 works on U3 too (sort of - he's still testing it).

Posted on 1 Feb 2014, 5:29 - Categories: FatdogArm Linux Arm
1 Comment - Edit - Delete


Mobile friendly

This blog is now a little more mobile friendly. Using media queries, if the maximum device width is 600px or less, it will hide the usual menubox and display a simplified menubox instead. Simple stuff.

Posted on 28 Jan 2014, 3:40 - Categories: General
No comments - Edit - Delete


FatdogArm Beta on XO-1.75

I have been slowly building the next version of FatdogArm (FatdogArm beta). This is a complete rebuild, based on newer LFS (LFS 7.4).

One of the major goal is to support a wider hardware base, reducing the requirement of the FPU from VFPv3 in Alpha to VFPv3-d16 in Beta; among other things.

Today it reaches a milestone - I've got it to run Xorg and JWM window manager on XO-1.75, a machine with MMP2 CPU (Armada 610 SoC), a well-known VFPv3-d16 machine (as discussed earlier).

It still has a lot to go before it reaches parity with Alpha4 (I have just completed step 5 of my original FatdogArm roadmap), but this is a good progress nonetheless.

Note: For anyone planning to do the same (glibc-2.18 on VFPv3-d16), let me save you some time: have a look at this bug entry. Apply that patch before you build glibc and save yourself some headache - otherwise all you would get from your shiny new glibc is "illegal instruction."

Posted on 18 Jan 2014, 3:28 - Categories: FatdogArm Linux Arm XO
No comments - Edit - Delete


Pages: ... [15] [16] [17] [18] [19] [20] ...