Ok, solved it myself :) It seems that the functions that you put in sections need to be in a separate source file.
Unfortunately the relevant code seems to remain in flash...does the linker place the section in ram or is it simply providing a convenient label for Redboot to use to relocate from ROM to RAM? I'm a bit shaky on this side of things. Objdump shows the flash addresses where the code goes; should it not also show RAM addresses for things you've asked to be placed in RAM? m@ -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matt Sartori Sent: 19 September 2005 13:55 To: eCos Discussion Subject: [ECOS] moving functions into RAM Hi all, I've looked through all the archived posts that mention the Relocation truncated to fit: R_ARM_PC24 and any mention of __attribute__ (section( in the hope of finding any hint as to why I'm failing to link with the above relocation error. I'm trying to ensure that a function is loaded to RAM instead of flash. I'm doing so by adding a section attribute to the end of my function declaration: void FLASH_SectorErase(u32 Xsectors) __attribute__ ((section (".2ram.flashsectorerase"))); I get the linker errors at all the points in the source where I'm calling the FLASH_SectorErase presumably because the BL target address won't fit in the 24 bits available to the address. I've edited the redboot/current/makefile to add a -mlong-calls but to no avail. Is the linker ignoring the argument or am I missing something else? Any info appreciated. m@ ------------------------------------------------------------------------ -------- The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender or postmaster ([EMAIL PROTECTED]) and delete the material from any computer. Although we routinely screen for viruses, addressees should check this e-mail and any attachment for viruses. We make no warranty as to absence of viruses in this e-mail or any attachments. Our Company's email policy is to permit incidental personal use. If this email is of a personal nature, it must not be relied upon as expressing the views or opinions of the company. Visit out website at www.hanoverdisplays.com -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
