This is the mail archive of the
ecos-patches@sources.redhat.com
mailing list for the eCos project.
Re: eCos + LPC21xx footprint
Jani Monoses <jani@iv.ro> writes:
> > However, we shouldn't have platform/variant specific ifdefs in
> > vectors.S. Also, a problem with your approach is that it assumes
> > that the vectors will remain constant. This is true of the interrupt
> > and exception vectors, however, the contents of the reset vector may
> > change depending on memory layout.
>
> You mean by the use of the CYGSEM_HAL_ROM_RESET_USES_JUMP switch ?
> 1) With Andrew's proposed CDL soulution this could be handled in the LPC cdl
> having different requires for the different startup modes.
Not just that. Users are at liberty to reorganize the layout of
sections in the .ldi file. Different startup types may also have
different layouts. This is particularly important in small footprint
systems like the LPC2xxx, where rearranging things might save some
RAM.
>
> 2) I am just looking at CYGSEM_HAL_ROM_RESET_USES_JUMP and I cannot
> figure out why it is needed.
>
> #ifdef CYGSEM_HAL_ROM_RESET_USES_JUMP
> // Assumption: ROM code has these vectors at the hardware reset address.
> // A simple jump removes any address-space dependencies [i.e. safer]
> b reset_vector // 0x00
> #else
> ldr pc,.reset_vector // 0x00
> #endif
>
> Which targets need this? I blindly copied it from the AT91 hal.
> I disabled it now and the app works using the ldr.
> So if I don't define this switch at all there should be not reset
> vector differences right? I see that the xscales do not use it either.
The branch version is position independent. For ROMRAM startups and
platforms where the ROM is relocated using the MMU, the code is linked
to the address it will run at after relocation. So it is important it
doesn't use any absolute references before the relocation is complete.
--
Nick Garnett eCos Kernel Architect
http://www.ecoscentric.com/ The eCos and RedBoot experts