RTEMS, Bootloaders and HW parameters

[Thomas Dörfler]

Leon,

I am sure this is enough for many BSPs. Your sketch has a generalized
API that the BSP can redirect to a suitable mechanism. So that's it.

Leon Pollak wrote:
> Thomas,
> 
> I agree with your trend. But still can not understand what is the problem with 
> "simple getenv"...:-)

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.

- applications want to have their vital data not under control of the
bootloader, but in some other storage.

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


-- 
--------------------------------------------
IMD Ingenieurbuero fuer Microcomputertechnik
Thomas Doerfler           Herbststrasse 8
D-82178 Puchheim          Germany
email:    Thomas.Doerfler at imd-systems.de
PGP public key available at:
     http://www.imd-systems.de/pgpkey_en.html