Gnome and Fedora-12 on ARM

Here are some screenshots of my kirkwood DB (1.2 GHz and 512 MB RAM, Matrox G550 graphics card) running Gnome. Pretty neat!
I am going to try XFCE desktop over the weekend. Lets see how that goes...

Here is a picture of my setup (taken 6 months ago)
(click to enlarge)

Another awesome Fedora release!

Fedora-ARM 12 is available!

Fedora-ARM 12 is now available.

The RFS is available at:
http://ftp.linux.org.uk/pub/linux/arm/fedora/rootfs/rootfs-f12.tar.bz2

The following package groups are available: Base, Core, Base-X, GNOME-Desktop, XFCE-Desktop, Java, Java-Development, Admin-Tools, System-Tools, Web Server, and commonly used embedded packages.

As usual it is built for ARMv5 EABI, soft-float, little endian.

For more details head to:
http://fedoraproject.org/wiki/Architectures/ARM

kernel and Fedora-ARM

Handling the kernel package on ARM is different than other architectures. Our kernel package typically provides only the kernel-headers. This is because, there are hundreds of ARM boards out there and everyone will use their own optimised and stripped down kernels anyway!

The side-effect of this choice is that there is no kernel package in the rpm database and hence, the packages that Require kernel (about 15 of them) won't have their dependencies satisfied. (Some examples would be, fuse, xorg-x11-drv-ati, pulseaudio, libdrm, etc) Currently, we work around this by changing the Requires on the kernel by Conflicts. Here is a sample patch. (It is obviously not a very elegant solution and any suggestions are welcome)

Now, this isn't much of a problem for packages that just Require kernel. But, now xorg-x11-drv-nouveau Requires kernel-drm-nouveau. It is rare for any ARM kernel to be compiled with nouveau support, so it makes less sense to change this Requires to Conflicts. Ofcourse, we can assume that whoever is trying to use a nVidia card with an ARM board knows what the hell he's doing, but the solution doesn't seem right anyway.

Any suggestions on how this can be handled?

Fedora-ARM: alignment errors

Alignment Errors:
We usually come across a lot of alignment error problems while building packages for Fedora-ARM.

Here is a quick example of the problem:

#define SIZE 20
#define CHARVAL 'a'
#define INTVAL 0x0a0b0c0d
main()
{
     char buffer[SIZE] = { 0, };
     char *p = buffer, c;

     printf("c value = 0x%x\n", CHARVAL);
     printf("i value = 0x%.8x %d\n", INTVAL, INTVAL);

     /* Ok, lets write them in the buffer one after the other */
     *p = CHARVAL;
     p++;
     *(int *)p = INTVAL;

     /* So the buffer should be 0x610d0c0b0a */
     print_hex_string(buffer);

}

The output of this program on x86 machine:

c value = 0x61
i value = 0x0a0b0c0d 168496141
0x610d0c0b0a000000000000000000000000000000
^^^^----------------here

As expected :-)

And on ARM?

c value = 0x61
i value = 0x0a0b0c0d 168496141
0x0d0c0b0a00000000000000000000000000000000
^^^^----------------here

And there goes your value of "c" stored in the array.

These alignment errors are often seen on the ARM architecture. Basically it expects a word to be on a word boundary (last 2 bits should be zero). And if it isn't, well expect the unexpected. As can be seen above the value of c has been completely over-written.

The same goes for pointers as well.

/proc/cpu/aligment:
This file displays the list of alignment errors that have been encountered thus far.

You can echo various flags in this file to change the kernel's behavior when an alignment error is encountered.

• 0: ignore
• 1: warn (/var/log/messages)
• 2: fixup
• 3: signal (core dump for analysis)

For a detailed overview: http://lecs.cs.ucla.edu/wiki/index.php/XScale_alignment

Lots of optimisations

While mass-building for F-11, we realised that there are a lot of areas we can work on to make the build process faster. ARM boards are not as powerful as the i686 machines, so, the actual build time cannot be reduced beyond a certain limit. But, we can increase the throughput. So here's what we've been working on for some days.

1) We got some new builders in the build-pool. Each one has 2 GB RAM and 1200 bogoMIPS processor. So, now we have 8 builders total in the build pool. We hope to add 2 more in some time. With 10 builders, the mass-builds would be much much faster.

2) Eliminate buildSRPMfromSCM tasks. Frankly, they were more of a red-tape. buildSRPMfromSCM is already done on the fedoraproject koji, it would be much much better (and faster) to just pick-up the SRPM and build. So, we wrote wrapper scripts to do just that. This has been of great great help because the boards are always doing some "meaningful" work now.

3) Optimise postgresql database. We vacuumed (fully) the database and reindexed it and it is blazing fast.

4) Also, we have scripts to partially automate analyzing build failures, determining which library sonames have changed upstream so that we need to build them first, etc. The build process is now fairly defined and streamlined.

And we have already started working on the base-set of F-12!

Fedora 11 Status

Since the last announcement of F-11 packages, a large number of packages have further been built. There currently are above 9000 rpms in the Fedora-11 repositories. Our effort has been to make available the following package groups:

Base
Core
Web-server
Gnome Desktop
Xfce desktop
Development Tools
X server
Web development
Admin Tools
System Tools
Java

The Fedora-11 updates for a large set of packages are also now available.

For Fedora-12, we would like to start tracking packages preferably when all the shared lib .so version updates are settled for f12 (thus avoiding any additional rebuild cycles at our end). Most likely this will happen by the Fedora-12 Beta Freeze date (29 Sept, in 3/4 days).

dhclient, firstboot and hald woes ...

In the last 2-3 weeks, I have run into some issues on my ARM board.

1) The first one was the udev-dhclient issue. The basic rootfs from the Fedora-ARM page worked fine for me. But, when I installed some packages, the board refused to reboot. It used to freeze on "Starting udev". After tinkering around a lot with udev, I finally decided debugging udev wasn't my thing. So instead tried to determine which package was causing the problem. After some brute-force and binary search, realised that dhclient was the culprit. After installing dhclient, the board hung at "Starting udev" on the next reboot. Weird. For now, I have just refrained from installing dhclient and everything is working fine. Any one have any ideas about this? (Probably dhclient gets the lease calculation wrong because udev accesses the hardware clock at the same time?)

2) Now firstboot. Its weirder! So, after I installed X and Gnome package group and restarted the board, it used to hang on the login prompt (run level 3). I could key in characters using the keyboard, but hitting return gave no response whatsoever. I couldn't even ssh into the board. At first, I thought it was a system freeze, but I enabled autologin on tty3 and wrote an infinite loop in .bash_profile and it worked fine. Finally, after 1-2 days of wandering off in different directions, the only option that remained was: the keyboard input is losing its way somewhere. So, copied my i386 system's /etc/sysconfig/keyboard to ARM's rootfs. And the system now responded fine to the keyboard input. But, it hung on "password:" prompt. Damn! Finally, realised that I need to run firstboot, so that it configures keyboard and authentication (using pam.d). (Now, as I didn't have a console on this rfs, took the basic working rfs, ran firstboot there and copied the generated configs on the new rfs.) Now things worked fine! firstboot!

3) hald. I still havn't been able to resolve this one. Its been 3 days and I have no headway. Problem is, whenever I start hald, the system just freezes. No I/O, no ssh nothing. A quick infinte loop in .bash_profile suggests that the system has crashed. I have posted the logs and lshal outputs to the mailing lists. Waiting for a reply. Without HAL, my USB mouse and keyboard aren't working in Gnome.

Do leave a message if you face a problem trying something out with your setup ...