Looking for BSP for Atmel AT91SAM7X-EK

[Feng, Kate]

Andrei Chichak wrote :
>> I'm still waiting for something better than C for embedded
>> work, until then I vote for C.

Joel Sherril wrote :
> I'm sorry this part of the discussion even came up. 
 
This came up because I wish to remind that
if there is any change in the structure of  RTEMS OS
or BSP,  please be object oriented instead of 
one-maintainer-mind oriented.   The change of
structure should not destroy the original merit of
the real-time programming that makes things work.
 
 
I have been constantly paged privately by people that
they want to violate  the LICENSE of the mvme5500 BSP
only because one claimed that one had changed the
structure drastically.   After all, it's STill  the same
copied code that operates real-time function.
I am tired of  being paged privately like this. 
 
Kate

________________________________

From: rtems-users-bounces at rtems.org on behalf of Joel Sherrill
Sent: Mon 12/17/2007 4:00 PM
To: Andrei Chichak
Cc: rtems-users at rtems.org
Subject: Re: Looking for BSP for Atmel AT91SAM7X-EK



Andrei Chichak wrote:
> Since I started this thread, I guess I can have a say too...
>
>  
Unfortunately, you asked a question that sparked a lot of
discussion that didn't help you.
> Being a newbie to RTEMS I have a different perspective than the others who have
> been doing this for a decade.
>
> I have found that a bunch of the BSPs are for boards that aren't made any more
> (CSB360, 336, 337), others have been deleted for various reasons (EFI332),
> others have had BSPs written but apparently never submitted (AT91SAM7X-EK
> http://www.rtems.com/ml/rtems-users/2007/august/msg00161.html).
>  

Normally we are pretty generous about leaving a BSP in the tree.
You are seeing the normal discussions of pruning after cutting
a release branch.

The Cogent boards may not be available anymore but at least
two of those BSPs do run on Skyeye and do provide examples
for CPUs that AFAIK are still in production -- so they are useful.

The EFI332 was a hobby board which the developer told us was
no longer in use by the community.  It needed some work (I don't
recall what) and there was another board MRM332 which covered
the same CPU model with a commercial board.  So that is why
that was killed.

I can't say why the BSP in that message wasn't submitted.  If
it had and the licensing is correct, it would have been in the tree.
I have emailed them and asked again now that you point it out.
That's all I can do.
> As a newbie looking to use RTEMS, I can look for a board that matches an
> existing BSP or roll my own. I have found that the deletion of BSPs (instead of
> moving them to a grave yard) removes a bunch of information from the pool, such
> as the proper boot sequence for a processor, that I need to roll my own.
>  
I don't know if you should deletion that way.  Usually the BSPs
deleted are some combination of

(0) no longer available even as example parts.
(1) not the only example BSP for that CPU or
(2) may not be the best example of the set or
(3) require significant maintenance to be good examples even if
     we can't test them.
> Some of the boards use a boot monitor that takes care of things like starting
> the processor and doing serial datacom (MRM332 using dbug32), so the code
> doesn't follow the documentation in the BSP and Device Driver Development Guide.
> There is also a large deviation in the style of the various BSPs.
>  
Yep.  An RTEMS BSP usually only does what initialization is required
after the loader puts it in memory.

The style differences are unfortunate but code for a board in any
style is better than no code.  The more common the code is (e.g.
CPU Kit code), the better the style and documentation.
> Granted, the guide is 1) a guide, 2) generated for a specific processor, and 3)
> done by someone as a "missing manual". I would have preferred a more generic
> guide with pseudocode explaining the various layers. Perhaps a style guide as well.
>  
Nothing money wouldn't solve. :)

