RTEMS, Bootloaders and HW parameters

[Leon Pollak]

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
> 


-- 
            Dr.Leon M.Pollak
                Director
       PLR Information Systems Ltd.
Tel.:+972-98657670  |  POB 8130, H'Aomanut 9,
Fax.:+972-98657621  |  Poleg Industrial Zone,
Mob.:+972-544739246 |  Netanya, 42160, Israel.