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):
http://distro.ibiblio.org/fatdog/arm/releases/alpha4/

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


Addressing your home PCs by names

If you have a few machines connected in a home network, you may want to connect to them (for administration, file sharing, streaming, etc). You can of course connect to them by using their IP address, but this gets old very soon especially if their IP address keeps changing (e.g. due DHCP server reboots, etc). You want to address them by name (by their hostname).

If you have an all-Windows network, this isn't a problem - Windows comes with facility to directly address each other (in the same subnet) with their (netbios) names.

If your machines are Bonjour/Avahi-capable, this is also not a problem - they provide similar functionality to discover name-to-address mapping (and more).

If your machines are none of these; then you will need some mechanism to somehow map the (host)names to their IP addresses, so head to this article.


Posted on 29 Oct 2013, 18:35 - Categories: Linux
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


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.


Posted on 7 Oct 2013, 2:25 - Categories: Linux
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):
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.

Posted on 2 Oct 2013, 23:26 - Categories: FatdogArm Linux Arm XO
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.

Posted on 31 Sep 2013, 3:38 - Categories: Linux General
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.

Posted on 23 Sep 2013, 7:25 - Categories: Linux
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!



Posted on 22 Sep 2013, 15:20 - Categories: Linux
Comments - Edit - Delete


Pages: ... [12] [13] [14] [15] [16] [17]