|
From: | Bernard Fouché |
Subject: | Re: AW: AW: [avr-gcc-list] Using current avr-gcc for target ATmega2561 |
Date: | Tue, 04 Oct 2005 11:56:50 +0200 |
User-agent: | Mozilla Thunderbird 1.0.2 (Windows/20050317) |
Haase Bjoern (PT-BEU/EMT) * wrote:
Always at the end of the flash... from 4 to 32 pages of 256 bytes reserved from the end.At which address does the bootloader code end up?
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
[Prev in Thread] | Current Thread | [Next in Thread] |