MIPS BSP

[gregory.menke at gsfc.nasa.gov]

 > 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. :)

MIPS In Space!!!


 > > 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 think it would be good to do so.  It would cause a measure of
duplication because of the similarities of the processors, but theres
enough mips1/mips3 complexity in the header files that its already
confusing anyhow.

 
 > > 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. :)

One currently interesting area is score/cpu/mips.  Its very mips1
oriented at the moment.  It <should> work with others in that family,
as it doesn't take liberties with the stack frame & it honors the
register set definitions coming from iregdef.h.



 
 > > 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 agree- a per-cpu "localized" version of a standard cache support api
should be better than a pile of per-bsp & per-cpu variants.



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

Oh how lovely.  This is almost as fun as real-mode segment stuff on
x86.

I think most all the preprocessor tests work off __mips at the moment.



 > > 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. :)

As I understand it, you may have the option to configure where the
exception vector is located via a bit in one of the processor's
configuration registers.  I <think> this is a bsp issue because a
particular board will set it one way or the another depending on the
board itself.

With respect to startup code, the exception vector location a bsp will
use is one or another of a set of well-known addresses.  Setting it
for RAM space only involves moving the address of the handler code to
the right location, so I don't know if its even worth going to trouble
making such code shared.  If per-cpu defines can specify all the
addresses a given processor supports in a nominally consistent way,
then bsp's can choose one or at least get a reasonable default.
Presumably this could be applied for the basic vector(s) that need be
set up for RTEMS to boot.  At that point its up to the application to
do extra stuff.

It doesn't completely solve the problem, but I think it defines the
right kinds of things in the right places.

What is of some interest to us is how to handle interrupt vectors vs
exceptions.  We chose to put both in a single big vector table, with
#defines providing a measure of symbolic naming.  The exception vs
interrupt vectoring front ends are slightly different, but ultimately
vector thru the single big table.

We've only messed with interrupt service thru the vector table at this
point, but it works fine- so we expect the exception logic to not
offer much trouble.  We already catch address alignment exceptions
just fine.

I think this may be a significant source of per-cpu variation.
Possibly each processor's interrupt & exception architecture could be
associated with that processor alone (We #defined MONGOOSEV_whatever
interrupt and exception vectors).  So if code moves from one processor
to another, the vector defines will change as well, but the fix only
requires looking up the right ones for the new processor.  ISR's
central to RTEMS operation like the timer tick would need a
centralized #define I imagine- though for on-chip interrupts,
presumably that will be dealt with in libchip already.

Greg