[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: powerpc-rtems-4.7-gcc-4.0 patch commited
E.g. the m8260 would be superflous, if it could be removed from cpukit.
The code it uses is _identical_ to the 603e, except of 1 define in
OK. Are you referring to this code?
#if (defined(ppc403) || defined(mpc860) || defined(mpc821) ||
uint32_t serial_per_sec; /* Serial clocks per second */
uint32_t timer_average_overhead; /* Average overhead of timer in
uint32_t timer_least_valid; /* Least valid number from timer
boolean timer_internal_clock; /* TRUE, when timer runs with
CPU clk */
#if (defined(mpc555) || defined(mpc860) || defined(mpc821) ||
uint32_t clock_speed; /* Speed of CPU in Hz */
These are the HW configuration parameters required by portions of
libcpu which are provided by the BSP. How about another mechanical fix?
+ Define this as a structure that is provided by the BSP.
+ Like other portions of libcpu, assume that the BSP is providing
a single global variable like "BSP_clock_speed" and change the
code in libcpu to use it.
However it is done, it is BSP specific information required by libcpu
code. No reason for it to be defined in cpukit.
That would seem to eliminate the need for mpc555, mpc860, mpc8260, and
Note that a #ifdef __mpcXXX in a BSP is *not* a valid reason as the
The only (legacy) reason I can think of are #ifdef __mpcXXX in cpukit
and/or libcpu - however,
these should be cleaned up.
Eg. let's implement a common API, shared between old and new exception
processing. Lack of this is the cause for at least 3 multilib variants.
Can you point me to a specific ifdef to nibble on?