Port to Atmel AVR RISC processor

[Ralf Corsepius]

Am Don, 2003-03-06 um 01.18 schrieb Joel Sherrill:
> David Dudley wrote:
> 
> >Has anyone attempted to port rtems to the Atmel AVR chip family?
> >
> >Looks like I'm going to have a requirement for one, so if no one has .... 
> >well, its started.
> >
> >
> >Got a question, or two before getting started, though:
> >
> >1. The "Porting" guide doesn't reflect the structure of the RTEMS directory, 
> >but rather, the 'build' directory, from what I've seen.  Is there a document 
> >that describes the source directory, and what goes where (and where things 
> >are to start with??? )?
> >  
> >
> 
> Please point out those differences so they can be fixed.  The 
> rearrangement of the
> source tree to separate BSPs and ":CPU Kit" many not be reflected.  In 
> general,
> you are looking at the directories:
> 
>   cpukit/score/cpu/XXX
>   c/src/lib/libcpu
>   c/src/lib/libbsp
> 
> >2. How do the libbsp/libcpu directories get built into the "build" directory?  
I don't understand this question. The build-directories are set up when
running the configure-scripts. 

> >It appears that files are actually copied from one place to the other -
Yes and no. Most of the files you see inside of the build-directories
are generated from files in the source-directories. However, some files
actually are copied when running "make". 

> >what/how are the files determined, and why didn't you just use symbolic 
> >links?
For those files which actually get copied, we could use sym-links
instead, but it once had been decided to avoid the typical problems
related to sym-links by copying the files instead.

> I will let Ralf go on this one.  It really isn't as radically different 
> as it looks though.
Well, when looking at "cpukit" from the distance, the cpukit/ is 
* "c/src/exec" has been renamed to cpukit/ 
* some other subdirs formerly in "c/src/" have moved to cpukit/

When looking at it closely, many things have changed fundamentally.

> >3. in the cpukit directory, is the file structure 'reflected' into the build 
> >directory somehow? ... and if so.... how?
autoconf magic :-) (To be found in the toplevel configure.ac and
c/src/configure.ac)

Currently, the cpukit can be built in 3 ways:

1. Per-BSP. This is the default and is what most people currently do.

The "cpukit/" directory of the source-tree will be built inside of the
"<target>/c/<BSP>/exec" directory inside of the build-tree. This results
into using the same build-directory layout as previous RTEMs releases.

2. Multilib'ed:  (RTEMS is configured w/ --enable-multilib).

The "cpukit/" directory of the source-tree will be build as
"<target>/cpukit" inside of the build-tree and multilib subdirs
neighboring and below this directory. (cpukit will be built several
times, one time each for each multilib-variant). 
This is the multilib building scheme applied by gcc/newlib and other
packages.

3. Stand-alone with or without multilib. This allows separating BSPs
from "RTEMS core" and shall allow shipping binaries of "RTEMS core" in
future to "release users from the burden of having to build it
themselves".

> >4. What "*.ac" files need to be modified to add the new architecture into the 
> >package?

To add a new architecture:
aclocal/rtems-cpu-subdirs.m4
cpukit/aclocal/rtems-cpu-subdirs.m4

You will also have to populate
cpukit/score/cpu/<cpu>

Having implemented these you should be able to build cpukit for a new
architecture standalone.


You probably will also want to populate (at present time this is
optional):
c/src/lib/libcpu/<cpu>


And add one or more BSP:
c/src/lib/libbsp/<cpu>/<bsp>
make/custom/<bsp>.cfg


Ralf