Merry Christmas
It's the time of the year again. Time to remember what a blessing this year have been, and time to remember Him who has given His all so that we are where we are today. Time to remember what Christ means in Christmas - not only in this holiday season, but also for the rest of the days in the upcoming new year.Merry Christmas everyone.
No comments - Edit - Delete
Barry Kauler is back
Barry Kauler, the original author of PuppyLinux (here and here) - from which Fatdog64 originally came from, is back.This patriarch of the Puppy community has been missing for over two months after he announced his retirement from Puppy Linux back in late September. News from him became few and far between; and there have been understandable confusions and worries among his followers in the Murga Linux forum.
But now he's back, and he's still doing Linux, among other things. It's no longer Puppy Linux admittedly, but is a quirky variant called - obviously enough - Quirky Linux (or Quirky Puppy, etc). Old habits (or hobby) dies hard :)
Whatever it is, it is a heart warming that he's still with us and is still doing Linux development of one sort or another. Let's hope that his stay is a long one.
No 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.
No 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.
No 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).
No 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
No 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.
No comments - Edit - Delete
Fatdog64 630RC1 is released
Release notes here: http://distro.ibiblio.org/fatdog/web/630rc1.html.Get it from ibiblio.org http://distro.ibiblio.org/fatdog/iso/ or its mirrors.
Forum thread: http://murga-linux.com/puppy/viewtopic.php?p=730926#730926
Highlights:
- kernel 3.11.4 with dynamic power management support for radeon graphic cards (lower temperature, better battery life, better performance). Please see this post from the radeon driver developer himself to see how to control the power/performance balance.
- updated Xorg and multimedia libraries
- multiple sandboxes (as first discussed here).
- LXC-based sandbox (as first discussed here). Note that the current 630RC1 kernel doesn't support user namespaces because it still conflicts with XFS and we feel that XFS is more important across the board than user namespaces. This may change if we decide to adopt kernel 3.12 which has resolved this issue.
No comments - Edit - Delete
Fatdog64 Update
I have been busy with FatdogArm in recent times but it doesn't mean that Fatdog64 is ignored. In fact, the development of the next version of Fatdog64 is currently in the works now.Fatdog64 development usually alternates between two phases - development phase and release phase.
During development phase, kirk and I get very active and do all the usual stuff you usually attribute to "development" - and in between we will release alpha or beta releases in quick succession for others to tests so that we can squash the bugs. When the quality is good enough, we will make a release - this marks the beginning of the release phase.
During this release phase, generally all development slows down except for immediate bug fixes and/or experimental ideas for the next release; it also helps to relieve us from burnouts and focus on other things in life. After a while (usually a period of between 3 to 6 months), the development phase will begin again.
Fatdog64 621 was last released on 8 May this year, so it is due for a refresh, which is in the works. One of the thing we waited before we update Fatdog64 was for kernel 3.11, which, among others, comes with improved power management for radeon cards.
The next release of Fatdog64 will still be based on the 600-series base; this (barring unforeseen circumstances) will be the final release of the series, and expected to last until early next year - thus making the entire series to last about two years from its initial release (which is another Fatdog tradition - Fatdog64 500 series also last for about two years from its initial release).
It is exciting times; we have Fatdog Next running in our system and while we still have to tweak it, things are looking good.
No 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.
1 Comment - Edit - Delete
