RTEMS, Bootloaders and HW parameters
Thomas.Doerfler at embedded-brains.de
Mon Nov 9 09:02:59 UTC 2009
I am always a bit suspect if one particular implementation is used as a
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
- 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.
Leon Pollak wrote:
> 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
> 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:
>> 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.
>> 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:
>>>> 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
>>>> - have a function that can be used by all drivers to get the relevant
>>>> 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
>>>> What do you all think about this?
>>>> Should I make a proposal for such a database?
Embedded Brains GmbH
Thomas Doerfler Obere Lagerstrasse 30
D-82178 Puchheim Germany
email: Thomas.Doerfler at embedded-brains.de
More information about the users