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.
Comments - Edit - Delete
Turbovnc now plays well with xrdp
I've recently toyed with xrdp to see how far it has progressed. Quite to happy to see that it finally has x11rdp back on the table in the latest git-master (0.7.0). During my experiment, though, I noticed that I can't login to any of sesman-Xvnc session. There was no error message from xrdp-sesman or from Xvnc (which was launched by sesman) itself, and there was no message from the rdesktop screen either. Surprisingly, I can *connect* to the underlying Xvnc server, but xrdp can't seem to connect to it, no matter what I did. It just seemed to hang during early protocol negotiation phase. For the record, my Xvnc is actually turbovnc.Naturally, I did a google search and I only found one occurrence of someone complaining that turbovnc doesn't play well with xrdp, with no solution (the only solution was to use tightvnc instead); this was from 2011. Hmmm. There was another somewhat unrelated 2010 post that they managed to use turbovnc with xrdp, but were having problems with x11rdp. I wasn't using x11rdp, but the interesting part is that it seemed that they could get turbovnc play well with xrdp - but no clue on exactly how. Mmmm, okay. Time to roll-up the sleeves again.
Initially I thought the problem was with xrdp, so I spent some time debugging it. I came to the conclusion that the hanging situation happened because xrdp (or rather, its vnc plugin) was waiting for authentication acknowledgement from the Xvnc but never got it. Upon closer examination and comparison with RFB protocol specification, I was quite certain that xrdp implemented the protocol correctly. But why did it hang, while my regular vncviewer (which is tightvnc's, not turbovnc's), didn't?
As I went on for a little while, I noticed that (tight)vncviewer connected to the (turbovnc) Xvnc using RFB protocol version 3.8. This protocol is quite different from the one used by xrdp; it used an earlier version, version 3.3. So I got tightvnc source, and hacked it a little to force it to use RFB 3.3 instead of the latest supported (in this case 3.8). Look and behold - this time the vncviewer hung, too! There must be something weird in turbovnc's implementation of the version 3.3 of the RFB protocol.
A little more debugging later, I came to the conclusion that there was indeed a bug in turbovnc's implementation of RFB 3.3 and 3.7 protocol (basically anything other than 3.8). In addition it also has a bug that render "no authentication" (ie, password-less) connection useless. Once found, it was easy to fix both of them.
It is to be noted that most vncviewers these days implement RFB 3.8 protocol; and most people will run Xvnc with authentication, so it is unlikely that you will encounter either one of these bugs. But if you do, and you need a solution, hit into my patches page and get the patch from there. Oh and by the way my patch also changes the root of X11 to be in /usr instead of /usr/X11R6 (that was long ago), and the location of the font directory (FontDir), as well as disabling PAM by default (you can re-enable it by removing the patch that disable it - it should be obvious which one). The patch is meant for turbovnc 1.1 but it will also apply cleanly to turbovnc 1.2 (which still has the bug).
As a happy ending, with the patch xrdp now works beautifully with turbovnc.
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
Patches page
I have a small collection of patches of various nature, so I thought I'd put them together in a page to make it easier for others (and myself) to find it when it is needed.The patches page is here.
One new patch in that page is a patch for guvcview, a webcam viewer and recorder. The latest version is GTK3 only, but I don't run GTK3, so I created a patch to compile and run guvcview in GTK2.
Comments - Edit - Delete
BootMenu updated
The original post was here. I just updated the BootMenu to add a few scriptable functions (reboot, init, shell, poweroff), as well as replacing the deadlock-prone evtest-based input with pure shell based input (using "read").The updated article and script is here.
Comments - Edit - Delete
Linux 3.12 will support USER_NS with XFS
I was hoping this was fixed in 3.11, but it isn't (I think it simply missed the commit window for 3.11).That being said, the good news is that it has been fixed and Linux kernel 3.12 *will support* building XFS with user namespace enabled! This is the commit that enables that, and it already appears in 3.12-rc1.
Good stuff!
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
Simple menu-based boot manager using kexec
The ARM platform doesn't have a user-visible boot manager that can match the flexibility of syslinux or Grub that enables the user to choose boot settings from many configurations at boot-time, before the operating system is loaded.U-Boot, the ubiquitous bootloader used in many ARM platforms, is indeed versatible but unfortunately it is run before the display is ready; thus the only people who can see and interact with it are those equipped with serial console to the platform.
To that point, I have written a simple menu-based boot manager called BootMenu. This simple boot manager allows you to write a syslinux-like configuration file and presents them at boot time for you to choose. For more details, read here.
BootMenu is included in FatdogArm Alpha2.
Comments - Edit - Delete
