RTEMS, Bootloaders and HW parameters
Ed Sutter
esutter at alcatel-lucent.com
Wed Nov 11 16:43:54 UTC 2009
Thomas,
Ok, I see. You're one level higher up than what I was talking about.
Thanks for the clarification,
Ed
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.
>
> 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
>
>
More information about the users
mailing list