[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: cpukit/bspkit split.



Sergei Organov wrote:
"Joel Sherrill <joel@OARcorp.com>" <joel.sherrill@OARcorp.com> writes:

Sergei Organov wrote:

"Joel Sherrill <joel@OARcorp.com>" <joel.sherrill@OARcorp.com> writes:
[...]


There is a PPC_INTERRUPTS_MAX which still remains to be addressed.
Ralf.. I think the the MIPS defines that in libcpu as a variable used by the
cpukit.

IMHO, it's time to define generic interface between cpukit and the rest of RTEMS BSP that will ensure compile-time independence of cpukit, or at least to document some guidelines. It seems that pre-multilib BSP interface definitions don't address the issue as in fact every BSP is now split between cpukit and the rest of libs and there is no definition of the interface to be used on this split line. Does it sound reasonable?

That largely exists. When we started splitting the CPU kit from the BSP and libcpu parts of the tree, most of the ports were clean.


Guess those that didn't have any CPU variants or where CPU variations were
in fact insignificant? ;)

We can do the same for PowerPC, -- let every CPU variant be a separate
RTEMS port, i.e., just forget that they are all called PowerPCs, --
every BSP then will be pretty clean with respect to CPUkit split ;)


The porting guide is in general pretty close.


Well, I'm looking at

<http://www.rtems.com/onlinedocs/doc-current/share/rtems/html/porting/index.html>

Do you mean this one? If so, I'm afraid it's far from being close. It
even doesn't mention anything like cpukit or bspkit and immediately
jumps to the reference to non-existing directory c/src/exec/score/cpu:

<http://www.rtems.com/onlinedocs/doc-current/share/rtems/html/porting/porting00004.html>

Then, "some_other_cpu_dependent_info" in the "rtems_cpu_table" seems
to be problematic as well.

Is there something more recent that I've missed?

No. The file referecnes need to be updated and the document needs to be updated to reflect that it is a CPU Kit porting guide. Traditionally that was all you ported in RTEMS.


It captures the CPU dependent features the RTEMS proper code under cpukit needs to know about.

[...]

The rules for cpukit vs bspkit are actually quite simple. If gcc
distinguishes a variant, then cpukit can know about it. If that
variant is not detailed enough to distinguish two CPU cores that
CPUkit has to know about, then we have to address that.
The rub is that there seems to be one unique piece of the port for
each architecture that you have to based on cpu model not ISA variant.


If we require CPUkit to have only code that is based on ISA variant,
then this problem goes away, right? That once again raises a question
how in fact the code is divided, why it is divided this way, and isn't
there a better way to divide it. All these questions could and should be
answered by designing the interface I'm speaking about.

The base point for why is easy. It is at a minimum divided based upon the level of multilib distinctions gcc and newlib makes. We want cpukit/ to be multilib'ed using the same variants the *-rtems gcc/newlib binaries do.


There are n CPUs with a 603e/G2 core and gcc doesn't know ore care about the model names. Ideally RTEMS cpukit/ wouldn't know either.

It might be number of interrupts or status register bits that are
valid, etc, etc.


That's where the problem of undefined rules for splitting come into the
picture, IMHO. Where is the definition of the list of all the things
cpukit cares about? Is this list architecture dependent? Should it be
architecture dependent?

The guidelines are architecture independent but the reality is that some things are defined by one ISA and left to the whims of the implementer on another. On the MIPS for example, you are given 8 bits (I think) as a interrupt mask. What they mean is left to the implementer. Isn't that special?


So on that ONE architecture, you can't know the answer to every question about those bits until you know the CPU model. Is this enough to write CPUkit? If the answer is no, you have to define a mechanism to get that info out of libcpu/bsp and still be able to compile cpukit/.

One general thing that is almost never knowable by CPU kit is caching details.

Notice how the PowerPC port is evolving now. Ralf proposed some
conditionals to remove/consolidate, then reduced the multilibs. Then
everyone jumped in and said "you can remove that" or "why is that
there?". Once the mess is straightened out, it will really be quite
simple.


I'm afraid it won't be that simple anyway. Probably the number of
multilib variants will be reduced, but the question of figuring out the
exact interface between CPUkit and the rest of the system will remain.
Just try to put yourself on a place of a new programmer trying to
implement yet another CPU variant. Usually she will select a way of
least resistance and the situation will tend to return back where it is
now.

