Martin Thomas wrote:
> Dimitar Alexandro wrote:
>> I'm looking for a linker script for AT91SAM7S128, or for a HOWTO about
>> these scripts. I wish not to loose too much time with this, that is why
>> a ready to be used script will help me a lot, but on the other hand it
>> is useful to know how to create it by myself.
>> I alredy have linker scripts for AT91SAM7S64 and AT91SAM7S256, from the
>> WINARM package.
>> BTW, many thanks to Martin Thomas for the WINARM package and especially
>> for the examples.
>> By comparing the two scripts (for the 64 and 256 flash version), using a
>> difference viewer, I see that only a few lines needs to be modified, but
>> still can't understand it :(
>>
>> Does someone knows any hints that could help me?
>
> Basicly the only difference between the linker-scripts for the different
> AT91SAM7 are the settings for the memory-sizes. But there are currently
> different approaches implemented in the examples. Again: sorry, I don't
> have the time to keep all examples up-to-date, I just check if the
> examples still work with an new WinARM release). Currently I use the
> files from the gamma-example as base for my own AT91 developments, this
> example is already prepared for SAM7S64 and SAM7S256, to add
> AT91SAM7S128-support. It may be easier to modify a single script but
> with the gamma-example support for different controller is already
> prepared so I try to explain the more complicated but more flexible
> method here:
>
> * change SUBMDL in Makefile: SUBMDL = AT91SAM7S64
>
> * modifiy board.h so the register-definitions for the 7S128 get
> included:
>
> #if defined(_WINARMSUBMDL_AT91SAM7S64_)
> #include "AT91SAM7S64.h"
> #include "lib_AT91SAM7S64.h"
> #elif defined(_WINARMSUBMDL_AT91SAM7S128_)
> #include "AT91SAM7S128.h"
> #include "lib_AT91SAM7S128.h"
> #elif defined(_WINARMSUBMDL_AT91SAM7S256_)
> #include "AT91SAM7S256.h"
> #include "lib_AT91SAM7S256.h"
>
> You can just use the AT91-library (lib_*.h) from another SAM7S - I found
> no significant difference the last time I compared the AT91 libs for
> 7S64 and 7S256. The register-defintions (AT91SAM7S*.h) only differ in
> the defines for the Flash and RAM size/organisation. If you don't need
> this defines you can also re-use the register-defintion from another
> SAM7S. The "correct" files are available from at91.com
> (kits->7S-EK->software).
>
> * copy AT91SAM7S64-RAM.ld and AT91SAM7S64-ROM.ld to *7S128.ld, the files
> are the linker-scripts which are used from inside the makefile. You see
> that there are just two includes there, one on them has to be modified,
> for example the AT91SAM7S128-ROM.ld:
> /* AT91SAM7S128 linker-script for flash workspace (mthomas) */
> INCLUDE AT91SAM7S128_memory.ldh
> INCLUDE AT91SAM7S_sections_ROM.ldh
>
> * The "sections include" in the linker-scripts are for all targets. In
> the *128_memory.ldh the memory-sizes for the target are given. Copy
> AT91SAM7S64_memory.ldh to AT91SAM7S128_memory.ldh and modify:
> /*- File source          : AT91SAM7S128_memory.ldh
> */
> MEMORY
> {
>   CODE (rx)  : ORIGIN = 0x00100000, LENGTH = 128k
>   DATA (rwx) : ORIGIN = 0x00200000, LENGTH = 32k
> }
>
> This should be all. I have implemented the changes in a new release of
> the gamma example:
> 
http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/index_at91.html#at91_gamma
> Please test.
>
> More information on linker-scripts can be found in the binutils manual
> (ld).
>
> Martin Thomas

Hello Martin,

thanks for the very detailed info. Indeed the different approaches for
writing a linker script are confusing me. For example the two linker
script files which I compared (*64.ld and *256.ld) the memory for the
programme is called "FLASH" in one of the files and "CODE" on the other
file. This was one of the things which puzzled me, the other one is way
how the size/length of the memory is specified  - 0x00010000 and 64k.
Indeed using linker scripts as you do it is very flexible as the Section
Definitions are the same for one MCU family.

