Meiring, H, Mnr | 9 Apr 14:10 2007
Picon
Picon

Guidance porting AT91sam7


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

Meiring, H, Mnr | 9 Apr 14:18 2007
Picon
Picon

Guidance porting AT91sam7


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

(Continue reading)

Andrew Lunn | 9 Apr 14:40 2007
Picon

Re: Guidance porting AT91sam7

On Mon, Apr 09, 2007 at 02:10:57PM +0200, Meiring, H, Mnr <meiring <at> 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
>  =

(Continue reading)

Meiring, H, Mnr | 9 Apr 17:09 2007
Picon
Picon

RE: Guidance porting AT91sam7


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 <at> ecos.sourceware.org on behalf of Andrew Lunn
Sent: Mon 4/9/2007 2:40 PM
To: Meiring, H, Mnr <meiring <at> sun.ac.za>
Cc: ecos-devel <at> ecos.sourceware.org
Subject: Re: Guidance porting AT91sam7

On Mon, Apr 09, 2007 at 02:10:57PM +0200, Meiring, H, Mnr <meiring <at> 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
(Continue reading)

Nick Garnett | 10 Apr 12:18 2007

Re: Guidance porting AT91sam7

"Meiring, H, Mnr <meiring <at> sun.ac.za>" <meiring <at> 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.
(Continue reading)

Maxin B John | 19 Apr 16:39 2007
Picon

Trouble with redboot on SPANSION S29GL512N


Dear all,

  I have compiled ECOS to support AMD/SPANSION S29GL512N  flash for EP9301 .
I have compiled the the redboot.bin but on booting , the system hangs. 
The flash_am29xxxxx_parts.inl is modified like this

#ifdef CYGHWR_DEVS_FLASH_AMD_S29GL512N
{
//AMD/SPANSION S29GL512N 
long_device_id:true,
device_id: FLASHWORD(0x227e),
device_id2: FLASHWORD(0x2223),
device_id3: FLASHWORD(0x2221),
block_size:0x20000 * CYGNUM_FLASH_INTERLEAVE,
block_count:512,
device_size:0x4000000 * CYGNUM_FLASH_INTERLEAVE,
base_mask:~(0x4000000 * CYGNUM_FLASH_INTERLEAVE-1),
bootblock : false,
banked :false,
},
#endif

Please let me know if anyone had successfully compiled the redboot with 
SPANSION S29GL512N with EP9301.

Thanks & Regards,
Maxin B. John
--

-- 
View this message in context: http://www.nabble.com/Trouble-with-redboot-on-SPANSION-S29GL512N-tf3607401.html#a10078647
(Continue reading)

Gary Thomas | 19 Apr 16:52 2007

Re: Trouble with redboot on SPANSION S29GL512N

Maxin B John wrote:
> Dear all,
> 
>   I have compiled ECOS to support AMD/SPANSION S29GL512N  flash for EP9301 .
> I have compiled the the redboot.bin but on booting , the system hangs. 
> The flash_am29xxxxx_parts.inl is modified like this
> 
> #ifdef CYGHWR_DEVS_FLASH_AMD_S29GL512N
> {
> //AMD/SPANSION S29GL512N 
> long_device_id:true,
> device_id: FLASHWORD(0x227e),
> device_id2: FLASHWORD(0x2223),
> device_id3: FLASHWORD(0x2221),
> block_size:0x20000 * CYGNUM_FLASH_INTERLEAVE,
> block_count:512,
> device_size:0x4000000 * CYGNUM_FLASH_INTERLEAVE,
> base_mask:~(0x4000000 * CYGNUM_FLASH_INTERLEAVE-1),
> bootblock : false,
> banked :false,
> },
> #endif
> 
> Please let me know if anyone had successfully compiled the redboot with 
> SPANSION S29GL512N with EP9301.

Make sure your memory map (which on ARM includes some
assembly tables) have been adjusted to handle the FLASH.
If they are not able to handle the entire size (64MB in
this case), then RedBoot will hang/die.
(Continue reading)

Maxin John | 20 Apr 07:12 2007
Picon

Re: Trouble with redboot on SPANSION S29GL512N

