RFC: Remove BSP_Configuration

[Joel Sherrill <joel@OARcorp.com>]

Ralf Corsepius wrote:
> On Thu, 2005-10-20 at 09:42 -0500, Joel Sherrill  wrote:
> 
>>Ralf Corsepius wrote:
>>
>>>On Thu, 2005-10-20 at 10:26 -0400, gregory.menke at gsfc.nasa.gov wrote:
>>>
>>>
>>>>"Joel Sherrill <joel at OARcorp.com>" <joel.sherrill at OARcorp.com> writes:
>>>>
>>>>>Hi,
>>>>>
>>>>>While teaching the class last week, it occurred to me that an RTEMS
>>>>>application has 2 copies of the Configuration Table and a separate 
>>>>>pointer to it in the executive proper.  Maybe this can be simplified.
>>>>>So I want some feedback.
>>>>>
>>>>>Currently:
>>>>>
>>>>>   + confdefs.h generated a structure named "Configuration"
>>>>>   + shared BSP code copies that to BSP_Configuration
>>>>>   + RTEMS proper does not know the variable name Configuration
>>>>>     or BSP_Configuration, so it takes a pointer in as an
>>>>>     argument to rtems_initialize_executive_early and saves
>>>>>     that address in a global pointer variable.
>>>>>
>>>>>My proposal would be to:
>>>>>
>>>>>(1) Eliminate BSP_Configuration entirely.  Do not copy
>>>>>     the generated Configuration to BSP_Configuration and
>>>>>     modified Cofniguration as required in the BSP.
>>>>
>>>>We have found BSP_Configuration to be useful at runtime, having a
>>>>well-defined struct to pull footprint info out of is nicer than defining
>>>>symbols in the linker script.
>>>>
>>>>We haven't had a use of CPU_Configuration however.
>>>>
>>>>The copying stuff related to these structs does seem a little clumsy,
>>>>but maybe its required or at least useful for other reasons.
>>>
>>>IIRC, this had been used to separate "initial ROM-based configurations"
>>>from "actual runtime-configurations".
>>
>>And to let RAM downloaded images be restarted.  We didn't know how to 
>>have a 2nd copy of the .data when in a.out/coff back in the dark ages. 
>>That's where it started.  Now I think this is easy to handle.
>>
>>But isn't this now what this type of trick now accomplishes:
>>
>>   /* initialized data section
>>      ld will load this at __text_end in the output file,
>>      but will actually locate it in ram.  By doing a
>>      memcpy( &_data_start, &_text_end, (&_data_end - &_data_start);
>>      during startup, we initialize our nonzero globals . */
>>   .init : AT (__text_end)
>>   {
>>     __data_start = .;
>>     *(.data)
>>     __data_end = .;
>>   } > ram
>>
>>
>>I think it would simplify things.  But I am concerned that
>>it is requiring the Configuration Tables to have a fixed name.
>>At one level it doesn't bother me at all. But at another, I worry
>>that I am missing something.
> 
> 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.

> Now I'd have to look up the details of how this consideration is
> connected to BSP_Configuration etc. ;)

I suppose now one could be smart enough to copy one of two 
configurations to BSP_Configuration and it is certainly possible in the 
future for the BSP to "fix" Configuration to reflect ROM or RAM 
requirements.

The tip of the iceberg is this code in libbsp/shared/bootcard.c:

   BSP_Configuration       = Configuration;

   BSP_RTEMS_Configuration = *Configuration.RTEMS_api_configuration;
   BSP_Configuration.RTEMS_api_configuration = &BSP_RTEMS_Configuration;

#ifdef RTEMS_POSIX_API
   BSP_POSIX_Configuration = *Configuration.POSIX_api_configuration;
   BSP_Configuration.POSIX_api_configuration = &BSP_POSIX_Configuration;
#endif

Configuration is itself in writeable memory and could have been loaded
from an initialized area by the start code.

I just want to eliminate this code and any extra copies of the data.

> 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