AW: AW: AW: [avr-gcc-list] Using current avr-gcc for target ATmega2561

[Haase Bjoern (PT-BEU/EMT) *]

After reading your message I conclude that you will probably not be having any 
problem unless that you are planing to use pointers to functions in your 
bootloader code. The jump stubs will be used *only* in case that you are using 
a function pointer because this way, we could stick to 2-byte function pointers.
The second restriction for your boot-loader code would probably be that you 
must disable table jump instructions by the appropriate compiler switch because 
these address tables usually do not end up in the bootloader section. This, 
however, probably is a restriction that applies already now.

IMO any other solution (3-byte pointers, alignment etc.) would be both, very 
difficult to implement not scalable and IMO less efficient.

Bjoern.


-----Ursprüngliche Nachricht-----
Von: Bernard Fouché [mailto:address@hidden 
Gesendet: Dienstag, 4. Oktober 2005 11:57
An: Haase Bjoern (PT-BEU/EMT) *
Cc: Martijn van Balen; address@hidden
Betreff: Re: AW: AW: [avr-gcc-list] Using current avr-gcc for target ATmega2561

Haase Bjoern (PT-BEU/EMT) * wrote:

>At which address does the bootloader code end up?
>
>  
>
Always at the end of the flash... from 4 to 32 pages of 256 bytes 
reserved from the end.

Now one may need more than 8K bytes of program size for a complex 
bootloader and so extend its size downward from the end the memory, by 
adding one or more sections. One would not expect to have also data 
already at the beginning of the memory or somewhere in the middle. We 
have done that at my company at least to be able to store debugging code 
while testing a bootloader (for instance by storing printf just under 
the bootloader). Also when a bootloader works, it will usually copy 
everything from a feeding point into the MCU memory. Having to manage a 
'bootloader jump stub section' somewhere and not scratch it will be 
difficult.

In the bootloader case, the jump stubs lose its meaning since if the 
stubs are moved in the bootloader section, then we are already jumping 
from and to an upper section address.

I did not follow all the exchanges about the different solutions, but 
the 4 bytes alignment seem to me the cleanest one since one will loose 
at most 2 bytes per defined function and there is no difference in code 
production between application and bootloader section. Now I have no 
idea about the required work in gcc.

  Bernard