RTEMS, Bootloaders and HW parameters

[Chris Johns]

Thomas Dörfler wrote:
> Ed,
> 
> thank you for your reply. I really was waiting for it because it seems
> you have been active in this area for some time. Your summary of
> parameter passing methods between bootloader and application is quite
> useful.
> 
> But:
> 
> Your conclusions are not really along the track of what I have in mind.
> I have been working with various bootloaders without really having the
> choice which bootloader I can use, because our customers simply come up
> with a board and it is already equipped with a certain bootloader. Its
> choice is beyond our scope so, in short, we have to live with whatever
> the board manufacturer has chosen to put on his boards.
> 
> So what I want to define in the next weeks is not really an API between
> bootloader and BSP/OS/drivers/application, but an API between
> _BSPstartup_ and OS/drivers/application.
> 
> So what I have in mind is an RTEMS-defined "database" (or environment or
> whatever it will really get) with well-defined entries, well-defined
> entry names and well-defined entry data formats. So the
> OS/drivers/application can use the same queries for these entries (e.g.
> to get the real memory size equipped, the MAC address of the third
> ethernet IF, the console baud rate to be used....).
> 
> And the BSPstartup is responsible to fetch the proper information from
> the bootloader (and this is highly dependent on which bootloader is
> really equipped) and either store it in the "database" or translate it
> into the data format that RTEMS has defined for this item.
> 

Thomas, have you consider something like the sysctl MIB approach but simpler. 
It is thread safe and can grow as needed by linking in different object files 
how-ever that is achieved. It supports complex structures like tables, eg more 
than one timer, NIC or reset/watchdog device, and you can iterate in a 
structured way. I am not saying you have create a sysctl for RTEMS, but I 
think some of the ideas may be useful.

I think this API is important and support the push to have one.

> I hope this makes sense to you.

It does make sense. We need to be independent of the boot monitor and let the 
BSP boot strap code interface to the specific monitor. This way the technical 
and license issues can be resolved independent of the application or RTEMS.

>> 1. ASCII command line
>>    Pro: ASCII is good  'cause it eliminates problems with endianness,
>>         data size etc...  you just parse it and you get what you need.
>>    Con: the line can get long if you have a lot of parameters

It suffers when expressing more complex types, eg tables. A command line is an 
important tool at the system level for configuration, how-ever I am not sure 
boot monitor to BSP interfacing is a suitable use.

>> 4. Environment variables
>>    Pro: easy to use and expand
>>         the OS can retrieve only the information it needs
>>         ASCII based (see above)
>>         Very intuitive
>>         Doesn't need a bootloader update to add new variables
>>    Con: you need a hook into the monitor's code to call something like
>> 'mon_getenv()'
>>         can't use this approach if the bootmonitor's text space is not
>> available when OS takes over
>>         (which may be the case when MMU is activated early in the OS
>> startup)

This could be considered binding the boot monitor to the application so we 
would need to make sure license issues are handled where this occurs, eg GPL 
boot monitors. With GPL monitors we would need to take a copy of the data 
passed and manage with our own code.

Chris