Re: ARM setup: How to load from flash?

[Grant Edwards <grante at visi dot com>]

> >Tell gcc you don't want start files linked in.  IIRC, it's
> >-nostartfiles.
>
> I think what I *really* want is to keep the default routines in these 
> files, but execute additional pieces of code *before* they are loaded 
> (see below). It's probably not that much work to write a custom version 
> of it all, though...

If you decide to keep them, I'd read through them first to make
sure I know exactly what they're doing.

> I asked because I know that the "entry point" code is usually
> (always if you use the default startup code?) stored at the
> very beginning of the text segment, so any such field in the
> object file seems somewhat redundant.

Yes, that's often the case.  I've seem some cases where it's
not true -- usually it happens when an interrupt vector table
comes first.


> >Why are you using COFF instead of ELF?
>
> Well, I'm assuming that it's simpler than ELF, and we're
> talking about a very plain setup, so ELF might just introduce
> more complexity without giving me anything extra that I need.

Perhaps if you're actually putting COFF files in flash and
"loading" them on the fly, the simpler format would be handy.

> That's not the real reason, though. Actually, it's not even
> true that I'm "using" COFF. So far, I've just loaded plain
> binary files and simply started execution from the start of
> the image.

That's generally what we embedded people do.  If you're
converting to binary or hex in the end, it doesn't matter which
object file format you use, and ELF seems to be the format with
the best support these days.

> These files are created using objcopy -b binary with COFF
> files as input, because as I said, I know I'll get the right
> code at the beginning for COFF (I'm not saying that I know I
> won't for ELF, though.)

With either, you can write your linker script and startup code
to make sure that there is an entry point at the beginning of
the binary image.

-- 
Grant Edwards
grante@visi.com

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com