XWindows

Use Buildroot!

Buildroot is the recommended method to build X Windows for AVR32, but I will leave the following information as a technical reference or for those who would prefer to, or must, build it by hand.

Binaries for the impatient...

Here are all of the files required to upgrade a NGW100 to run X Windows.

Download, combine and extract the PART A and PART B files below and copy the extracted files to an ext2 formatted SD card. Create three partitions on the SD card. Partition 1 will be the /usr filesystem, it has to be at least 200MB and formatted with ext2. Partition 2 will be swap space, make it 32MB. Partition 3 is used for the USB mass storage driver and can be formatted with any filesystem you want and can be any size. The root password is: roota. It is setup to start with a 640x480x16 display. If you need a different resolution, use fbset or recompile the kernel with a different screen resolution. The init scripts are also setup to run synergy automatically so you can use your desktop's mouse and keyboard. Just install synergy on your desktop and edit /etc/init.d/S52synergy on the NGW100 to change the ip addresses.

Combine and extract the /usr archive like this:

cat ngw100-base-sdcard-parta ngw100-base-sdcard-partb > ngw100-base-sdcard.tar.bz2
tar -xvf ngw100-base-sdcard.tar.bz2 --directory /path/to/mounted/sdcard

* ngw100-base-sdcard-parta: X.org binary for AVR32 (PART A)

* ngw100-base-sdcard-partb: X.org binary for AVR32 (PART B)

The next two files are the root filesystem and the JFFS2 image for the NGW100. The image can be installed by following the instructions here or if you mount the SD card as root, you can combine the root filesystem with the /usr archive located above.

* atngw100_root.tar.bz2: Root file system for NGW100

* atngw100_root.img.bz2: JFFS2 root image for NGW100 with busybox 1.8.2

The next file is a pair of u-boot images, there is an installer script included. Copy the files to your SD card and run the shell script on the NGW100. Updating u-boot is optional, but can be done to boost your clock speed a bit. It can also render your board un-bootable, requiring a JTAGICE-mkII to reflash it. So be careful doing this.

* atngw100-uboot.tar.bz2: u-boot 1.3.0.atmel.2 images for NGW100 (140MHz and 200MHz versions)

Building X Windows for AVR32

Here you will find a complete X.org 7.3 build tree with shell scripts to automate the build for the AVR32. It includes all of the required dependencies, fluxbox, blackbox, and twm window managers, all of the usual X.org applications, and the rxvt shell console.

The archive file was split because the wiki only allows attachments up to 65 Megs. The command I used to split it was:

split -b 60000k xorg-7.3-avr32.tar.bz2

You can recombine the files and extract the tree like this:

cat xorg-7.3-avr32.parta xorg-7.3-avr32.partb > xorg-7.3-avr32.tar.bz2
tar -xvf xorg-7.3-avr32.tar.bz2

The README file explains the usage. When the build is finished, just copy the contents of /usr/avr32-linux to an SD card mounted at /usr on your AVR32 board.

I also highly recommend upgrading your kernel to 2.6.22.atmel.4 if you have not done so already. Here are instructions on how to build a new kernel, and here is my own patch and config set for the NGW100. It includes setup for the LCDC and the stable kernel preemption patch.

Once you have it installed, you can start it by either: X -ac -noreset & or Xfbdev -ac -noreset & X is a symbolic link to Xfbdev.

The -ac turns off access control if you want to connect to the X server remotely, and -noreset keeps X from dying if no apps are open.

Also, if you enter export DISPLAY=:0 you don't have to add the -display flag to applications when starting them.

* xorg-7.3-avr32.parta: First part of X.org 7.3 build tree

* xorg-7.3-avr32.partb: Second part of X.org 7.3 build tree

* Screenshot from NGW100:

* Screenshot from NGW100:

The following information documents the process I went through to port everything.

Hardware

1. You will need to have a kernel installed that provides the framebuffer device (/dev/fb0) and the framebuffer console (/dev/tty0). You will also need at least 500Mb of filesystem space. An easy solution to this is a 1Gb or larger SD flash card mounted at /usr. And obviously, you will need video display hardware attached to your AVR32 LCDC in the form of either a video DAC IC, or an LCD panel.

Software

1. First, make sure you have the AVR32 GNU toolchain installed on your development system.

