[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, email@example.com wrote:
"Joel Sherrill <joel@OARcorp.com>" <joel.sherrill@OARcorp.com> writes:
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.
+ 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_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
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
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;
BSP_POSIX_Configuration = *Configuration.POSIX_api_configuration;
BSP_Configuration.POSIX_api_configuration = &BSP_POSIX_Configuration;
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.
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