Re: [ECOS] PowerPC vector base location

[Bart Veer <bartv at redhat dot com>]

>>>>> "Patrick" == Patrick Doyle <wpd@delcomsys.com> writes:

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

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

As Jifl pointed out, there are various ways of tackling this in CDL.
Without knowing full details of the PowerPC hardware...

1) make the option calculated depending on a platform choice, as per
   Bob's message.

   cdl_option CYGHWR_HAL_POWERPC_VECTOR_BASE {
       calculated { <some expression> ? 0xFFF00000 : 0x00000000 }
   }

   where the expression depends among other things on some other
   option defined in a variant or platform HAL, e.g.
   CYGHWR_HAL_POWERPC_FORCE_VECTOR_BASE_HIGH. Note that inference
   engine cannot readily manipulate calculated options at present,
   so any "requires" constraints involving calculated options
   have little effect. In theory the inference engine would be
   able to make progress by considering the "calculated" expression,
   but that is not implemented yet.

2) make it a default_value, allowing the user to overwrite it.

       default_value { <some expression> ? 0xFFF00000 : 0x000000 }

   This gives the user full control, but assumes that the user knows
   exactly what he/she is doing. If setting the address to e.g.
   0xFFE00000 by accident could cause permanent hardware damage then
   this is a very bad idea. Even if no hardware damage is possible,
   if a typo is made and the system stops working it could take a long
   time to isolate the problem.

3) make it a default_value but impose a legal_values constraint.

       default_value { <some expression> ? 0xFFF00000 : 0x000000 }
       legal_values  { 0xFFF00000 0x00000000 }

   This still gives the user control but is safer. A problem could
   arise if some manufacturer creates a new PowerPC variant where the
   vectorbase could be placed somewhere else again, but that is
   probably not worth worrying about too much.

4) always default to 0, but allow platforms to override this via
   requires constraints.

       default_value { 0x00000000 }
       legal_values  { 0xFFF00000 0x00000000 }

     plus

       cdl_package CYGPKG_HAL_POWERPC_random_platform {
           requires { 0xFFF00000 == CYGHWR_HAL_POWERPC_VECTOR_BASE }
       }

   On platforms which contain such "requires" constraints there is no
   user choice. On platforms where it may be sensible for the user
   to make the decision, the "requires" constraint can be left out.
   However there is a problem on platforms where there is a user
   choice but 0xFFF00000 would be a better default.

5) combine (3) and (4)

       default_value { <some expression> ? 0xFFF00000 : 0x000000 }
       legal_values  { 0xFFF00000 0x00000000 }

     plus

       cdl_package CYGPKG_HAL_POWERPC_random_platform {
           ...
           requires { 0xFFF00000 == CYGHWR_HAL_POWERPC_VECTOR_BASE }
       }

   This way the vector base will be at a suitable location for the
   given platform by default. On some platforms that location will be
   fixed by a "requires" constraint, while on others users may
   override this.

Possibly CDL should have another property such as "prefers" which
allows a package to manipulate the default value associated with some
other option, without interfering with "requires" constraints and the
inference engine. That way a platform HAL could contain:

       cdl_package CYGPKG_HAL_POWERPC_other_platform {
           ...
           prefers { 0xFFF00000 == CYGHWR_HAL_POWERPC_VECTOR_BASE }
       }

That would reduce the need for utility configuration options such as
CYGHWR_HAL_POWERPC_FORCE_VECTOR_BASE_HIGH. However it is just an idea:
implementing it would be non-trivial, and I would have to think
carefully about issues such as possibly increased user confusion.

hope this helps.

Bart

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