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

pc386 on 386sx



>>>>> "joel" == joel  <joel at OARcorp.com> writes:

joel> On Thu, 29 Jul 1999, erik.ivanenko wrote:

joel> EriC's statement that is code that "only depend on processor and not on
joel> rtems executive code" is very clear.  

Thanks :-)

joel>      - numerous clock/timer/interrupt controller drivers and vector
joel>      support for the mpc8xx, ppc4xx, MIPS, sh7032, etc.

I think it is very simple to understand why. Some chips contains the
usual IO subsystem directly integrated (mpc8xx, various MIPS, 683xxx, ...).

So for theses chips, what is usually contained in a BSP, has been moved 
into the CPU part. Then it usually breaks MY libcpu definition, because 
the code will connect interrupts, handle them and maybe trigger events...
One could even wonder why there is still a BSP (except for very
early initialisation and additionnal external IO's...). This approach
is only suitable if interrupt management is provided bu exec/score/<cpu>
which is I think a bad idea...

I would say that the "right" definition/location for integrated IO 
subsystem code would be a libcpuIo if not directly a BSP. I see several 
advantages of doing so :

	  - It would solve the problem faced by joel, as the libcpu
	  code could stick to my definition while the libcpuIo code
	  would stick to "usual" definition, on top of RTEMS,

	  - It would solve the problem of having duplicated code for
	  similar cpu (cpu having the same cpu heart but different IO 
	  subsystem  like in the vaste 683xx familly that have all a cpu32
	  heart or the 8xx PPC familly),

	  - Revolve the absolute need to implement interrupt handling
	  in score/<cpu> as It could be done in libcpuIo... and shared
	  if needed by introducion a libcpuIo/shared like in libbsp/i386/shared...

joel> EriC's point to me is that there is distinction that should be made
joel> between code in score/cpu which should only be used outside RTEMS with
joel> extreme care and the "below/beside" code which is fairly safe to use in
joel> both RTEMS proper and in applications which are willing to do so.

Every usual inline code for byte swapping, bit string search interrupt masking,
execption vector manipulation, etc, fits obviously in this category.

The problem I originally faced (before the make preinstall concept was introduced)
was that I needed to use some of score/cpu/<cpu>/*.h files before they were
available. So as what I need was not rtems rrelated, I moved it to libcpu/...


joel> I feel like I have finally had an insight.  The floor is now open to
joel> convince me I have not had one or to help work out a mechanism to handle
joel> this new "below/beside" code.  I realy don't think identifying it is the
joel> problem. cpuModel fits the bill nicely as a test case. :)

At least we exchange idea and thus progress in our perception of what would
be perfect vene if noone has really time to make it tangible...

-- 
   __                 
  /  `                   	Eric Valette
 /--   __  o _.          	Canon CRF - Communication Dept
(___, / (_(_(__         	Rue de la touche lambert
				35517 Cesson-Sevigne  Cedex
				FRANCE
Tel: +33 (0)2 99 87 68 91	Fax: +33 (0)2 99 84 11 30
E-mail: valette at crf.canon.fr	http://www.crf.canon.fr