Lib CPU

[Steven Johnson]

Chris,

Re: your response to me directly on the issue of multilib :- I Understand.

Let me snip this conversation a bit and concentrate on a specific core 
issue with RTEMS, and in particular the MPC860 (and variants).

But before I say anything further let me say this: "I Think RTEMS is 
fantastic.  I think the work you guys do is fantastic."

[SNIP]
Ralf said:
 > The basic feature, code under cpukit must fullfil is to be
 > BSP-independent.

>Steven Said:
>>>Ideally I'd prefer not only no bsp, but no cpu stuff. 

OK, now some background:

A Long time ago (years) I ported RTEMS V4.0 (without networking) to 
CodeWarrior for the PowerPC under windows.

But when I ported it (which involved some pretty big changes because 
Codewarrior back then wasn't much like GCC at all.)  I decided to change 
the BSP/LibCPU Implementation.

I Made the Library completely independent of any particular CPU or BSP. 
  It just built.  The CPU specific stuff resided outside the ported 
Rtems Library all together.

This made life very easy.  The LibCPU Stuff became more a part of the 
BSP than the OS.

Now the discussion:

Now I understand the theory that the code under cpukit should be bsp 
independent.  If that is to be true, it should not impose anything on 
the bsp either, otherwise it is not bsp independent.

For example the mpc860 has 2 execption handling mechanisms in cpukit in 
the rtems tree (new and old).  My BSP wants to use a slightly different 
mechanism (similar to new, but it is different).  The reason is when I 
ported the library all those years ago, I decided I didn't like the 
exception handling mechanims in the then existing MPC860 BSP's, and so 
created my own.  The MPC860 has a very complex and highly customisable 
exception handling mechanism, it can be done in a number of different 
ways.  Mine involves some highly tuned assembler that handles and 
despatches all exceptions (Raw IRQ's, CPM and SIU Interrupts) in the 256 
bytes available in the base exception handler.  These things can be 
re-configured by software in the MPC860, and different priorities can be 
given to things.  All this means is that the excpetion handling should 
really be part of the BSP, at least in the case of the MPC860, because 
there are so many ways it can be done, some are better for different 
applications.  Now on other processors where exception handling is cast 
in stone by hardware (and not cpu assisted as in the powerpc) this case 
may be different.

Most of the other files in CPUKIT for the MPC8XX are fine, because they 
are really just hings like "Enable Interrupts" and an unsigned32 maps to 
an unsigned int, etc.

But then we have LibCPU under c/src/lib/libcpu

As far as the MPC8XX is concerned, all of this tuff (as far as I am 
concerned) is really stuff for the BSP.  Such as uart drivers 
(console-generic), mmu handling (see below) and other drivers.

All of which are tweaked for my BSP.

Re: MMU Handling.  Just like exceptions, the MMU can be handled in a 
number of ways.  The way documented by Motorola is just one, and it is 
not the most efficient.  Again, we use hand coded assembler and a simple 
MMU scheme to fix our SDRAM into one contiguous map, which would 
otherwise have great gaping holes.  Again the MMU is software assisted, 
and so can be done in any number of ways.

Now don't get me wrong the sample code here is invaluable for reference. 
   It is also highly usable as is, and Im sure a lot of people use it 
without touching it.  That isn't the point.  The point is that it is all 
stuff that should be fair game for a BSP to take control of, without 
creating a whole new CPU in the source tree this can not be done. (Or 
without patching the tree which is what I do.)

Now I have tried to use no_cpu as this is really what I want.  Build 
RTEMS for whatever processor, but do not build anything under 
c/src/lib/libcpu and also not cpukit/.../old or new exceptions.  But I 
don't think it can actually be built. Im not sure what it is for 
otherwise though, so I would be happy to be wrong.

To actually build rtems, you also do not need very many of the other 
definitions under CPUKIT.

Personally I think the definition of CPUKIT should be a lot more 
restrictive.  CPUKIT should only have stuff in it that the rtems library 
itself needs to compile.  Everything else should be part of LibCPU, 
which should be able to be excluded from the build of RTEMS.

Even with multib this should be possible, you should be able to 
configure rtems with multilib, and then make RTEMS_BSP="" RTEMS_CPU="" 
all install

Then you would truly have an RTEMS that is seperate from application 
considerations.

Im not making this discussion for no purpose, nor do I expect others to 
fulfil my wish list.  If this is a goal others want (most importantly 
Joel)  then i'm happy to contribute to get it done.  The problem I have 
is every time I try to touch configure/autoconf/automake stuff I 
horribly break it and can never get it to work in any sane way.

If no-one else thinks this is worthwhile, or that i'm a complainer, then 
that's fine too, Ill just keep patching the tree.  Also im not 
suggesting this should happen any time soon (like before 4.6.0 is released).

For what it's worth I did try to work out why --enable-bare-cpu-flags 
doesn't work anymore, but horribly broke the configure stuff in the 
attempt, so I gave up.  Had I the skill to fix it, I would, and a patch 
would be attached to this email :)

Also, the foregoing should be understood to be limited to MPC8XX CPU's 
I dont use any others with RTEMS, and so can not comment on them.  I do 
however suspect the same issues would exist to varying degree's.

Regards,
Steven