RFC: Remove BSP_Configuration
Joel Sherrill <joel@OARcorp.com>
joel.sherrill at OARcorp.com
Fri Oct 21 13:38:03 UTC 2005
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
>>>>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
+ (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.
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
More information about the users