RFC: Remove BSP_Configuration
Joel Sherrill <joel@OARcorp.com>
joel.sherrill at OARcorp.com
Thu Oct 20 16:52:53 UTC 2005
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.
Yes I will end up mechanically having to edit every BSP which references
BSP_Configuration to use the new name.
More information about the users