This is the mail archive of the
mailing list for the eCos project.
Re: Porting eCos to the BlackFin processor
Bas Vermeulen wrote:
The linker script sets an entry point, although that tends to be relevant
only for programs that are loaded to and start from RAM. For stuff that
runs from ROM/Flash i.e. that is the first thing that's loaded, then you
have to use the linker script to ensure the relevant startup code is
linked at the correct memory address. This is done by a combination of the
.ld file supplied by the architecture HAL (generally) and the mlt*.ldi/.h
files in the include/pkgconf subdirectories of platform HALs.
Ok. So if I understand you correctly, I don't have to set the CPU's
reset vector until I'm in my startup routine, because the reset vector
is handled by ld scripts. Or rather, the startup routine is linked in
the right memory location.
Yep, because something has to have it running from the right place before
it can do anything else obviously! For RAM startup apps, the entry point
can be slightly different: the entry point comes from the first .text bits
in whatever filename is referenced by the STARTUP() directive in the .ld
file. Normally this would be
and the first text stuff in vectors.o would be the startup. Again have a
look at the other architectures to see what I mean.
You would make this startup routine common between ROM and RAM startup
anyway. Sometimes other helper functions go in there, but usually those go
in either arch.inc or <architecturename>.inc (e.g. arm.inc) and are
defined as macros.
I think that vector.S needs to contain the interrupt trampoline
routines, the startup function, and the reset vector. Is there anything
more than that?
That very much depends on the architecture! If (synchronous) exception
trampoline routines are different from interrupt ones, then those should
be there too.
eCosCentric http://www.eCosCentric.com/ The eCos and RedBoot experts
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine