[ECOS] Q: PowerPC HAL '.vectors', ROM/RAM, etc.

Jesper Skov jskov@redhat.com
Tue Apr 4 00:51:00 GMT 2000


>>>>> "Sergei" == Sergei Organov <osv@javad.ru> writes:

Sergei> Now, I need the '.vectors' section to be put in RAM, but
Sergei> 'vectors.S' file generates '.vectors' section only if at least
Sergei> one of the following conditions is met:

Sergei> #if defined(CYG_HAL_STARTUP_ROM) || \
Sergei> defined(CYGPKG_HAL_POWERPC_SIM) || \
Sergei> defined(CYGSEM_HAL_POWERPC_COPY_VECTORS)

Sergei> The second condition here seems to be a bad idea anyway
Sergei> because code in 'powerpc/arch' should not know about
Sergei> particular target being supported, I believe. Anyway, in my
Sergei> case I need '.vectors', but neither of these conditions are
Sergei> true. I guess that was the problem with SIM target as well,
Sergei> and the vectors.S was just quickly adopted. Obviously doing
Sergei> the same thing for my target is even less acceptable. How do I
Sergei> solve this?

Many such crufty expressions need to be rewritten to use CDL
interfaces instead, so the semantics can be properly controlled from
CDL. I think it will take a very long time before all eCos code is
changed to take full advantage of CDL though.

Sergei> Another problem is that code in 'powerpc/arch' assumes RAM is
Sergei> located at 0, but it's not the case with my board where both
Sergei> RAM and vectors are located at 0xfff00000, and ROM is located
Sergei> at 0.

Sergei> The best solution for these problems would be to fix PPC HAL
Sergei> to make ROM/RAM configuration, ROM/RAM location, vectors
Sergei> location, and requirement to copy vectors from ROM to RAM be
Sergei> separate parameters that are to be defined by target, but I
Sergei> don't fill myself familiar enough with eCos to predict
Sergei> required amount of work and all the consequences. Any
Sergei> suggestions?

It should be a fairly limited job:

 o Add new CDL option which specifies where to copy vectors
   (should take values 0x0 or 0xfff00000, former being default)
 o Change COPY_VECTORS code to use that variable.
 o Change MSR value calculation (top of vectors.S) to take the value
   of that variable into account.
 o The hal_vsr_table definition must be made platform specific.
   I saw this one coming but didn't take the time to figure out how to
   deal with it. 
   Short term: add the above variable to the definition so the table
   either resides at 0x3000 or 0xfff03000.

Then you would be in a situation where CYGSEM_HAL_POWERPC_COPY_VECTORS
should be enabled (or it should be harmless to do so).

Sergei> BTW, I noticed that linker files in the PowerPC variants
Sergei> define variables like, e.g., '__reserved_vsr_table', that
Sergei> currently seem to be used nowhere. Are they invented to get
Sergei> rid of static definition of 'hal_vsr_table' in the
Sergei> 'powerpc.ld' file?

No - these are just descriptive place holders so users can see the
space is reserved for use by the HAL.

Jesper


More information about the Ecos-discuss mailing list