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
Comments - Edit - Delete

FatdogArm Alpha4 for Odroid released

I had FatdogArm Alpha4 running on Odroid-U2 since early last month. In that time period, I was hoping that I could get beta up and running - but my timing was off; I got occupied by something else (Fatdog64 is one of them).

I am now building FatdogArm beta, but it will be a long way off until it reaches parity with Alpha4. So in the interim, I thought I'd just release a version of Alpha4 that will run on Odroid. Get it from the usual place here: http://distro.ibiblio.org/fatdog/arm/releases/alpha4/.

Note that in addition to the kernel package, Odroid-U2 will require a newer fd-arm.sfs (named fd-arm-u2.sfs). The main change from the original alpha4 sfs are these:
a) /etc/init.d/02-cpuspeed is disabled by default - Odroid kernel is sensitive to unrecognised values; it will crash the kernel otherwise.

b) /etc/X11/xorg.conf.d/20-gpudriver.conf defaults to "/dev/fb1" as the framebuffer device (instead of /dev/fb0) - this is how it is on Odroid, /dev/fb0 is actually reserved for LCD screen (which usually isn't connected on U2).

Other than that, it is fd-arm-u2.sfs contains a newer version of Seamonkey. You could have used the original fd-arm.sfs too and make the above changes yourself, but I thought it would be more convenient to have one that immediately works.

I have also updated the INSTALL notes; I have also updated the release notes to reflect the update.

Posted on 1 Jan 2014, 20:04 - Categories: FatdogArm Linux Arm
Comments - Edit - Delete

Odroid-U2 is fast!

Odroid-U2 is really fast. I built Seamonkey 2.22.1 (the latest at the time of writing) on it - it took me only 2 hours 45 minutes. This compares favourably with building on my 64-bit x86_64 laptop which is about 2 hours 15 minutes (or so).

It is a far cry with my original build of Seamonkey 2.19 on Mele (A10, Cortex A8, single-core, 512MB) - which took between 15 to 18 hours depending on my luck.

During the build, all the four cores of Odroid-U2 was maxed out at 100%, yet the temperature never climbed higher than 70 degrees. Odroid-U2 uses a fanless heatsink, and this heatsink - while noticeably warm - was still touchable. This contrasts with my x86_64 laptop, whose temperature climbs to a worryingly 95 degrees with its fan is being overworked to prevent thermal shutdown.

I need to revise my opinion that ARM is still playing catch-up with Intel - it no longer is. In fact, there is no Intel offerings which is on similar power/performance/price as this one. Intel Minnowboard is a single-core hyper-threaded (=dual-thread) 1GHz CPU and 1GB RAM priced at $199. Intel Galilo is a measly 400MHz single-core CPU poised to compete with Arduino. None of them are even close in terms of price/performance to Odroid-U2 (I didn't check the specs on their power consumptions) - this board and its Exynos4412 Prime CPU is in a class of its own.

Posted on 7 Dec 2013, 5:01 - Categories: FatdogArm Linux Arm
Comments - Edit - Delete

FatdogArm on Odroid-U2 - take two

I really want to have console framebuffer on the Odroid.

So I spent quite a while to figure out what's wrong with console framebuffer. I wanted to know why the framebuffer works with X but not with fbcon.

First, I figured which driver provided the framebuffer functionality (not easy since /proc/fb doesn't show the driver name). Turned out it is "videobuf2-fb.c". Secondly, I traced the failing call from fbcon.c - this was one was quite straightforward, and brought me back to videobuf2-fb.c - and there lied the problem - videobuf2-fb.c checked for fbcon call and reject it (the line that did it was even commented that mmuch!). The check was actually for an init call from kernel space (which fbcon does).

Okay, so what happened if I allowed fbcon call to pass through? Various bad things happened - either the system didn't boot up at all; or, if I switched fbcon to use the framebuffer later, the system froze. Well I can't see anything when this is happening, so I have to hazard a guess: there must be some interlocking mutex between videobuf2-fb and fbcon. Enabling fbcon call to videobuf2-fb caused a deadlock somewhere. Without a serial console, things like these are very difficult to trace and debug - so that was the end of it.

Turned out all the above was a wild goose chase anyway. I was planning to upgrade to kernel 3.8, and now that I hit dead-end with that investigation, I decided to build it. Guess what? The hardkernel guys (or is it samsung itself? not sure) have fixed the framebuffer issue! The videobuf2-fb issue is still there; but there is a brand-new "exynos-drm" module that does the same job, but only better!

In fact, kernel 3.8 improves on other things: HDMI audio now works, alsa volume control now works ... three cheers for the hardkernel guys.

So yeah, looks like it will be smooth sailing from here.

Posted on 4 Dec 2013, 2:23 - Categories: FatdogArm Linux Arm
Comments - Edit - Delete

FatdogArm on Odroid-U2

I've just received an Odroid-U2 board a few days ago, from a nice person who wish to remain unnamed (thank you!).

Odroid-U2 is a board with Samsung Exynos4412 Prime SoC, a 1.7GHz, 4-core Cortex-A9 CPU with 2GB of memory. It's very small (smaller than cubieboard2) yet it is very capable; it demonstrates lucidly where ARM is going (and Exynos4412 is actually last year's product - the newest one being Exynos5 which is an 8-core CPU).

I immediately set to task to get FatdogArm running on it, after confirming that the board works by running stock Hardkernel Ubuntu ARM on it.

I went with the (now) standard procedures of building the bootloader (u-boot), building the kernel, and preparing the initrd (mainly for kernel modules), and put them into SD card.

I immediately hit a snag - the system seemed to boot but my screen was blank. After a few visits to odroid/hardkernel forum, it was made obvious that odroid doesn't have a working framebuffer console for HDMI output to due quirky way the HDMI output driver had been written. For the better or worse, I don't have an UART serial cable to go with it - which means I'm blind, I don't know whether the board works or not (and if not, what is the error).

But thankfully Hardkernel guys (the manufacturer of this board) has been working hard to prepare a kernel that is rock-solid - the board actually worked the first time, it's just that I can't see the output. I typed the output blindly (I know what to expect if things goes right), slotted in my USB flash drive and piped command output to the flash drive, and read the output on my laptop. This way of working soon got me a working ssh server on the odroid, and with that I'm no longer blind. Sure I still can't see what happens before the ssh server is started but that's not so important at the moment.

With ssh working, I managed to get X desktop working shortly afterwards (as it turned out, there is nothing special required except to specify the correct framebuffer device), here's a simple screenshot based on a tweaked Alpha4 release (it must be tweaked because verbatim Alpha4 release has a boot-up command (/etc/init.d/02-cpuspeed) that causes the kernel to crash).

Posted on 3 Dec 2013, 4:59 - Categories: FatdogArm Linux Arm
Comments - Edit - Delete

FatdogArm Alpha4 is released

Alpha4 is a bugfix release, mainly because of RAM layer problem. There is no new feature in it (apart from new distribution method). Everyone is recommended to upgrade.

Release notes http://distro.ibiblio.org/fatdog/web/arm-alpha4.html.

Get it from ibiblio (or one of its mirrors):

Forum thread: http://murga-linux.com/puppy/viewtopic.php?p=734069#734069

Posted on 1 Nov 2013, 15:37 - Categories: FatdogArm Linux Arm XO
Comments - Edit - Delete

FatdogArm on Cubieboard2

I have received a Cubieboard2 from someone who shall remain anonymous (thank you!).

The delivery took quite a while, but it finally arrived yesterday; and today I have FatdogArm running on it (screenshot here).

It is still in the early days and it will need tweaks, but in general it is running smooth and well. Cubieboard2 will be a supported platform in the next release.


I noticed something. I'm using linux-sunxi kernel, 3.4 branch, the latest, and using cubieboard2_defconfig (suitably modified) from cubieboard2/linux-sunxi fork. The difference between this and my previous ARM kernels is that this kernel enables a lot of modules. Which is ok, except for one thing: I noticed that the kernel modules are *huge*. For example, the entire collection of netfilter modules on my x86_64 is around 1.3MB. The same collection on the A20 kernel I just compiled is - guess what? It's *18MB* - more than 10 times! Initially I thought it is because of the compiler (I used gcc 4.6.2) so I used Linaro's gcc 4.7, and the result is almost identical. Hmmmm.

Posted on 9 Oct 2013, 18:27 - Categories: FatdogArm Linux Arm
Comments - Edit - Delete

FatdogArm for XO-4 is released

Based on alpha3, Mavrothal has kindly released FatdogArm for XO-4. I have updated the release notes to reflect this.

Release announcement: http://distro.ibiblio.org/fatdog/web/arm-latest.html#xo4.

Forum thread: http://murga-linux.com/puppy/viewtopic.php?p=728487#728487.

Images: http://distro.ibiblio.org/fatdog/arm/images/.

Posted on 3 Oct 2013, 23:04 - Categories: FatdogArm Linux Arm XO
Comments - Edit - Delete

FatdogArm alpha3 is released

Make sure your read the release notes first: http://distro.ibiblio.org/fatdog/web/arm-alpha3.html

Get it from ibiblio (or one of its mirrors):

Forum thread: http://murga-linux.com/puppy/viewtopic.php?p=728353

Alpha3 supersedes the Alpha2 (which has been removed from the server).

Apart from a few fixes, the main feature of Alpha3 release is support for XO-4 (in a separate image) - and the release of FatdogArm as a "meta-distribution" allowing anyone to build a customised version of FatdogArm.

Posted on 2 Oct 2013, 23:26 - Categories: FatdogArm Linux Arm XO
Comments - Edit - Delete

Fixing XO-4 touch input

I'm in a hurry, so here's a short summary.

FatdogArm works well on XO-4, except that it's touchscreen isn't working (but it works under Fedora Arm).

I have two touchscreen-capable drivers in FatdogArm: evdev, and xf86-input-tslib. Both are the latest versions. And as it happens, both have bugs preventing them to work.

a) evdev 2.8.1 (latest as of time of writing) has bugs, calling mtdev for unnecessarily. This bug is fixed by this commit. Fedora Arm doesn't encounter this bug because it uses an ancient version of evdev, version 2.7.3. Upgrading to the latest git version (commit 0f16065b00436c5df48af6e1d6a18e2ed27a12fd) fixes it.

b) xf86-input-tslib has bugs and its underlying tslib library has problems:
b1) input-tslib will crash because of missing xf86InputSetScreen. This function was removed from Xorg in 2011, so all that is needed is to comment it out. But I've already used Debian Sid patches for this, I wonder why they haven't included this fix in their patchset? (perhaps because it is seldom used at all?)

b2) tslib doesn't suport multitouch, so XO-4 input confuses it. Furthermore, XO-4 touch reports that it has BTN_TOUCH support but never generates one. There are multitouch patches for tslib lying around but they don't work.

So I went inside tslib and patch it to work with XO-4 driver (adding the appropriate event recognition to tslib - ABS_MT_PRESSURE, ABS_MT_TRACKING_ID, etc). It *does not* make tslib multitouch-capable, it only makes tslib works with touchscreen that uses multitouch drivers / protocol.

The patch fixes issues with XO-4 touchscreen but I believe that it isn't XO-4 specific - anyone with multitouch driver will meet similar problem sooner or later. I have sent the patch to tslib maintainer (Chris Larson) but in case you need it sooner, you can find the patch here.


With those, now both drivers work with XO-4 (and hopefully with others too). Whichever you choose to use is up to you. For now, I'm putting evdev as the default driver and removing xf86-input-tslib and tslib from the basesfs; however they are available in the repository.

Posted on 22 Sep 2013, 15:31 - Categories: FatdogArm Linux Arm XO
Comments - Edit - Delete

Pages: ... [2] [3] [4] [5]