Lib CPU

[Joel Sherrill]

Very few comments inserted below. :)


Steven Johnson wrote:
> 
> 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.

And logically it still is considered as such.  Only the code under
cpukit is considered completely BSP and application independent.

When constructing your BSP, you are free to completely ignore libcpu
and libchip if you like.

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

It is intended to be a compilable documented piece of example code but
I am sure it has bit-rotted.  At one point, the nocpu/nobsp
configuration
was regularly built by an arbitrarily chosen cross toolset.  It is
not currently in the automated test build but would be a good addition.

I am ashamed to admit that from memory I do not even remember how to
build it at this point. :(

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

Eventually the code under cpukit will be packaged as a library which 
is separate from the BSP kit.  The BSP kit will include libcpu.

> 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

The automated test build builds every multilib configuration using
make RTEMS_BSP="" but does not set RTEMS_CPU.

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

What do you think is not being covered by building all ports with
--enable-multilib and using the above make command?

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

I think we are heading in the same direction but the travel done the
path is slow.

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

I am glad to see Ralf got to you before I dug out the test
configurations
I regularly build with that.  I don't think it works for EVERY CPU
combination
but the basic infrastructure is working.

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

I think your comments on structure are right.  libcpu is logically part
of
the BSP kit and can be used or ignored at the BSPs discretion.  

> Regards,
> Steven