2. The config.guess and config.sub need to be updated in all of the X.org packages. Get those files here and here.

3. After replacing config.sub and config.guess, you must do the following:

aclocal
automake --foreign
autoconf

If there were any failures in this step, you must have a missing m4 macro on your machine. Take note of the name in the prefix of the reference error and find the related package's source code. Google is helpful here. Find the m4 macro file that contains the missing reference in that source package. Copy that m4 macro file to /usr/share/aclocal, then repeat the above steps.

4. You will occasionally find that ./configure fails in some packages because a test program tries to run, but fails because you are cross compiling. As my patch set collects below, this problem should disappear. In the mean time, if you want to start on your own, there are two methods of dealing with this.

Method A (preferred):

Create a text file called config.cache in your source directory. When ./configure fails, take note of the message. For example, the glib-2.12.13 package will fail with this error:

checking for growing stack pointer... configure: error: cannot run test program while cross compiling 

Open the configure script with your favorite text editor and search for "growing stack pointer". In this example it can be found here:

echo $ECHO_N "checking for growing stack pointer... $ECHO_C" >&6; }
if test "${glib_cv_stack_grows+set}" = set; then 

See the line that starts "if test"? The variable referenced is what we are looking for, "glib_cv_stack_grows". You will need to add this reference to your config.cache file like so:

: ${glib_cv_stack_grows=yes}

The values of these results can usually be guessed, or you can build the package for your development machine and see what the typical result is (probably bad advice!). You may even try to compile and run the test program on the AVR32 in some cases. This would be the safest, but most difficult alternative.

Now you can run ./configure again with the command line switch -C, this tells configure to use the results in the config.cache file instead of running the test program.

Method B (when all else fails):

Delete the section of the configure script that fails, paying attention to any definitions that need to be set during that section. Make sure to define those variables, and run configure again.

After configure successfully completes, you can run make.

5. Make failures. You will occasionally have make failures because a utility program is built by the AVR32 compiler and then the build machine attempts to execute it. The trick I used, was to build the offending package for the development machine, then rename the utility program's executable file to executable.host. After that, just open the makefile that runs the utility program and change the reference to "executable.host". Now make will build the utility for the AVR32, but execute the host program instead. Problem solved.

6. When you finish building a package, install it like this:

make install DESTDIR=/

These steps should work in most cases. If you find any other tricks, feel free to update this wiki!

Performance Statistics

Currently, on my NGW100:

Memory at boot:

              total         used         free       shared      buffers
  Mem:        25628         5604        20024            0           72
 Swap:            0            0            0
Total:        25628         5604        20024

After starting X:

              total         used         free       shared      buffers
  Mem:        25628        14380        11248            0          328
 Swap:            0            0            0
Total:        25628        14380        11248

That's roughly 9Mb of memory consumed by X.

CPU usage:

  PID USER     STATUS   RSS  PPID %CPU %MEM COMMAND
  371 root     R        340   359  1.3  1.3 top
  361 root     S <     3448   360  0.0 13.4 X
  368 root     S       1480   360  0.0  5.7 xterm
  360 root     S        492   359  0.0  1.9 xinit
  359 root     S        404     1  0.0  1.5 sh
    1 root     S        312     0  0.0  1.2 init
  342 root     S        232     1  0.0  0.9 dropbear
  350 root     S        212     1  0.0  0.8 inetd
  228 root     S        204     1  0.0  0.7 syslogd
  238 root     S        180     1  0.0  0.7 klogd
  328 root     S        116     1  0.0  0.4 udhcpc
  261 root     SW<        0     2  0.0  0.0 mmcqd
  175 root     SWN        0     2  0.0  0.0 jffs2_gcd_mtd1
    6 root     SW<        0     2  0.0  0.0 khelper
   45 root     SW<        0     2  0.0  0.0 kblockd/0
    5 root     SW<        0     2  0.0  0.0 events/0
  248 root     SW<        0     2  0.0  0.0 kmmcd
    4 root     SW<        0     2  0.0  0.0 watchdog/0
    2 root     SW<        0     0  0.0  0.0 kthreadd
    3 root     SWN        0     2  0.0  0.0 ksoftirqd/0
   47 root     SW<        0     2  0.0  0.0 kseriod