[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bare bsp set for m68k
- Date: Wed, 30 Sep 98 09:03:08 -0600
- From: eric at skatter.USask.Ca (Eric Norum)
- Subject: bare bsp set for m68k
> On Wed, 30 Sep 1998, Robin Kirkham wrote:
> > Now I look at m68k.h, I see the dreadful temporary hack of mine
> > to deal with the CPU32/CPU32+ discrimination (involving setting
> > RTEMS__mcpu32p__) seems to be there still. Does this have to be
> > incorporated in the bare-bsp selector fragment, Joel, or is it
> > dealt with elsewhere?
> Grep'ing the entire source tree turns up these references:
> ./src/exec/score/cpu/m68k/m68k.h: * If you are using a CPU32+, then
> the symbol RTEMS__mcpu32p__ should
> ./src/exec/score/cpu/m68k/m68k.h: * two cores, then
> RTEMS__mcpu32p__ usage will be replaced with the
> ./src/exec/score/cpu/m68k/m68k.h:#elif defined(RTEMS__mcpu32p__)
> Two of those are in comments and the third defines the CPU model.
> How do you want to deal with it?
> As a side note, there were 2 identical copies of the 68060 info in
> there and I deleted one of them.
But there's one more place this symbol shows up
@echo "/* #define NDEBUG 1 */ " >>$@
@echo "#define RTEMS_TEST_NO_PAUSE 1" >>$@
@echo "/* #define RTEMS_DEBUG 1 */" >>$@
@echo "#define RTEMS__mcpu32p__ 1" >>$@
This, of course, is not correct when the gen68360.cfg file is being
included by the gen68360_040.cfg file. I think there's not a big
problem, because the order of the conditional tests in m68k.h finds
the 68040 definitions first, but it is a little confusing in this
Perhaps the make-target-options definition has to be put in a
conditional inside gen68360.cfg?
Or is there some other way to make sure that `#define
RTEMS__mcpu32p__ 1' is not done when RTEMS_GEN68360_COMPANION_MODE is
Eric Norum eric at skatter.usask.ca
Saskatchewan Accelerator Laboratory Phone: (306) 966-6308
University of Saskatchewan FAX: (306) 966-6058