RTEMS, Bootloaders and HW parameters

[Thomas Doerfler]

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
PGP:   Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.