Linux Kernel support for UC3 processors

The UC3 processor family is similar to the AP7 family in many respects, but not all. The differences are:

• UC3 implements the AVR32A micro-architecture. The AP7 implements the AVR32B micro-architecture.
• AP7 has instruction- and data-caches. The UC3 doesn't have any caches.
• AP7 has an MMU. The UC3 does not.
• AP7 supports unaligned word-sized loads and stores. The UC3 does not support any unaligned loads and stores.
• Minor differences in which optional parts of the instruction set are implemented.

The below sections provide more details for each of these points, in no particular order. One strategy might be to get Linux to run on the AP7000 with CONFIG_MMU=n first, and then add the bits needed specifically for UC3 to work.

AVR32A micro-architecture support

The AVR32A micro-architecture is different from AVR32B in that, when entering interrupt- and exception handlers, the return context is pushed on the stack instead of being stored in dedicated system registers. This means that the interrupt-, exception- and system call entrypoints must be rewritten. Currently, those are implemented in arch/avr32/kernel/entry-avr32b.S. A new file arch/avr32/kernel/entry-avr32a.S must be added with support for AVR32A-style exception handling.

Caches

The existing kernel code provides several interfaces for flushing the caches:

• The DMA mapping API in include/asm-avr32/dma-mapping.h
• The, uh, other stuff in include/asm-avr32/cacheflush.h

The easiest way to deal with the lack of caches on the uC3 is probably to define the following functions as empty stubs initially:

• invalidate_dcache_line()
• clean_dcache_line()
• flush_dcache_line()
• invalidate_icache_line()

All the other functions that deal with cache flushing are implemented in terms of these. To optimize performance and memory footprint further, other functions may be stubbed out as well.

Support for MMU-less systems

The Linux kernel can be configured without MMU-support by setting the CONFIG_MMU Kconfig symbol to "n". Currently, it is always "y" on AVR32, so this must be made selectable, perhaps through selecting the CPU type. Since the current code has been written based on the assumption that MMU support is always available, some of the existing code probably needs to be made conditional on CONFIG_MMU.

Unaligned memory access

Some of the AVR32 code in the Linux kernel assumes that unaligned word accesses are ok. This includes the memcpy() implementation, so it must be slightly modified to work on the UC3.