Dear Gary Thomas,

 Thank you very much. But I am a bit consfused. I would like to know
where I need to modify that. So how user can change the memory layout
if he wants to change ?
   I not sure  that I am suppossed to change the *.ldi  files. So am I
suppossed to change the  size in  *.h or *.mlt file and recompile
again ?

Thanks & regards,

Maxin B. John

On 4/19/07, Gary Thomas <gary <at> mlbassoc.com> wrote:
> Maxin B John wrote:
> > Dear all,
> >
> >   I have compiled ECOS to support AMD/SPANSION S29GL512N  flash for EP9301 .
> > I have compiled the the redboot.bin but on booting , the system hangs.
> > The flash_am29xxxxx_parts.inl is modified like this
> >
> > #ifdef CYGHWR_DEVS_FLASH_AMD_S29GL512N
> > {
> > //AMD/SPANSION S29GL512N
> > long_device_id:true,
> > device_id: FLASHWORD(0x227e),
> > device_id2: FLASHWORD(0x2223),
> > device_id3: FLASHWORD(0x2221),
> > block_size:0x20000 * CYGNUM_FLASH_INTERLEAVE,
> > block_count:512,
(Continue reading)

Gary Thomas | 20 Apr 13:53 2007

Re: Trouble with redboot on SPANSION S29GL512N

Maxin John wrote:
> Dear Gary Thomas,
> 
> Thank you very much. But I am a bit consfused. I would like to know
> where I need to modify that. So how user can change the memory layout
> if he wants to change ?
>   I not sure  that I am suppossed to change the *.ldi  files. So am I
> suppossed to change the  size in  *.h or *.mlt file and recompile
> again ?

The current files (as provided by Cirrus) only map 16MB for FLASH.
You'll need to make adjustments in 3 places to handle your 64MB device.
   hal/arm/arm9/ep93xx/v2_0/include/pkgconf/mlt_arm_arm9_edb9301_romram.h
   hal/arm/arm9/ep93xx/v2_0/include/pkgconf/mlt_arm_arm9_edb9301_romram.ldi
   hal/arm/arm9/ep93xx/v2_0/include/hal_platform_setup.h
> 
> On 4/19/07, Gary Thomas <gary <at> mlbassoc.com> wrote:
>> Maxin B John wrote:
>> > Dear all,
>> >
>> >   I have compiled ECOS to support AMD/SPANSION S29GL512N  flash for 
>> EP9301 .
>> > I have compiled the the redboot.bin but on booting , the system hangs.
>> > The flash_am29xxxxx_parts.inl is modified like this
>> >
>> > #ifdef CYGHWR_DEVS_FLASH_AMD_S29GL512N
>> > {
>> > //AMD/SPANSION S29GL512N
>> > long_device_id:true,
>> > device_id: FLASHWORD(0x227e),
(Continue reading)

Maxin John | 20 Apr 14:33 2007
Picon

Re: Trouble with redboot on SPANSION S29GL512N

Dear Gary Thomas,

 I have modified the files as given below..

romram.h

#include <cyg/infra/cyg_type.h>
#include <stddef.h>

extern unsigned long SDRAMSize;
#define CYGMEM_REGION_ram (0)
#define CYGMEM_REGION_ram_SIZE (SDRAMSize)
#define CYGMEM_REGION_ram_ATTR (CYGMEM_REGION_ATTR_R | CYGMEM_REGION_ATTR_W)
#define CYGMEM_REGION_rom (0x60000000)
#define CYGMEM_REGION_rom_SIZE (0x1000000)
#define CYGMEM_REGION_rom_ATTR (CYGMEM_REGION_ATTR_R)
extern char CYG_LABEL_NAME (_heap1) [];
#define CYGMEM_SECTION_heap1 (CYG_LABEL_NAME (_heap1))
#define CYGMEM_SECTION_heap1_SIZE (CYGMEM_REGION_ram_SIZE - (size_t)
CYG_LABEL_NAME (_heap1))

romram.ldi

MEMORY
{
    ram : ORIGIN = 0, LENGTH = 0x10000000
    rom : ORIGIN = 0x60000000, LENGTH = 0x1000000
}

SECTIONS
(Continue reading)


Gmane