RTEMS, Bootloaders and HW parameters

Joel Sherrill joel.sherrill at OARcorp.com
Mon Nov 9 11:48:26 UTC 2009

Peter Dufault wrote:
> On Nov 9, 2009, at 4:02 , Thomas Dörfler wrote:
>> I am always a bit suspect if one particular implementation is used  
>> as a
>> general API.
> I'm only sometimes a bit suspect when one particular implementation is  
> used as a general API.
> I hate it when an API is modified only by doing something like  
> prepending "rtems_" to the front of it (or by replacing "umon_" with  
> "rtems_").  If, for example, the uMON API is perfectly adequate for  
> what is needed now and in the foreseeable future and if it is used on  
> the majority of the boards using such a facility then go ahead and  
> standardize on it.
> I'm not saying this is the case, you have to use your good judgement,  
> but I've seen too many examples of mulltiplying APIs for no good  
> reason not to point this out.
I think Thomas is suggesting that RTEMS define a standard
BSP method to get parameters.  There can be multiple
shared implementations like other BSP methods.  So
we could have a standard umon implementation, u-boot
implementation, one for when you pass a command line
string, etc.  The BSP would pick one of these variations
or provide its own.

Thomas has dealt with generic system on chip BSPs
which sometimes come with different monitors or none.
Having a standard named method in the BSP whose
implementation varies is a good idea.

The U-Boot implementation would probably get some
information from its hw info structure and some from
environment variables.

The "command line string" style is used by pc386 and
would do something different.

I think umon provides everything we want through env


> Peter
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-users

More information about the users mailing list