RTEMS, Bootloaders and HW parameters

[Ed Sutter]

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
> 
>