RE: Linker options for dividing flash

["Kishore, Jonnalagadda \(IE10\)" <Kishore dot Jonnalagadda at honeywell dot com>]

> -----Original Message-----
> From: dj@redhat.com [mailto:dj@redhat.com]
> Sent: Monday, April 02, 2007 8:46 PM
> To: Kishore, Jonnalagadda (IE10)
> Cc: binutils@sourceware.org
> Subject: Re: Linker options for dividing flash
> 
> 
> "Kishore, Jonnalagadda \(IE10\)" <Kishore.Jonnalagadda@honeywell.com>
> writes:
> > The problem I have is that each of the three sections is to be built
> > independently thus generating 3 elf images. For section one to jump
into
> > section 2 or 3, I need to fix the entry address of sections 1 and 2
for
> > a given board. Suppose I have allocated 64KB for each section, I
need to
> > inform the linker that the address range for section 1 is 0-64,
65-128
> > for section 2 and 129-192 for section 3.
> 
> It sounds like there's a couple tips that might help you.
> 
> If you look in newlib's sources in src/libgloss/m32c, you'll see my
> code for generating linker maps from scripts in Makefiles.  You can
> use something like this to generate a set of link maps that differ
> only in the start/end address of your flash memory.
> 
> To coordinate the jumps to the two boot images, you have two choices:
> 
> 1. Declare that the starting address is always the beginning of the
>    flash block, or some other fixed address.  Use crt0.S and your link
>    script to ensure that the start label is in the right place.  The
>    easiest spot is at the lowest address in the block, as you just
>    tell the linker to link crt0.o first, but the m32c example includes
>    a reset vector at the top of memory if you want to do it that way.
> 
> 2. Use "<target>-nm" to scan the two elf images and parse the actual
>    address of the images.  Use the results of that to create a .S
>    program that's used to generate the bootstrap block.
> 
> I suspect the first is what you want, as you'd want to flash the
> bootstrap the minimum number of times (for safety, yes?).

Indeed, the first option would be my choice. The idea is to have the
bootstrap to be a minimal system that shall never (hopefully :-)) be
upgraded.

Considering your first option, let me know if I have understood
correctly. From your sources:

MEMORY {
        RAM (w) : ORIGIN = RAMSTART, LENGTH = RAMSIZE
        ROM (r) : ORIGIN = ROMSTART, LENGTH = ROMSIZE
        VEC (r) : ORIGIN = VECSTART, LENGTH = 32
        RESETVEC (r) : ORIGIN = RESETSTART, LENGTH = 4
}

Is this what you refer to? Ie. I set RAMSTART, RAMSIZE etc. individually
for each of the three sections? I've never tried this, so can I invoke
the inker command with something like:

<target>-ld -DRAMSTART=0x400 ...

And RAMSTART gets substituted in the linker script? And the way I
control the entry address with respect to the begin of the section is by
writing the startup file accordingly and have it be the first file
passed to the linker?

This sounds simple. I'll try it out. Just that... would it be possible
that entry address is controlled even when the files passed to the
linker are out of order? I am considering creating a section for the
startup file and put it in the beginning of the linker script.

Warm regards,
Kishore