[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [avr-libc-dev] [PATCH] Alpha version: True support for atmega256x in
From: |
Björn Haase |
Subject: |
Re: [avr-libc-dev] [PATCH] Alpha version: True support for atmega256x in binutils and gcc |
Date: |
Mon, 1 May 2006 07:51:16 +0200 |
User-agent: |
KMail/1.7.1 |
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.