Guidance porting AT91sam7

Guidance porting AT91sam7

[Meiring, H, Mnr <meiring@sun.ac.za>]

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

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

ARM arch layer  - great keep as is

AT91 var layer – this layer contains a lot of platform specific info specifically for AT91SAM7 series (for instance in var_io.h ) – why here, can’t it be moved to the platform specific source (plf_io.h)? Or shall I rather
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
(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?

Can anyone give me some guidance on how to attempt this specific port? 

Regards
Hendrik Meiring
MScEng student at the University of Stellenbosch
South Africa

Re: Guidance porting AT91sam7

[Nick Garnett]

"Meiring, H, Mnr <meiring@sun.ac.za>" <meiring@sun.ac.za> writes:

> The at91sam7a series seems to be an combination of the 7s and 7x
> series- basically the 7s with an ebi (my view may change as I look
> at more detail). There is however differences with the startup, the
> 7a series have a clock manager that handles that, so the platform
> setup should change a bit. The interrupts seems to be fairly
> similar, but i will first try to get redboot working and then worry
> about interrupts.
> 
> I will have a look and shout if I have q's

Be warned that there be dragons here. I added SAM7A series support to
the eCosCentric source tree a little while ago. It was not nice. The
A1 and A2 devices are SAM7's in name only. They differ in lots of ways
from the S and X series, and from the earlier AT91 parts; there are
almost no functional units that remain identical and some, like the
PDC and PIO are very weirdly different. I suspect that they are odd
parts that have been shoehorned into the SAM product line as a
marketing exercise, there is certainly no technical reason for it.

There is further confusion because the SAM7A3 *does* share most
functional units with the S and X series.

I suspect that the A1 and A2  may be discontinued fairly quickly. So
think hard about whether you really want to use the A2. You will be
much better off using an S or X series part, or the A3.


And, of course, eCosCentric can offer you a working port if you want
to save yourself a lot of grief.


-- 
Nick Garnett                                     eCos Kernel Architect
eCosCentric Limited     http://www.eCosCentric.com/   The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.    Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.

RE: Guidance porting AT91sam7

[Meiring, H, Mnr <meiring@sun.ac.za>]

The at91sam7a series seems to be an combination of the 7s and 7x series- basically the 7s with an ebi (my view may change as I look at more detail). There is however differences with the startup, the 7a series have a clock manager that handles that, so the platform setup should change a bit. The interrupts seems to be fairly similar, but i will first try to get redboot working and then worry about interrupts. 

I will have a look and shout if I have q's

Thanks

-----Original Message-----
From: ecos-devel-owner@ecos.sourceware.org on behalf of Andrew Lunn
Sent: Mon 4/9/2007 2:40 PM
To: Meiring, H, Mnr <meiring@sun.ac.za>
Cc: ecos-devel@ecos.sourceware.org
Subject: 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

Re: Guidance porting AT91sam7

[Andrew Lunn]

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

Guidance porting AT91sam7

[Meiring, H, Mnr <meiring@sun.ac.za>]

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

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?

Can anyone give me some guidance on how to attempt this specific port? =20

Regards
Hendrik Meiring
MScEng student at the University of Stellenbosch South Africa