RFC: Remove BSP_Configuration

[Joel Sherrill <joel@OARcorp.com>]

Ralf Corsepius wrote:
> On Thu, 2005-10-20 at 11:52 -0500, Joel Sherrill  wrote:
> 
>>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.
> 
> We are treating Configuration as static, r/o, non-volatile initial
> configuration but are treating BSP_Configuration as a dynamic, r/w, and
> volatile run-time configuration.
> 
> What you don't see is what applications do with BSP_Configuration!

That I can't see so maybe the name should rename BSP_Configuration.

>>Yes I will end up mechanically having to edit every BSP which references
>>BSP_Configuration to use the new name.
> 
> 
> Which? Are you serious in wanting to call it "Configuration"? 
> Pardon, but this would be a bad choice!

confdefs.h generates a "constant" table which is called Configuration
and has done so for a long time.

The copy from Configuration (generated by confdefs.h) to 
BSP_Configuration is a hack which is equivalent to the procedure used to 
load the initial values into the .data section variables.  It was 
initially added so programs loaded into RAM could be re-executed but it 
is a partial solution since it only reloads one structure.

The initialization procedure does this:

   + (start.S) copy "shadow" copy of .data section initial values into
     the .data section in RAM since .data is by definition initialized
     but writable.  This should load the values in Configuration and
     BSP_Configuration.
   + (bootcard.c) copy Configuration to BSP_Configuration
   + ... modify BSP_Configuration as needed
   + (exinit.c) pass pointer into RTEMS.

As a potentially less intrusive change, I think the table generated by 
confdefs.h should be named BSP_Configuration and we should assume the 
BSP does the right thing with respect to the initial values for the 
.data section variables.  This would eliminate the variable Configuration.

Second, RTEMS should be able to assume the name of the configuration 
table and just use a hard-coded variable name rather than having an 
extra pointer variable.  This would eliminate some variables inside
RTEMS proper and likekly result in simpler code generated.

I think what is being missed is that "BSP_Configuration = Configuration" 
is a hack which is a poor substitute of loading the initial values for 
the .data section since it only covers one structure.

> Ralf
> 
> 


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
    Support Available             (256) 722-9985