This is the mail archive of the ecos-devel@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Guidance porting AT91sam7


On Mon, Apr 09, 2007 at 02:10:57PM +0200, Meiring, H, Mnr <meiring@sun.ac.za> wrote:
> 

> Hi, I am attempting a port of an ATMEL AT91SAM7A2 uP.

I think there is somebody else working on a port for this
processor. Check the archives and try to coordinate your efforts.
 

> The sam7s and sam7x ports seems the closest to what I need (but
> still = with quite a few differences).=20 With starting this port I
> would like some guidance in the format that = the port must be
> according to =93your=94 standards with regards to = directory
> structure and which layers to implement. The current structure = is
> as follows with my recommendations next to them: =20

> ARM arch layer	- great keep as is

> AT91 var layer =96 this layer contains a lot of platform specific
> info = specifically for AT91SAM7 series (for instance in var_io.h )
> =96 why = here, can=92t it be moved to the platform specific source
> (plf_io.h)? Or = shall I rather=20 say how must I approach this to
> get the anonymous sources changed? I = think it will make things
> more structured and when I want to port the =

> AT91SAM7A2 series I only need to do platform changes and not variant
> = changes as well.

> AT91SAM7S - How do you want the directory structure and why call the
>  =

> directory at91sam7s (and not at91sam7) when the x series is
> implemented = in it as well and the variant name it resides under is
> at91sam7=20 (CYGPKG_HAL_ARM_AT91SAM7). Now must the new port be made
> alongside the = at91sam7s platform or completely independent from
> the existing port? How = must this be done so that they will add the
> new port to the anonymous = cvs format wise etc?

I made of bit of a mess when i added the SAM7S port. I did not look at
the AT91SAM7X processors and see that it is basically the same
processor with Ethernet and CAN added. So the directory naming is not
very logical. However the CDL naming is more generic. 

The way it works is that the var_io.h contains register definitions
for anything which is shared by AT91SAM devices. This should all be
generic. The only exception to this is the pin definitions. Ideally
they should be moved in the platform HAL, but for the moment place
them in var_io.h. One day i might clean this up. 

Take a look at the code in the at91sam7s directory. Is the code in
at91sam7s_misc.c and hal_platform_setup.h valid for your system? How
are the interrupts arranged? Are they nearly identical to what is in
hal_platform_ints.h? Or do you need to add a lot of #ifdef's?
Hopefully you can just use the at91sam7s code with a few minor
changes.

You need to add an at91sam7a2ek directory which contains code specific
to the development board. There tends to be very little in this
directory, just code for the LED and maybe to initialise the Ethernet
PHY.

        Andrew


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]