[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) || defined(mpc8260))
uint32_t serial_per_sec; /* Serial clocks per second */
boolean serial_external_clock;
boolean serial_xon_xoff;
boolean serial_cts_rts;
uint32_t serial_rate;
uint32_t timer_average_overhead; /* Average overhead of timer in ticks */
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) || defined(mpc8260))
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?
Two alternatives:

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

Note that a #ifdef __mpcXXX in a BSP is *not* a valid reason as the respective compiler


The only (legacy) reason I can think of are #ifdef __mpcXXX in cpukit and/or libcpu - however,
these should be cleaned up.

Fully agreed.

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?