RFC: Remove BSP_Configuration

[Ralf Corsepius]

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.

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]

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

Ralf