avr-libc-dev
[Top][All Lists]
Advanced

[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: Marek Michalkiewicz
Subject: Re: [avr-libc-dev] [PATCH] Alpha version: True support for atmega256x in binutils and gcc
Date: Mon, 1 May 2006 15:31:25 +0200
User-agent: Mutt/1.5.9i

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".

Part of the issue (RAMPZ/elpm) already exists on 128K devices.
Ideally, bootloaders should set RAMPZ=1 and use "elpm" instead of
"lpm" - as already done in the loop that copies the data section
from flash at startup, but not for other uses of "lpm" (tablejumps,
*_P library functions, etc.).

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.

Regards,
Marek

PS.  I haven't had much time to contribute to this project in the
recent months, but I'm glad to see it continues and is successful.
I've been very busy, and this is unlikely to change anytime soon.
In addition, in 3 months I'm going to start a new job for a large
corporation, which means I probably won't be allowed to contribute
to open source projects, to avoid intellectual property issues.
Now is a good time for me to say thanks and goodbye to all of you.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]