This is the mail archive of the
ecos-discuss@sourceware.cygnus.com
mailing list for the eCos project.
Re: Q: PowerPC HAL '.vectors', ROM/RAM, etc.
- To: Sergei Organov <osv at javad dot ru>
- Subject: Re: [ECOS] Q: PowerPC HAL '.vectors', ROM/RAM, etc.
- From: Jesper Skov <jskov at redhat dot com>
- Date: 04 Apr 2000 09:51:11 +0200
- Cc: ecos-discuss at sourceware dot cygnus dot com
- References: <87r9cnyryq.fsf@osv.javad.ru>
>>>>> "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