Re: [avr-libc-dev] [PATCH] Alpha version: True support for atmega256x in binutils and gcc

[Björn Haase]

Marek Michalkiewicz wrote on Montag, 1. Mai 2006 15:31 :
> On Mon, May 01, 2006 at 12:22:39AM +0200, Björn Haase wrote:
> > I am getting closer to a true solution for the atmega256x issue. The good
> > news is that the most difficult problem is IMO now solved. The patches
> > still will need some testing, but I don't see any serious difficulty any
> > more.
>
> Good to see this moving forward - thanks, and keep up the good work!
>
> One issue remaining to consider - ATmega256x bootloaders, located
> completely above 128K, so there is no "low memory" reachable with
> indirect jumps.  Possible solution:
>
>  - initialize EIND and RAMPZ in gcrt1.S based on the program start
>    address (nonzero in bootloaders, zero in normal applications).
>    Note that EIND is the high byte of a word address (multiple of 128K
>    bytes), and RAMPZ is the high byte of a byte address (multiple of
>    64K bytes) - for example, ATmega256x boot needs EIND=1, RAMPZ=3.
>
>  - replace all uses of "ijmp" and "lpm" with "eijmp" and "elpm",
>    respectively; 16-bit addresses are now relative to EIND / RAMPZ
>    base address instead of 0; "below 128K/64K" now becomes "within
>    a block of this size and alignment, containing the bootloader".

> I don't have a strong opinion about the RAMPZ/elpm part - perhaps
> leave it as is, and just be careful when writing bootloaders, just
> as is currently necessary for 128K devices.  The EIND/eijmp part
> for >128K devices looks like a good idea to me in any case.
Agreed :-). One should probably prepare a patch that does both: remove the 
stack initialization completely from main and replace it by an initialization 
of EIND and RAMPZ for the avr6 devices only. I think that it's better to make 
gcc make the stuff. This way one will not need two pass the parameter to the 
crt-generator.

Regards,

Bjoern.