I found the info in your compilation, concerning the LD file, but if I
have to write it from zero it will cost me too much time. It is a lot
more easy to have examples.

I'll inform you if there is a problem with the linker script for the
128K version.

Thanks and best regards,
Dimitar

I'm starting with ARM and WinARM.
And I have a question about linker scripts. Why on Earth in some scripts
is:

MEMORY
{
  CODE (rx) : ORIGIN = 0x00000000, LENGTH = 0x00010000
  DATA (rw) : ORIGIN = 0x00200000, LENGTH = 0x00004000
  STACK (rw) : ORIGIN = 0x00204000,LENGTH = 0x00000000
}


and in the other :

MEMORY
{
  CODE (rx) : ORIGIN = 0x00100000, LENGTH = 0x00010000
  DATA (rw) : ORIGIN = 0x00200000, LENGTH = 0x00004000
  STACK (rw) : ORIGIN = 0x00204000,LENGTH = 0x00000000
}

The first script is from C:\WinARM\examples\at91sam7s64_Atmel_example
and the other from
C:\WinARM\examples\at91sam7s64_Atmel_interrupt


I don't understand why we move DATA to address 0x00100000 ?? Why we
don't use this area of memory ?
And this line is problem for my JTAG and software : H_JTAG ? When it is
this offset , I can't jtag my ATsam7x256 (olimex board SAM7-EX256) and I
get from
H-JTAG (module H-Flasher):

Error: Destination Flash address is out of range

What I think is that that offset is to enable interrupt, am I right ??
By what sholu I do to could program my flash ??

It's very interesting scheme.But I still don't understand....


When we don't have offset :
(CODE (rx) : ORIGIN = 0x00000000, LENGTH = 0x00010000 )

 we put the program (CODE) from address 0x0000000. But after reset
processor check bit 2 in GPNVM and do mapping on 0x0000000 from Flash
(0x0100000) or from ROM (0x0300000), so if we don't put our programm in
0x0100000 processor loaded the old rubish from address 0x0100000 ??

And I don't understand error showed by H-JTAG - H-Flasher ?
From what address start H-Flasher loading our hex /bin file ??
From 0x00000000 or from 0x0100000 ???

As long as the remap-bit is not set the controller (at least SAM7S) maps
the flash into the address-space starting with 0x0. So basically it does
not matter if 0x00000000 or 0x00100000 is used as ORIGIN.

I currently to not have access to an AT91SAM7X-Board so I don't have
"hands on" experience - maybe someone else can jump in here. So far I
have only used SAM7S64 and SAM7S256.

But the basic concept of remapping should be the same. As far as I know
"ROM" is a integrated bootloader on SAM7X for interfacing with i.e.
SAM-BA. This is not really interesting for JTAG-programming. Just make
sure the NVM-Bits are set to map flash to 0x0 (disable the remap to
ROM). You have to set the NVM-bits yourself. IRC SAM-BA can be used for
this, OpenOCD can do this for sure. I don't know if H-JTAG/H-Flasher has
an option for this.

> And I don't understand error showed by H-JTAG - H-Flasher ?
> From what address start H-Flasher loading our hex /bin file ??
> From 0x00000000 or from 0x0100000 ???

As far as I know H-JTAG flashes to the Flash-Origin of the device which
is 0x00100000 for SAM7S and should be the same for SAM7X. The ORIGIN of
the linker-memory-entry for flash (CODE in the cited examples) will be
the first address used in the hex-file. So if H-JTAG parses the
hex-file, finds 0x00000000 as first address it might throw the
error-message since it expects 0x00100000 as first valid address it can
flash to (not tested myself). If you use 0x00100000 as ORIGIN the
start-address in the hex-file matches the start-address H-JTAG expects
and it should work. To avoid the problem you might use the "raw" .bin
file, set offset to 0 in the H-JTAG flasher and it should work with both
ORIGINS.

Martin Thomas