MIPS BSP

[Joel Sherrill]

There are a number of MIPS users on the general RTEMS users list
as well as people who just have good insight on structure.  So I
am moving this to the list.  I have also included Greg Menke since 
he represents the MongooseV space mips. :)

Wayne Bullaughey wrote:
> 
> Joel
> 
> More ramblings about MIPS:
> 
> >From my understanding of the IDT MIPS processors there are two pretty
> orthogonal concepts. One is the instruction set which is described by the
> _mips value which gives the ISA spec. The other include such things as cache
> architecture, memory organization and interrupts. I don't think the ISA spec
> applies to those things in a vary consistent way. 

Correct.  The issues you specifially mention as well as drivers
for on-CPU peripherals needs to be addressed in libcpu.

> The 4 processors we
> currently support are IDT 4700, IDT 5000, IDT 32364 and QED 7000. All but
> the 32364 run the ISA level 3 but are all different in terms of cache and
> memory. The conditional compilation constructs in the current idtcpu.h do
> not handle all these cases. I use a single build of gcc to generate code for
> all three so I get R4000 and either _mips == 1 or _mips == 3 depending on
> flags I pass to gcc.

FWIW I do not think you can trust R4000 from gcc as much as you
can __mips.  On the ports I looked at, it was hard coded in 
the CPP_PREDEFINE_SPECS.  So ...

IMO if idtcpu.h includes anything that is not strictly dependent on the
ISA level, we need to figure out if it can be moved into the libcpu
structure.

> I greped around in gcc 3.0.1 sources and found references to R3000, R3900,
> R6000, R4000, R4100, R4300, R4600, R4650, R5000, R8000.

Yep.  The mips family is so simply and beautiful until you look at all
the variants. :)

I followed up on Alan Cudmore's work in reorganizing the mips port to
more properly support all models.  The problem is that there are SO MANY
variants that I was only comfortable with the mips ISA 1 versus NOT ISA
1.
I am sure that ISA3 versus ISA4 is not dealt with completely and I am
also sure that due to my not knowing every MIPS model intimately, I
missed some cases where things vary.  So when you spot things put it
in the historical context.  I probably missed things that vary. :)
 
> The way I started reorganizing idtcpu.h is to use the standard macros R3000
> and R4000 but then to add vendor specific defines which would be set in the
> board support package cfg file for cases that need special handling. I've
> used defines like IDT_4700 and QED_7000.

idtcpu.h is a legacy artifact of the mips64orion port and it is now
more of a generic MIPS ISA level handler for some common defines.
Anything
that it has beyond that needs to be addressed.  

RTEMS is trying to be multilib-able.  The old non-multilib way would
have 
been to do this.  Now we want to separate the code that can't be built
based upon the gcc's multilib variants into libcpu (or in extreme cases
libbsp).  So although workable, this is not the desired solution.

> Another approach which seems more
> consistent with what you have been doing would be to take the definitions
> which are vary CPU architecture specific such as the cache configuration
> masks out of the common include file idtcpu.h and move them to maybe a
> vendor specific place (idtcpu.h sounds like a vendor specific include file
> but it looks like its used for all MIPS ports).

idtcpu.h is a legacy artifact of the mips64orion port and it is now
more of a generic MIPS ISA level handler for some common defines.

> The code in
> c\src\exec\score\cpu\mips doesn't do anything with cache or memory
> organization so it doesn't need the defines that differ.
> 
> I see how you started CPU specific directories in c\src\lib\libcpu\mips.
> Each of those directories could have an include file which has the cpu
> specific defines which are now in idtcpu.h. I think the cache and TLB
> handling code should also be moved to directories under
> c\src\lib\libcpu\mips.

I am glad you came to this conclusion because it is indeed the intention
and plan.  There is a common RTEMS cache API you can support.  At the
current time, the mips cache API support is marked as TBD in the source.
:)

> I'd like to come up with a way to make these changes without breaking
> current BSPs. Would it work to create a new file in
> c\src\exec\score\cpu\mips called mipscpu.h which has only the common
> definitions  or at most ones that can clearly be identified by the defines
> like R3000 and R4000 but leave the current idtcpu.h as it is and move over
> time to not using idtcpu.h. .h files with the cpu specific definitions would
> go in c\src\lib\libcpu\mips.

Perfect.  But if we can avoid R3000 and R4000, let's do it.  I am 
VERY uncomfortable about their correctness.  mips-rtems-gcc does not
define R3000 or R4000.  Try this:

