[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: RFC: Remove BSP_Configuration

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@gsfc.nasa.gov wrote:


"Joel Sherrill <joel@OARcorp.com>" <joel.sherrill@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@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985