public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: "Matt Sartori" <msartori@hanoverdisplays.com>
To: "eCos Discussion" <ecos-discuss@ecos.sourceware.org>
Subject: [ECOS] moving functions into RAM
Date: Mon, 19 Sep 2005 15:09:00 -0000	[thread overview]
Message-ID: <F9885E669725F248A1F6DB9109FDD67905E510@Molly.hanover.local> (raw)

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 (postmaster@hanoverdisplays.com) 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

             reply	other threads:[~2005-09-19 12:54 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-09-19 15:09 Matt Sartori [this message]
2005-09-20  2:07 ` Andrew Lunn
2005-09-20  1:34 Matt Sartori

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=F9885E669725F248A1F6DB9109FDD67905E510@Molly.hanover.local \
    --to=msartori@hanoverdisplays.com \
    --cc=ecos-discuss@ecos.sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).