Welcome to AVR32 Linux... Users Groups

Linux on UC3 processors

While the mainline Linux kernel has had support for AVR32 AP7 processors since version 2.6.19, it still has no support for the AVR32 UC3 family of processors. There are no technical limitations preventing Linux from running on UC3, given enough RAM and flash storage, but there are some fundamental differences between the AP7 and UC3 platforms that need to be handled in software before you can have a fully functional Linux system running on your UC3. This page, along with a few others linked to from here, intends to explain what those differences are and provide some hints on how to handle them.

In order to boot a Linux system, you need the following pieces of software:

  • A boot loader. DasUBoot is currently the only boot loader capable of loading AVR32 Linux.
  • The LinuxKernel. Obviously.
  • A toolchain capable of generating "flat" binaries. On AP7, ELF binaries are used, but the Linux ELF loader does not support systems without an MMU. The AP7 core includes an MMU, the UC3 core does not.
  • LinuxApplications. This is the easy part, once all the other pieces are in place. But picking out a set of applications that is useful on specific UC3-based development boards is still a task that needs to be done.

Boot loader

For details on what needs to be done to get DasUBoot running on UC3, please see the UBootOnUC3 page. The latest patchset was posted here:

Linux Kernel

For details on what needs to be done to get the LinuxKernel running on UC3, please see the LinuxKernelOnUC3 page. The latest patchset was posted here:

Development tools

Binary format support

The binfmt_elf loader in the Linux kernel relies heavily on demand-paging in order to get the program binary loaded into RAM. By relying on the virtual memory subsystem to actually load the program binary image into memory, the startup time is reduced and physical memory can be shared between different processes, but it obviously does not work on systems which don't have a Memory Management Unit (MMU).

When an MMU is not available (or turned off for some reason), most architectures seem to use the "flat" binary format (binfmt_flat.) This requires an extra utility, elf2flat, to convert from the ELF files generated by the avr32-linux GNU toolchain into the flat binary format.

Some architectures, notably FR-V and Blackfin, offer an alternative: ELF FDPIC. From a quick scan, it looks like it offers some advantages compared to the flat format, mainly that it allows text segments to be shared between different processes without sharing the data segments. This is the alternative chosen in the above implementation.

The GNU Toolchain

The avr32-linux target of GCC and Binutils should work on UC3 as well, provided multilib support is turned on. UC3 Linux applications (as well as the kernel and u-boot) must be compiled with "-march=uc".

GCC and/or Binutils needs some work in order to generate position-independent executables suitable for the elf2flat tool, or ELF FDPIC binaries if the other alternative is used. Patches adding support for FDPIC were posted here:

uClibc

uClibc works mostly as-is, but it needs some adjustment to the configuration files to make it possible to select a configuration without MMU support, and to make the FDPIC format available. Some modifications to the startup and system call code was needed as well, and the string operations needed a few changes because the UC3 core doesn't support unaligned word access. The patch making these changes can be found here:

Linux Applications

Most existing Linux applications should work out of the box when the kernel- and toolchain support is in place. But it would be nice to have a set of applications that is considered useful on various UC3-based kits, in the form of a default buildroot configuration, for example.

r5 - 2011-09-09 - 14:53:39 - HansChristianEgtvedt
Copyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Linux® is the registered trademark of Linus Torvalds in the U.S. and other countries.
Atmel®, AVR® and others are registered trademarks or trademarks of Atmel Corporation or its subsidiaries.
All other trademarks are the property of their respective owners.
Syndicate this site RSSATOM