RTEMS, Bootloaders and HW parameters

[Leon Pollak]

Thomas,

May be I miss something....

I thought that this "translator" will be the bootloader specific 
implementation of, let's call it, bsp_getenv(NAME).

The names used in RTEMS are (will be) constant and known throughout the RTEMS.
bsp_getenv(NAME) will translate it into some bootloader specific call or db 
extraction action.

For the uMon it will simply call the mon_getenv with possible translation of 
the parameter name (in uMon "ETHADD2" is the name of the second IF MAC 
address).

To simplify the code, the RTEMS names may be numeric constants, defined 
somewhere in the BSP - bsp.h, for example.

Sorry, if this shoot is out of the target...:-)

On Monday November 9 2009, Thomas Dörfler wrote:
> Leon,
> 
> I am always a bit suspect if one particular implementation is used as a
> general API.
> 
> Problems that would not be solved with your recommendation are:
> - The same things may be named differently by convention in different
> boot loaders. e.g:
> - the MAC address of the second ethernet IF of a board may be named
> "FECMAC2" or "fec2addr". It may be stored as 6 bytes, as a
> null-terminated hex string with or without ":" or "." or in a different
> format
> - the bootloader might also pass in a data structure, that contains part
> of the required information at fixed locations
> 
> RTEMS should accept this information in the way the bootloader provides
> it. And therefore I would like to see a module, that translates this
> information into a RTEMS-specific format. It may then be queried using
> identification string (the same way "mon_getenv" works). But the strings
> should have a common format and the result types should have this also.
> 
> wkr,
> 
> Thomas.
> 
> Leon Pollak wrote:
> > Thomas,
> > The concept of uMon seems to me rather universal :-)
> > I mean the usage of the function mon_getenv(VAR_NAME).
> >
> > May be this can be a model of the mechanism: each time the BSP wants to
> > know a value of some parameter, it calls some getenv(PARAM_NAME) function
> > from the BSP.
> > And this function, in turn, takes care of providing the parameter value
> > in appropriate (for the bootloader) way.
> >
> > On Monday November 9 2009, Thomas Doerfler wrote:
> >> Leon,
> >>
> >> up to now I did not work with micromonitor, but heard a lot about it.
> >>
> >> We are working with U-Boot, DBug, TQMon, GRUB and several other
> >> bootloaders, all of them have a way to pass HW parameters to the booted
> >> application and all of them do it differently.
> >>
> >> So my idea is to have a module, that collects this information and
> >> includes a service to query that information. The "collect" part will be
> >> specific to a certain bootloader but may be portable/generic between
> >> various BSPs.
> >>
> >> I would like to contact you or Ed Sutter when it comes to the real
> >> implementation, just to prove that the concept also works fine for
> >> systems booting with micromonitor.
> >>
> >> wkr,
> >> Thomas.
> >>
> >> Leon Pollak wrote:
> >>> We use the excellent loader uMon from Ed Sutter for about 10 years.
> >>>
> >>> We pass all necessary parameters via uMon environment variables.
> >>> This seems to be very structural and comfortable way.
> >>>
> >>> Usually, uMon is prepared (mostly modified) by HW people and they set
> >>> the env.vars, which are easily read from console.
> >>> Then SW people can take them into BSP using mon_getenv function.
> >>>
> >>> On Sunday November 8 2009, Thomas Dörfler wrote:
> >>>> Hi,
> >>>>
> >>>> some days ago I onve again added support to pass parameters from a
> >>>> specific boot loader (Freescale DBug) to an RTEMS BSP. While I was
> >>>> modifying the ethernet driver and the console driver and the bsp
> >>>> startup to get bts and pieces from the boot loader, I got the
> >>>> impression that this is all wrong :-(
> >>>>
> >>>> The parameters I am talking about are:
> >>>> - console baud rate
> >>>> - UART port to be used for console
> >>>> - actual memory start/end address (or addresses...)
> >>>> - CPU clock speed
> >>>> - BUS clock speed
> >>>> - base clock speed for peripherals (like UART, timers...)
> >>>> - ethernet MAC addresses
> >>>> - primary ethernet port to be used
> >>>> - initial IP addesses for client, server, DNS, gateway....
> >>>>
> >>>> Wouldn't it make sense to establish a different structure to collect
> >>>> and then spread this information? What I have in mind is sort of a
> >>>> database, (in fact this can be an extended BSP configuration 
> >>>> structure or something similar), that allows to:
> >>>>
> >>>> - write a routine like "bsp_params_init_from_boot()", that fetches as
> >>>> much info as possible from the boot loader and stores it in this
> >>>> bsp_params database
> >>>>
> >>>> - have a mechanism to override these parameters from bspopts.h, of set
> >>>>  there
> >>>>
> >>>> - have a function that can be used by all drivers to get the relevant
> >>>> values.
> >>>>
> >>>> This would allow us to make many drivers generic again, even the
> >>>> questions "where do I get the initial baudrate", "which port should be
> >>>> /dev/console", "what is the system bus frequency" etc. would get
> >>>> generic answers.
> >>>>
> >>>> What do you all think about this?
> >>>> Should I make a proposal for such a database?
> >>>>
> >>>> wkr,
> >>>> Thomas.
>