Re: Porting eCos to the BlackFin processor

[Bas Vermeulen <bvermeul at blackstar dot nl>]

On Thu, 2003-09-11 at 00:49, Jonathan Larmour wrote:
> bvermeul@blackstar.nl wrote:
> > Hi all,
> > 
> > I'm trying to port eCos to the Analog Devices BlackFin BF533 processor, 
> > but am having some difficulties understanding the implementation needed 
> > for vector.S.
> > 
> > I've read the Architecture HAL porting bit on the web, and do understand
> > the trampoline function that it has, but not how I am supposed to set the 
> > vectors to the hardware itself.
> > 
> > The Blackfin processor has special purpose registers for the various 
> > exception vectors, which would need to be filled by eCos during startup.
> > The way I read it, the reset vector needs to be set by the linker?
> > I'm not entirely sure of that, but don't see where else that would be 
> > handled.
> > 
> > Any pointers to code or documentation would be very much appreciated. At 
> > the moment I'm a little stumped.
> 
> Well, there are plenty of other HALs to look at! Which one were you using 
> as a basis?

ARM mostly, a bit of i386, but I look at most of them for things in
common.

> 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.

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?

Thanks,

Bas Vermeulen

-- 
Profanity is the one language all programmers know best
	-- Troutman's 6th programming postulate