RTEMS, Bootloaders and HW parameters
chrisj at rtems.org
Wed Nov 11 23:21:36 UTC 2009
Thomas Dörfler wrote:
> 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
> 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
>> 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
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.
More information about the users