Ralf, I and others have cleaned up the other ports to have an interface between that CPUkit and libcpu/bsp for that port. Those other ports are "multiib clean". We generally did not bother anyone with the changes we made over the past few years.


Now we are looking at the biggest and ugliest port and people are noticing.

What you are suggesting is valid. Once we know what MAY need to be known between the CPUKit and libbsp/libcpu, we can unify that and define the interface more cleanly. The reality is that it will be a set of
data items and calls that are NOT needed on all ports.


But that doesn't always work. One example is hooks at the VERY bottom that may architecture specific. But that can be covered by saying "PowerPC CPU models must provide X."

What I'm talking about is a [set of] '.h' file(s) that contains entire
CPUkit to the rest of BSPs interface and only that interface. There
should be defined not only what should go into the file(s), but with the
same significance what *must not* appear in this file(s). E.g., it
should be a documented requirement that there should be nothing but what
is actually required by the interface, -- especially no any #ifs that
can't be resolved by defines provided by the multilib variants.

I won't argue with that at all. What we are doing now is cleaning up the existing powerpc port so that is even possible.

Let's take a look at the current situation. Consider the authoritative
example of how things should be implemented, the "no_cpu" port. The
"cpu.h" seem to define the interface in question. It in turn includes
two more files, "no_cpu.h" and "types.h". I've carefully read all the
three and found no requirements in them that are violated by the current
PowerPC port's "cpu.h" and "powerpc.h". However, "powerpc.h" (as well as
"cpu.h") obviously violates CPUkit independence requirement as it uses
#ifdefs not supported by any of multilib variants. The bad thing is that
nothing in RTEMS documentation or no_cpu port suggests that it's broken.

That's a valid point. There should be some guidelines in the porting guide and it must also be expanding to include interactions with libcpu.


Well, for me it seems that "no_cpu.h" and therefore "powerpc.h" should
be just eliminated altogether. Their purpose in cpukit is unclear and
comments in the no_cpu.h are misleading, IMHO.

I will argue this. no_cpu.h is intended to be a starting point for new ports of the code under cpukit. It is compileable and a good starting point.


Whether it is worth maintaining with the low number of new ports is up for debate.

I can't follow how you jumped from nocpu to powerpc.h though.

Now comes a surprise: PowerPC port has in fact 2 "powerpc.h" files,

c/src/lib/libcpu/powerpc/rtems/powerpc/powerpc.h
cpukit/score/cpu/powerpc/rtems/score/powerpc.h

both claiming to be

/**
 * @file rtems/score/powerpc.h
 */

what's that? Did the former has been forgotten to be removed from the
CVS as it seems that it's the latter that ends up being installed?

I think that's a file that was copied last week as part of the cleanup and the Doxygen comment wasn't updated. Don't read too much into that one. It is just left over fomr the recent moving party.


If everyone keeps offering constructive criticism and saying CPU X and Y
should be able to use the same multilib, then we will make it.


That won't help to fix "powerpc.h", especially its mpc860 and mpc8260
interrupts definitions, I'm afraid. I think external (to the CPU core)
interrupts just shouldn't be there, -- only architecture-defined
exceptions. The fact that a PIC is built into the chip isn't an excuse
to put that vectors into this file.

How do you get a unified set of vector numbers for external interrupts for device drivers?


I think the mips port is closer to right here. The generic vector/isr.S
code invokes a CPU/BSP specific routine to decode PICs, etc. The maximum number of vectors is specified by libcpu which may be overridden by the BSP.


This in turn once again raises a problem of absence of separate
raw-exception/c-exception/interrupt handlers/masks support in the
RTEMS-to-user and RTEMS-to-CPU APIs. Was there any progress in this area
recently?

Not really. It is a logical next step after the PPC code is cleaned up and PCI API is unified.


FWIW I am going to make the x86 PCI API match that of the PPC. This looks to only require a few files to be modified.

The next step will be getting help comparing .S files in various BSPs and
seeing if we can consolidate them under fewer files. No one can test every
variant but with care, we should be able to reduce them mechanically with
little risk.


Yeah, at least that seems to be doable and will provide better starting
point for subsequent cleanups and enhancements.

That's where we are now. Cleanup and moving things around. Once they are in the right places, we can unify and change them. I personally do not want to change 27 powerpc .S files. :)


Any help you can provide in reducing that set will help. I just randomly compared the vector.S file from mbx8xx and mpc8260ads and see that the only real difference is in that the MSR_IR and MSR_DR bits are not touched in one of them.



--joel