Need help. when porting RTEMS to L4

[Joel Sherrill]

xi yang wrote:
> On Thu, Mar 20, 2008 at 1:06 AM, Joel Sherrill
> <joel.sherrill at oarcorp.com> wrote:
>   
>> xi yang wrote:
>>  > Hi all:
>>  > I am porting RTEMS on L4 micro kernel . I just
>>  > do it like what UNIX bsp does . But there are
>>  > some problems
>>  > I develop BSP like this
>>  > * cpukit/score/cpu/l4  (Like unix)
>>  > * c/src/lib/libbsp/l4/okl4 (like UNIX/posix)
>>  >  I copy files form unix bsp and change Makefile.am
>>  > and other files .
>>  > * touch okl4.cfg
>>  >   RTEMS_CPU=l4
>>  >   RTMES_CPU_FAMILY=arm
>>  >   RTEMS_CPU_MODEL=pxa255
>>  >
>>  >   RTEMS_BSP_FAMILY=okl4
>>  >
>>  The configure infrastructure uses RTEMS_CPU to select
>>  directories at the score/cpu and c/src/lib/libcpu and
>>  c/src/lib/libbsp level.
>>
>>     
>>> * Add score/cpu/l4/Makefile to cpukit/configure.ac
>>>       
>>  >
>>  >
>>  So you accounted for this one.  D
>>
>>     
>>> then ../rtems/configure --enable-rtemsbsp="okl4"
>>>       
>>  > This cause the toolchain to the host toochain ,
>>  > maybe it can compile some files ,then
>>  >
>>  Right. This configures the target to be your native machine (e.g. posix
>>  port)
>>  with a BSP that does not exist under libbsp/unix.
>>
>>
>>  > Make
>>  > but It doesn't compile any files , just say
>>  > make all , then ../rtems/configure --target=arm-rtems --enable-rtemsbsp="okl4"
>>  > Make
>>  > It doesnot compile any files, just say make all,
>>  >
>>  >
>>  That is looking for okl4 in libbsp/arm.
>>     
> So, if I want to do this way , I must have the l4-rtems- toolchain ?
>   
No you will use the arm-rtems tool chains and target
an L4 ARM BSP which might be based on an L4 specific
CPU model.
>>> What else should I modify the build system to let it compile ?
>>>       
>>  > anyone can help me ?
>>  >
>>  >
>>  Your configure points are confusing me.  You are treating L4 as a
>>  CPU architecture from RTEMS perspective.  What really has to
>>  change?
>>
>>  We have to know the answer to the above question to
>>  know where to distinguish between real hardware and
>>  an L4 version of the same hardware.
>>
>>  My gut feeling is that L4 should be treated as a specific CPU
>>  model within a CPU family because you still want to compile to
>>  ARM but probably have a somewhat perverted view of the
>>  interrupts and maybe the hardware, right?
>>     
>
> Yeah, I want to compile it to ARM now .
>   
See above.
>>  This would mean you should add okl4 as a BSP and possibly
>>  some ARM-L4 CPU model.  Say it is pxa255 for real, then make
>>  it pxa255l4.  Then you can treat it as a real raw pxa255 when
>>  possible and still ahve the ability to detect it as an L4 virtualized
>>  pxa255 when it makes something different.
>>     
>
> Yeah, that will add some #if #endif things to source code ^-^.
> Thanks, joel .
>   
I hope it doesn't turn it too ugly.  If it is a big deviation,
it may make sense to split them.  I can't make this
judgment until we know the differences.

I suspect they are relatively small so conditionals will
be OK.

libcpu should be full of examples on this type of thing.
>>  It may even be that the same BSP can work with one variant for
>>  real hardware and another for L4 virtualized with a few conditionals
>>  to account for the CPU model differences.  This is done by a few
>>  BSPs including the gen68360, mbx8xx, and motorola_shared.
>>
>>  --joel
>>  > Regards
>>  > _______________________________________________
>>  > rtems-users mailing list
>>  > rtems-users at rtems.com
>>  > http://rtems.rtems.org/mailman/listinfo/rtems-users
>>  >
>>
>>
>>  --
>>  Joel Sherrill, Ph.D.             Director of Research & Development
>>  joel.sherrill at OARcorp.com        On-Line Applications Research
>>  Ask me about RTEMS: a free RTOS  Huntsville AL 35805
>>    Support Available             (256) 722-9985
>>
>>
>>
>>     


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985