RTEMS, Bootloaders and HW parameters

[Leon Pollak]

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