RTEMS, Bootloaders and HW parameters

[Thomas Dörfler]

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.


-- 

--------------------------------------------
Embedded Brains GmbH
Thomas Doerfler        Obere Lagerstrasse 30
D-82178 Puchheim       Germany
email: Thomas.Doerfler at embedded-brains.de
Phone: +49-89-18908079-2
Fax:   +49-89-18908079-9