FatdogArm on Tablet
Fatdog Arm reaches another milestone today - it is now capable of booting straight to desktop. Booting to command line only takes 5 seconds (that includes the 3 second wait for SD card media to be recognised), booting to full desktop takes about 25 seconds (may be because of slow SD card, gzip decompression, etc). Once in the desktop, the applications are zippy (they are a bit sluggish to start but once running, works fast). We're talking the entire build here - nothing cutdown yet, all the 450MB gzip-compressed SFS goodness with all the toolchains, headers, static libraries, and what have you.As a bonus, I put the same stuff on the micro SD card for the ARM tablet I mentioned in the previous post, and here is the picture of that tablet running Fatdog Arm.
Unfortunately, I am going to lose that tablet soon (my mum is going on a trip and she will take that tablet with her).
But yes, apart from that, I am excited !!
Comments - Edit - Delete
Media player done
I've built the media player - Xine - for Fatdog Arm, along with all the usual codecs etc. It plays SD video nicely upscaled to 720p, though I do notice some hesitation and a little stuttering on the more complex scenes. HD video not so good, the lag and frame drop is very noticeable. Please note that this is purely software rendering (using hardfloat and in some cases NEON optimisation); the A10 video acceleration is not used at all. All in all - not so bad for something that uses only 2 watts.This is the final software package I planned for Fatdog Arm, after this I'm going to look at package management and Fatdog system scripts.
And one more thing - I bought a tablet for my mum which happens to use A10. I managed to boot that tablet - linux console and all - from the same boot image that I've been using for Mele (only changing the script.bin!). How exciting! I should attach a photo of that here.
Comments - Edit - Delete
FatdogArm progress
Fatdog Arm reaches another milestone today, with most of the applications planned for it ready: abiword, gnumeric, web browser (seamonkey en-GB), osmo, evince, calcoo, gftp, and openssh. The only major thing left is the media player and package management (and may be a few others while I'm at it).I've also updated another relatively minor article about building applications in case you are interested.
Comments - Edit - Delete
Building localised Seamonkey web browser
I spent 3 days building Seamonkey on the ARM platform. Each build took between 15 to 18 hours. The first build was actually successful, but I wanted to try making a localised build (en-GB instead of the default en-US) and while doing that I forgot to test the Lightning calendar add-on. When I finally did the test I found that it didn't work, but I reasoned that could be because I had files mixed up between the old and new half-baked compile.So I wiped off and started again; this time with localised build from the beginning. Well, whaddayaknow, this second build failed halfway many times - firstly, it was missing localisation files (but ... but I thought it was part of the source tarball like many other packages!); and then bad localisation files (the web is littered with wrong advice on which localisation tarball to use). The one that seems most accurate is to pull directly from Mercurial repository; this will include the tool to automatically check-out the locale files too --- except that I don't want to build bleeding edge, I want to build a release-build version!
I almost abandoned my localised build when I finally tied up the all the clues and managed to find the location of the correct tarball. So the third build went on smooth, another 18 hours clocked on my little poor ARM box. This one finally built cleanly, I've got the en-GB binary tarball at the end.
The calendar, however, still didn't work. It always said that it isn't compatible with this version of seamonkey, which is odd for the fact it is built together with the rest. For a note, a similar built on x86_64 a while ago worked perfectly. It is definitely not the version numbering as the numbering is correct. Anyway, after spending 3 consecutive days on that stuff the ARM (and myself) is getting tired actually so I'll let that go for the moment - at least I get my en-GB built done!
To make sure that others don't have to spend 3 days building their localised Seamonkeys, I've written the detailed steps of how to do so on my wiki, here. While the instruction is meant for Seamonkey, it is trivial to adapt it to build localised Firefox too.
Enjoy.
Comments - Edit - Delete
Building the toolchain article
While waiting for the Seamonkey browser to finish its compilation (a process that takes about 15 hours), I've decided to write the article about building your own toolchain from scratch - not using Aboriginal's or Linaro', and it is now online here.The entire NativeCompiler build on ARM took me more than 2 days. The entire build of that my own cross-and-native compiler build takes a tad more than 2 hours. Which makes Aboriginal's qemu+ditscc method becomes more and more appealing everyday.
Comments - Edit - Delete
FatdogArm now runs Fatdog desktop!
Which consist of openbox, lxpanel, and ROX Filer. We are getting there! RoadMapComments - Edit - Delete
FatdogArm now runs Xorg!
FatdogArm reaches its first milestone - it is now running X desktop! Sure the only apps available is xterm and xclock, but that's a good start
On the down side, kernel 3.11 is now in rc3; but linux-next still shows no sign that XFS will be compatible with user namespace anytime soon (the UIDGID_CONVERTED still makes XFS = n)
Comments - Edit - Delete
Native compiler article is up
Chapter 6 of LFS is done, I now have a usable command-line root filesystem; and that's the end of LFS for me (I don't need the rest of the chapters on booting and initscripts because I can already boot the system and I already have initscripts from Fatdog).I'm now on the first item on my (revised) roadmap - building Xorg packages.
Meanwhile, I have written the article on preparing the hard-float native compiler here.
Comments - Edit - Delete
FatdogArm initrd article is up
I'm now at the middle of LFS Chapter 6. I have completed the final distribution-ready hardfloat native compiler (with the proper name this time - arm-unknown-linux-gnueabihf) and am using it to build the rest of the packages in Chapter 6.While waiting for them to build, I managed to write the next article about using initrd with the ARM build here.
Comments - Edit - Delete
Native compiler working
I have completed Chapter 5 of LFS and have a working hard-float native compiler. I am now at early steps of Chapter 6, working my way towards getting distribution version of the toolchain. Looking good!And 1Hz of ARM cycle is definitely not worth 1Hz of x86 cycle. My 1GHz A10 feels like 600 MHz Celeron
Took me 3.5 hours to build gcc and I had to do it a couple of times since LFS is well, not exactly targeted towards ARM - plus I changed direction from the default soft-float to hard-float in the middle of the compile --- and I had to do that 5 times
This is looking more and more attractive now, but I'm a little tight with the budget right now so that'll have to wait.
I'm logging the final installs with paco. I'm still considering what package management to use, since paco doesn't support pulling packages from remote location (paco and gpaco is for managing local packages only). I have slapt-get and gslapt in mind, but I will have to think further.
Comments - Edit - Delete
