RTEMS, Bootloaders and HW parameters
Thomas Dörfler
Thomas.Doerfler at embedded-brains.de
Wed Nov 11 16:12:23 UTC 2009
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.
I hope this makes sense to you.
wkr,
Thomas.
Ed Sutter wrote:
> Folks,
> Sorry for the late reply here. I was out for the last week...
> Anyway, I'd like to throw in my two cents...
>
> I've seen a few different ways to pass parameters from boot monitor
> to application, here's a quick summary...
>
> 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
> 2. Binary data structure
> Pro: its quick to retrieve the data
> Con: if it changes both ends (bootloader and rtos) need to know
> 3. ATAGS
> Pro: quick to retrieve the data
> structure can vary without need for other side to know about it
> Con: it can be a little confusing to get used to
> 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)
>
> I've seen versions of linux that use #1, #2 & #3 (uMon can do any of
> them). In each of these
> cases, the OS is simply passed a pointer.
>
> Anyway, in my experience, I've used all of the above (I'm sure there are
> other techniques),
> and quite honestly I still find that the easiest and most extensible way
> to do this is
> just with something like xxx_getenv(). This DOES have the one
> requirement regarding the
> accessibility of the bootloader's text space when the RTOS takes over;
> however, that's
> only a problem if you can't make that hookup prior to turning on the MMU.
>
> Then, depending on the bootloader, the content of (and possibly even the
> presence
> of) certain shell variables can be used by the OS to determine what
> state the system is
> in (this may be dynamic) when it hands over control to the application.
> This makes it
> very easy to build your system so that the bootloader's environment can
> preconfigure how
> the application runs (debug mode levels, etc...).
>
> This whole notion of providing an API from bootloader to application
> provides a lot
> of interesting possibilities beyond just environment transfer. The
> obvious extensions
> would be things like a common console interface, common network
> interface, heap, etc...
> Even some sharing of exception handlers... this allows the bootloader to
> be the
> "base" that an RTOS can fall back on if it crashes; thus allowing the
> monitor to be
> configured to automatically reboot if this occurs; or optionally stop
> and allow the
> user to retrieve the core for post-mortem analysis. That's a whole
> other topic...
>
>
> Ed
>
>
> Leon Pollak wrote:
>> Thomas,
>>
>> You are absolutely right and I am also interested in the most possible
>> general solution.
>> That's why I want to understand your "objections".
>>
>>> I have no problem with getenv, as long as it is available throughout the
>>> system runtime. But we need a solution that offers the same API, even
>>> if:
>>>
>>> - boot monitors pass a data structure in RAM, that gets overwritten
>>> during startup.
>> This is a good "objection" case.
>> I should sharpen it - what to in the case when loader itself is
>> overridden by the application. Well, I do not know any other way,
>> except copying the environment aside...
>>
>> BTW, uMon also requires an initialization phase to be done before you
>> can use its services, including mon_getenv...
>>
>>> - applications want to have their vital data not under control of the
>>> bootloader, but in some other storage.
>> Hmm... Why the corresponding 'case' in the 'switch' can not extract
>> this data directly from that storage?
>>
>>
>> Anyway, thank you for raising the issue - intuitively we have this
>> need for years and each of us is going in its own way...
>>
>> It is high time for us to unify our efforts.
>>> Once again, for the existing boards using umon, mapping the "bsp_getenv"
>>> to "umon_getenv" may really be the suitable solution.
>>>
>>> wkr,
>>> Thomas.
>>>
>>>> >From your example I think I see a simple implementation.
>>>>
>>>> Let's suppose that you define in your bsp.h:
>>>> #define ETHMAC1 100
>>>> #define ETHMAC2 101
>>>> #define ETHMAC3 102
>>>>
>>>> and then in the driver you call (ThisIFn is the number of the
>>>> interface):
>>>> uchar ThisMAC[6];
>>>> memcpy(ThisMAC, bsp_getenv(ETHMAC1+ThisIFn), sizeof(ThisMAC));
>>>>
>>>> and in the bsp_getenv:
>>>> char* bsp_getenv(uint Request)
>>>> {
>>>> switch(Request) {
>>>> case WHATEVER YOU HAVE PARAMETERS:
>>>> ...................
>>>> case ETHMAC1:
>>>> Take MAC1 address fromever you like,
>>>> return its address
>>>> .................
>>>> }
>>>>
>>>> while bsp_getenv(...) is BSP specific implementation.
>>>>
>>>> Is it not enough OK?
>>>>
>>>> On Monday November 9 2009, Thomas Dörfler wrote:
>>>>> Peter,
>>>>>
>>>>> in a way you are right. I don't want to invent things again, if
>>>>> existing
>>>>> code already does what it should do. On the other hand, I would
>>>>> like to
>>>>> make this API as usable as possible. This includes:
>>>>>
>>>>> - putting data into the right format. E.g. it may be nice to get
>>>>> ethernet IP and MAC adresses already in the proper network data
>>>>> format,
>>>>> not a string. the same is true for baud rates etc.
>>>>>
>>>>> - being as versatile as possible
>>>>>
>>>>> - include handling for bootloader/configuration/default values
>>>>>
>>>>> I don't know micromonitor, but what I have seen as the interface
>>>>> package
>>>>> seems quite nice. So I can actually add the following code to my
>>>>> network
>>>>> driver:
>>>>>
>>>>> ...
>>>>> macstr = umon_getenv("ETHMAC1");
>>>>> ...
>>>>>
>>>>> But there are still various things that may have to be adapted in the
>>>>> network driver, if I use it on a different board (with a same/similar
>>>>> microcontroller), e.g.
>>>>>
>>>>> - the environment variable name may differ (because this board only
>>>>> has
>>>>> one ethernet IF it is called "ETHMAC")
>>>>>
>>>>> - the environment variable is not set at all because this board
>>>>> gets its
>>>>> MAC address from a different location (e.g. bunrt into a dedicated
>>>>> chip)
>>>>>
>>>>> - the ethernet address must be taken from an specific storage (e.g.
>>>>> application specific EEPROM) instead of from the bootloader
>>>>>
>>>>> ... and many other things that may be different. Up to now, this is
>>>>> treated in the networking(/console/clock...) driver and it must be
>>>>> adopted to different board to get its information. What I want to
>>>>> add is
>>>>> a BSP/board specific code module, that is responsible for collecting
>>>>> that data, wherever it can be taken from. And then ALL drivers can
>>>>> simply query that information in a uniform fashion.
>>>>>
>>>>> So I think this a bit beyond a simple "getenv" call. For most cases it
>>>>> may be mapped to it, but not always.
>>>>>
>>>>> wkr,
>>>>> Thomas.
>>>>>
>>>>> 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.
>>>>>>
>>>>>> Peter
>>>> _______________________________________________
>>>> rtems-users mailing list
>>>> rtems-users at rtems.org
>>>> http://www.rtems.org/mailman/listinfo/rtems-users
>>
>>
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-users
--
--------------------------------------------
Embedded Brains GmbH
Thomas Doerfler Obere Lagerstrasse 30
D-82178 Puchheim Germany
email: Thomas.Doerfler at embedded-brains.de
Phone: +49-89-18908079-2
Fax: +49-89-18908079-9
More information about the users
mailing list