There is a style guide in the Wiki.  The BSP and Drivers Guide
needs a review and update.  The Class material is much more current
and probably takes a completely different approach to presenting
the material.  I know it was completely reordered a while back
to do things in the order I think you should do them in when
developing a BSP.
> In the current conversation there is talk of canning a BSP because it doesn't
> conform to the current interrupt structure...where do I find out about the
> interrupt structure so I don't, as a newbie, generate something that will be
> shunned (but I don't want to change because it works)? Given that I am making a
> derivative BSP and have to make a decision between switching to RTEMS and
> coughing up for uC/OS-II in about a week?
>  
This doesn't impact the ARM.  The x86 and PowerPC are the
only ports which have ever used an alternative exception model.

This is strictly a PowerPC discussion and the history should
make you feel more comfortable about how serious we take
killing something.

Dates of interest:

  + x86 initial support - 1990.
  + PowerPC initial support - 1995.
  + PowerPC "new exception" - 1998/9.

Terms:

  + Simple Vectored (a.k.a old exceptions on PowerPC)
  + PIC Interrupts (a.k.a new exceptions on PowerPC)

The history is that the x86 and PowerPC ports were initially
developed without considering that the boards using those
CPUs always used programmable interrupt controllers.  This
means that the decoding of interrupt sources and turning
those into "vectors" is VERY board specific.  The "simple
vectored" model was used on those ports initially.  This is
what the m68k, SPARC and other CPU families have.

In the 1998-9 time frame, support was added for BSPs to
always help with the PICs.  This was called the "new exception
model" for lack of a better name at the time.

Unfortunately, this left the other to be called the "old exception"
model when the PIC interrupt model was added. We didn't kill
old exception  BSPs -- we kept around a huge amount of build
infrastructure to support the old BSPs.   It has been a maintenance
burden but one we think was appreciated by users who got to
take their time transitioning.

Over time, the set of "old exception" BSPs has shrunk to the
point where we want to kill the last two legacy BSPs.  There is
a BSP in place as an alternative to those being killed.

The helas403e BSP was submitted by Thomas Doerfler in 1998.

The gen405 was submitted in 2001 and was used as the basis
for the virtex BSP.

So neither BSP is of recent vintage and both have better examples.
Removing them opens the door to clean up that we have wanted to
do for a long time.

All ports use either the Simple Vectored or PIC Interrupt model
as dictated by the architecture.
> Is there anybody at OAR looking at the current crop of processors and evaluation
> boards and putting together BSPs speculatively?
Not unless someone pays for it.  We are not independently wealthy.  :D

We do develop BSPs for users as do other consultants on this list.

I should add that the Blackfin and NIOS ports are both relatively
recent additions.  Things are far from stagnant if that is what you
are worried about.
> Are they relying on the newbies
> to bring in the new blood? What is being done to grow the user and processor base?
>
>  
It's an open source project.  It is used on many things and each project
brings something and some people to the project.  There are more users
now than ever before.  RTEMS is used in more and more critical
systems.  It is used in universities.

We don't have a marketing budget and don't make you sign a license.
So I don't get the privilege of having that information.  I only get to
know about projects that say they are using RTEMS.  The scientific
and space communities have been very open about their use and
we can confidently state it is circling the Earth, Venus, Mars, and
on its way to the asteroid belt.  It is helping physicists unlock both
the secrets of the universe as well as decode Archimedes manuscripts.
It drives robots and tunes hearing aids.  It powers medical devices
and communications devices.

And that's just what people will admit to.  :)

> On C++:
> I realize that a lot of the users are in aerospace and have big memory budgets,
> but for commodity embedded stuff I follow the MISRA guidelines and all of my
> memory is statically allocated. I can't afford the call system bloat with 256K
> of RAM (although with that little memory, leaks are found pretty early). Also I
> found that C++ has crappy syntax and lots of theoretical features that can't be
> explained past some fictitious graphics package where circles and squares are
> interchangeable. I'm still waiting for something better than C for embedded
> work, until then I vote for C.
>
>  
I'm sorry this part of the discussion even came up.  :(

The bottom line is that we continue to analyze and improve and
refactor the BSP code.  The CVS head is different from the 4.8
branch already from BSP refactoring work.  It is a lot of work
to do things across all BSPs and not destroy something.  AFAIK
the head has continued to work nearly all the time in spite of
this type of maintenance.
> I don't want to make this sound like a rant or a critical flame, what you have
> looks great.
>
>  
I didn't take it as that.
> Thanks for doing this,
>
>  
If email isn't working for you or you have some concern,  just call me
directly.
Email and I will give you the extension number.

--joel

> Andrei
>
> ------------------------------
> Andrei Chichak
>
> Systems Developer
> CBF Systems
> Suite 4-038
> 11421 Saskatchewan Drive
> Edmonton, Alberta
> Canada T6G 2M9
> V: (780) 628-2072
> F: (780) 628-5542
>
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.com
> http://rtems.rtems.org/mailman/listinfo/rtems-users
>  

_______________________________________________
rtems-users mailing list
rtems-users at rtems.com
http://rtems.rtems.org/mailman/listinfo/rtems-users