RFC: Remove BSP_Configuration

[Joel Sherrill <joel@OARcorp.com>]

Ralf Corsepius wrote:
> On Thu, 2005-10-20 at 10:46 -0500, Joel Sherrill  wrote:
> 
>>Ralf Corsepius wrote:
> 
> 
>>>I think we are talking pass each other:
>>>
>>>A "initial ROM-configuration" is static, r/o and non-volatile in most
>>>cases, while a runtime-configuration is dynamic, r/w and volatile in
>>>most cases.
>>
>>But there was/is no distintion between the values of the ROM copy and 
>>RAM copy.  Both are intended for a single configuration of the BSP 
>>whether that is to run out of ROM or RAM.
>>
>>This was really just a hack that dates back to not having the ability to 
>>place the initial values for the .data section in a separate location 
>>and having start code copy it.  The .data section cannot permanently 
>>reside in ROM because it is initialized but writeable.
>>
>>
>>>To support this, you must have 2 sets of configurations being available
>>>at run-time. Simply copying anonymous memory from ROM to RAM is not
>>>sufficient. You will want to know each and every detail about both
>>>configurations otherwise you won't be able to switch between.
>>>
>>>[Consider "warmstart"/"SW"-resets and the like]
>>
>>Yes but the current setup doesn't support this either.
> 
> 
> Have a look into c/src/lib/libbsp/sh/gensh1/startup/bspstart.c
> and you'll see that we use it -- we even use CPU_Table.

We are missing each other today. :)

Yes you are using the BSP_Configuration structure.  But with no magic 
switch between multiple configurations that I see.  As long as 
Configuration (or rtems_configuration) ends up initialized and in RAM,
it still works.

Yes I will end up mechanically having to edit every BSP which references
BSP_Configuration to use the new name.


--joel