[ECOS] PowerPC vector base location

Patrick Doyle wpd@delcomsys.com
Wed Dec 26 04:25:00 GMT 2001


In addition, or instead, why not change the "calculated" property to
"default"?  That way it could be overridden on a case by case basis.

Actually, I think that Bob's idea is a fine one, I am more seeking guidance
from the CDL gurus as to why one would choose "calculated" over "default"
(or vice versa) for an option such as where to place the interrupt vector
table.

--wpd


> -----Original Message-----
> From: ecos-discuss-owner@sources.redhat.com
> [mailto:ecos-discuss-owner@sources.redhat.com]On Behalf Of Gary Thomas
> Sent: Monday, December 24, 2001 11:03 AM
> To: bob.koninckx@mech.kuleuven.ac.be
> Cc: eCos Discussion
> Subject: Re: [ECOS] PowerPC vector base location
>
>
> On Sun, 2001-12-23 at 02:13, Bob Koninckx wrote:
> > Hi guys,
> >
> > I'd like to introduce an extra configuration option into the powerPC
> > HAL.
> > The powerpc architecture allows the vectorbase to be located at
> > 0x00000000
> > or fff00000. Not every board however has memory at 0xfff00000. Depending
> > on
> > the platform, 0x00000000 can be RAM or FLASH or ...
> >
> > Therefore I think that it makes sense to rewrite the CDL option for the
> > vector
> > base as follows.
> >
> >     cdl_option CYGHWR_HAL_POWERPC_VECTOR_BASE {
> >         display       "Exception vectors location"
> >         description   "
> >             PowerPC exception vectors can reside either at 0x00000000 or
> >             0xfff00000. The startup type and platform HAL controls which
> >             is used."
> >         flavor        data
> >         calculated { (! CYGHWR_HAL_POWERPC_FORCE_VECTOR_BASE_LOW &&
> >                        (CYGHWR_HAL_POWERPC_FORCE_VECTOR_BASE_HIGH ||
> >                        (CYG_HAL_STARTUP != "RAM" &&
> >                         ! CYGSEM_HAL_POWERPC_COPY_VECTORS)))
> >                       ? 0xfff00000 : 0x00000000 }
> >     }
> >
> > If the platform HAL does not define
> > CYGHWR_HAL_POWERPC_FORCE_VECTOR_BASE_LOW,
> > nothing changes, so there is no risk of breaking existing code. It
> > leaves however
> > the option to force the vector base at zero with copying (for RAM at
> > 0x0000) or
> > WITHOUT copying the vectors. (FLASH 0x0000000)
> >
> > This would be good to have for e.g. MPC555. Copying the vectors is than
> > usefull for
> > platforms that disable the internal flash and dual map it to a RAM
> > region. Not copying
> > allows for using the Internal flash. (an attempt to write to that one
> > will result in
> > an illegal instruction exception)
> >
> > Any comments, suggestions ??
>
> This is a fine idea, as long as care is taken to not break anything :-)
>
> Do it, test it, send the patch & the [copyright] assignments and we'll
> integrate it into the source tree.
>
>
>



More information about the Ecos-discuss mailing list