mips-rtems-gcc -dM -E -mips1 - </dev/null
mips-rtems-gcc -dM -E -mips3 - </dev/null
mips64orion-rtems-gcc -dM -E -mips1 - </dev/null
mips64orion-rtems-gcc -dM -E -mips3 - </dev/null

Interestingly the 3rd example still prints R4000.  So you can't 
trust it.


> One thing that is common to all the MIPS processors that I'm familiar with
> that is not handled in idtcpu.h which I need is the fact that there are two
> sets of interrupt vectors. One which is enabled by default when the
> processor comes out of reset (often this is in ROM address space) and a
> second set at the low end of kernel address space (often RAM address space).
> The defines in idtcpu.h only define the set at the low end of kernel memory.
> Some of our boards have RAM where most have ROM and no memory at the other
> vector. I would like to see some conditional compilation flag which
> indicates which vector to use in the idtcpu.h vector definitions. This
> define could default to the normal case but could be overridden by CFLAGS
> set by the BSP configure.

Are you saying this is something that the routine 
mips_install_isr_entries() is not addressing?  It certainly is
hardcoded to the vector addresses. Would it be sufficient to 
pass it a parameter so it knows which to use?  But if they
are in ROM, you can't modify them so how do they get setup
in our situation?

Hmmm... Greg can you help out here?  This is tricky and I
know you guys are very knowledgeable. :)

> Are there any of the other MIPS users I should bounce ideas off of?

I have cc'ed Greg Menke and the rtems-users list so we can pick up the
ones from the community.  
 
> > -----Original Message-----
> > From: joel at wmi.com [mailto:joel at wmi.com]On Behalf Of Joel Sherrill
> > Sent: Thursday, October 11, 2001 5:54 PM
> > To: Wayne Bullaughey
> > Subject: Re: MIPS BSP
> >
> >
> > Wayne Bullaughey wrote:
> > >
> > > Hi Joel
> > >
> > > I'm back working on RTEMS for our MIPS products. I'm trying to merge my
> > > changes in to the 20010816 snapshot. One of the problems I'm
> > having is with
> > > the way the idtcpu.h file was changed.  All of the #if's are
> > now in terms of
> > > __mips. The problem with this is the mips level really applies to the
> > > instruction set the MIPS processor uses where as registers are much more
> > > processor specific. There are a number of different register
> > architectures
> > > that all use the mips 3 instruction set. There were specific CPU
> > > designations like CPU_4000. I think we really need this level
> > of granularity
> > > to correctly describe all the possible MIPS CPUs.  I'm working
> > with the IDT
> > > 32364 processor which has a hybrid instruction set but is
> > mostly mips level
> > > 1 but has registers like the 4000 series which is mips 3. I
> > will be working
> > > on making this change but I wanted to get your advice on how to
> > get it back
> > > into the distribution.
> >
> > I thad to think about this a little bit to come up with an answer.
> > AFAIK vanilla-ish mips cpu models (close to the ISA spec) can use
> > a standard toolset configuration like mips-XXX or mips64-XXX.  But
> > some mips are really oddballs and have to be configured special
> > even for gcc (like the tx3904).  So the answer depends a lot on
> > your answer to the question:
> >
> > What toolset target do you use?
> >
> > The code in score/cpu can ONLY depend on macros defined by gcc
> > implicitly.  If you are using a mips32364-XXX gcc target, then
> > you can test on anything it defines.  Do a "dumpspecs" on your
> > target gcc and see what it conditionals it gives you.
> >
> > Just please, please let me know the output and justify your
> > choice of symbols.  The mips is a really ugly gcc port about this
> > kind of thing and I just want to keep a master list of valid
> > gcc predefined symbols to test along with a description. The
> > __mips ones are obvious but you are proposing a not so obvious
> > one.  It is OK and perfectly kosher but it needs to be justified
> > and documented. :)
> >
> > > Wayne Bullaughey               Voice:  (610) 692-9526 ext: 104
> > > Woodward McCoach, Inc.                 (877) 284-4804
> > > 1180 McDermott Drive           Fax:    (610) 436-8258
> > > West Chester, PA 19380         Email:  wayne at wmi.com
> > >                                web:    www.wmi.com
> >
> > --
> > Joel Sherrill, Ph.D.             Director of Research & Development
> > joel at OARcorp.com                 On-Line Applications Research
> > Ask me about RTEMS: a free RTOS  Huntsville AL 35805
> >    Support Available             (256) 722-9985

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985