RTEMS, Bootloaders and HW parameters

[Leon Pollak]

Thomas,

I agree with your trend. But still can not understand what is the problem with 
"simple getenv"...:-)

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
>