FatdogArm Beta1 kernel packages re-uploaded
If you have downloaded FatdogArm Beta1 recently, please re-download the kernel packages again. The ones I uploaded before have one leftover settings from my development that I forgot to turn off: they have SSH server enabled by default. You can easily turn them off using the Control Panel --> Services Manager, or justchmod -x /etc/init.d/S50dropbearThe newly-uploaded kernel packages have SSH disabled by default.
Note: I have just re-uploaded the kernel packages, and it usually takes about 24 hours for the mirrors to sync. So either hit ibiblio.org directly or wait 24 hours from this post before hitting your favorite mirror.
Comments - Edit - Delete
FatdogArm Beta1 is released.
After being in the cooker for over two months, I can happily announced the next release of FatdogArm: the Beta1 release.Get it from ibiblio.org as usual, or from one of ibiblio's popular mirrors: nluug.nl and uoc.gr if you're in Europe, or aarnet.edu if you are in Australia. Many thanks for ibiblio and the mirrors for providing this public service.
Read the release notes first; and if you are new to FatdogArm, please also read the INSTALL instructions. Unlike many of Linux ARM distributions out there, FatdogArm is *not* distributed as images.
Forum announcement here.
FatdogArm Beta1 is the second-generation of FatdogArm; despite its name it is *not* a continuation of Alpha: it is in fact a full-rebuild using LFS 7.4 as the base (I would like to claim "the latest LFS" but LFS 7.5 had just been released as I was gearing for release, oh well) with glibc 2.18 and gcc 4.8.1 but otherwise with many of the packages remain identical with its Alpha counterpart (updates are only done for stability reasons).
The major goal of Beta is a change of hardware platform (from VFPv3-d32 to VFPv3-d16 *without* NEON) to enable it to run on larger class of hardware; as well as a fully-reproducible build system. As a bonus, Beta1 also supports 3D GPU acceleration for all supported platforms, which are: Odroid-U2, Odroid-U3, A10/Mele A1000, A20/Cubieboard2, OLPC XO-1.75 and OLPC XO-4.
Just like Alpha4, Beta1 also ships as a "meta-distribution" (now conveniently provided as a tarball instead of fossil repository) that enables you to build your own customised version as you see fit: headless console-only version; etc. All the kernel sources are provided (kernels were cross-compiled using Linaro cross-toolchain)) so you can also also build new modules etc if you need.
Special thanks to mavrothal and 01micko for OLPC XO support and testing.
Enjoy.
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.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."
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):
http://distro.ibiblio.org/fatdog/arm/releases/alpha4/
Forum thread: http://murga-linux.com/puppy/viewtopic.php?p=734069#734069
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/.
Comments - Edit - Delete
FatdogArm alpha3 is released
Make sure your read the release notes first: http://distro.ibiblio.org/fatdog/web/arm-alpha3.htmlGet it from ibiblio (or one of its mirrors):
http://distro.ibiblio.org/fatdog/arm/images/
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.
Comments - Edit - Delete
XO-4 native Xorg driver for FatdogArm
I finally managed to build dovefb Xorg driver for XO-4. That means XO-4 now has a native Xorg driver (using proprietary blobs from Marvell), and should provide equal features as Fedora XO.The difficulty with compiling the driver lies in finding the right version of the proprietary blobs to use. The one in the git repository turns out to be not the latest one, the one in OLPC RPM Dropbox is.
One thing that it immediately fixes is screen rotation (xrandr). 3D may work too, but I haven't tested that (no EGL / GLES test programs). There is no acceleration for hardware decoding though, as it is another subsystem of the SoC (VMeta) and requires complete different library ...
Anyway, with this, and the other hard work from Mavrothal, FatdogArm on XO-4 is looking very good.
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.
Comments - Edit - Delete
When an FPU is not an FPU
After finishing up the loose ends, I went to look at the XOs. Mavrothal has already ported the bulk of FatdogArm to XO-4, with only minor nuisance left, so I thought I'd like to attack XO-1.75, which Mav has attempted to and found intractable problems: Xorg desktop won't start (illegal instructions), autoconf won't start (illegal instructions), wpa_supplicant won't start (illegal instructions) (e.g here), so I thought it would be a interesting challenge. And a challenge it was, indeed!I booted of Mav's FatdogArm's XO-build and was immediately faced with the same problem. And it's not only those, even innocuous programs like "tar" or "ps" would crash with illegal instructions. In the beginning we thought that the crash could be caused by the accidental use of NEON instructions (which XO-1.75's CPU, Armada 610 SoC, doesn't have) - perhaps used by pixman (used by Xorg) and encryptions (wpa_supplicant). But surely "tar" and especially "ps" have nothing to do with SIMD processing, so it is unlikely that NEON has anything to do with it.
Gdb was no help - it itself was crashing
. I followed the same general steps that I took when troubleshooting Seamonkey illegal instruction, but it didn't get me far.
I got a major clue when I managed to run "tar" without crashing, that is, when I run "tar --version" - it worked well, it showed the version number, and there was no crash. But if I run "tar" by itself - then I got the crash. This informed me that the cause of the crash must have happened after dynamic linking is done; otherwise it will always crash no matter what.
"Tar" is a rather big application, but "ps" is small and it also crashed. So I hacked "ps" source and start peppering it with printf statements to see where the crash happened. This got me to the function that crashed - the "uptime" function. But why did it crash? Why did the entry to the call make the entire program crash (the body of the function never got executed).
I did a few tests and after a while I managed to create a 5-line C program that will crash too:
#include <stdio.h>
main() {
float a=3.0;
printf("%f\n",a);
}So was it "printf" that was bad? Is there something wrong my with glibc built? But this same program - crashed also when I run it on the Fedora that shipped with XO. I'm quite sure Fedora's libc is fine because other Fedora apps work fine, not crashing. So it has to be my 5-line program.
So I went to "objdump -d" to look at the assembly code generated. I don't know much ARM assembly language, I just hoped that my knowledge of x86 assembly will carry me through --- and it did. A few further experimentation pinpointed the problem with this innocuous instruction: vcvt.f64.f32 d16,s15 (that's a floating-point conversion instruction, converting from single precision to double precision, data source from register s15 and storing the result or register d16). So the crash is caused by a floating point instructions, which isn't surprising because FatdogArm is built from ground-up as a "hardfloat" system.
But there is only one problem - that instruction worked on A10! So what gives? Both A10 SoC and Armada 610 SoC have FPUs which conforms to VFPv3, so the instruction should work on both, right?
Wrong. ARM FPU doesn't come in a single variant. In fact the VFPv3 FPU comes in 4 (four) variants, two of which are common. Look here for the details, one can see that ARM supports multiple versions of the VFPv3 (if you count VFPv2 and VFPv4, you'll get even more variants, but we already know that our SoCs only support VFPv3 so we can ignore the rest).
The major two common variants are VFPv3 (also known as VFPv3-d32 or the full VFPv3, which comes with 32 double-precision registers), and VFPv3-d16 (which comes with half the number of registers, 16 only). And this confirms that Armada 610 only supports VFPv3-d16. In fact, one can look at /proc/cpuinfo and see the same information - but I didn't see it before. XO-1.75's /proc/cpuinfo contains cpuflags of "vfp vfpv3 vfpv3d16" and I thought those combinations means that the CPU supports all combinations. Well I was wrong; the flags means that while "vfpv3" instructions are supported, only the "vfpv3d16" subset will work.
Armed with this information, it is easy to see what the problem is. With 32 registers, one has registers named "d0" to "d31". With 16 registers, one only has "d0" to "d15". And what was the instruction again? "vcvt.f64.f32 d16,s15" --- so that was the problem, it was trying to access a register ("d16") that doesn't exist in vfpv3-d16 - and of course, one will get a "illegal instruction" for that.
The solution? Easy - just re-compile the application with "--mfpu=vfpv3-d16" (instead of the default --mfpu=vfpv3) and then my 5-line C program worked. I did the same for "ps" and it worked too.
Of course, it is one thing to fix one program, it is another issue to fix the entire distro (which apparently the task that I need to do if I want FatdogArm to run on XO-1.75 ...
)
After note: I could have short-circuited all the above if I just look at Fedora's gcc build-time configure flags (by running "gcc -v"), which would have told me that it is configured for vfpv3-d16 instead of vfpv3. At the very least Debian publishes explicitly what its hardfloat port will run on.
Comments - Edit - Delete
