at91 SoC separation

Sylvestre Gallon ccna.syl at
Sun May 24 19:31:19 UTC 2009


I am currently working on the at91sam9261ek port for the
Google Summer Of Code 2009.

Currently I work on how I could implement the at91sam9261ek
most efficiently. I notice that all the at91 code could be at91
System On Chip independent with some few changes.

The big work is to extract the SoC specific code in a separate file
by SoC. It's what I tried to do on my perforce :

perforce repo :

Changes that I've done :!

One thing that continues to disturb me : On At91 SoC, the IPs and
their registers are quite the same. The only big change that exists
between these SoC are the base addresses for each IPs.  The different
SoC generic drivers may need IPs base addresses to perform the
mapping of registers. For the moment to not have some ugly
#ifdef like :

#ifdef __AT91RM9200__
#include <at91rm92reg.h>
#elif __AT91SAM9261__
#include <at91sam9261.h>
#elfi __ANOTHER_SOC__
#include <another_soc.h>

I have created base address accessors in the SoC file. But I'm not
sure I like that... Do you have some ideas to handle it in a better
way ?

When All the code of at91 will be SoC independents It will be very
easy to port any other at91 board (1 or 2 days of work by cpu).
I have also access to a lot of atmel board, I live near Atmel French
R&D  and know some people who work there who are ready to lend
me boards with these SoC :

- at91sam9260
- at91sam9261
- at91sam9263
- at91sam9rl
- at91sam9m10 (not officially out, and not yet in Linux ;) )
- at91cap9
- ..

I'am open to all suggestions, it is important for me to implement
the at91sam9261ek (and perhaps other) port the best way I can
to have a chance to see it in current after the Google Summer Of
Code :)


Sylvestre Gallon (
Fifth Grade Student @ Epitech & Researcher @ LSE
R&D @ Rathaxes (

More information about the freebsd-arm mailing list