Crash in _User_extensions_Thread_create

[Matthew J Fletcher]

Hi,

Looking at BSP for a CPU from my youth 68340 i can see in the linker script.

        .data : {
                PROVIDE (_copy_start = .);
                *(.data*)
		*(.gnu.linkonce.d*)
		*(.gcc_except_table*)
		*(.jcr)
                . = ALIGN (16);
                PROVIDE (_edata = .);
                PROVIDE (_copy_end = .);
        } >ram

Nice start and end symbols, and in the startp.s

SYM(_CopyDataClearBSSAndStart):
	lea	SYM(_copy_start),a0	| Get start of DATA in RAM
	lea	SYM(_etext),a2		| Get start of DATA in ROM
	cmpl	a0,a2			| Are they the same?
	beq.s	NOCOPY			| Yes, no copy necessary
	lea	SYM(_copy_end),a1	| Get end of DATA in RAM
	bra.s	COPYLOOPTEST		| Branch into copy loop

Problem solved !, maybe i should think more before asking daft questions.

- Matthew



On 20/02/13 20:39, Matthew J Fletcher wrote:
> Hi,
> 
> Ok so looking at the rtl22xx BSP as an example i can see the linker
> creates a .data section like so,
> 
>   .data :
>   {
>     *(.data)
>     *(.data.*)
>     *(.gnu.linkonce.d*)
>     *(.jcr)
>     SORT(CONSTRUCTORS)
>     _edata = .;
>   } > sdram
> 
> but in start.s there is no reference to the data section or the _edata
> symbol, so i've got no idea how that could setup the data section with
> the initialised variables in it.
> 
> Thinking for a minute, would the linker script not need a symbol for
> both the beginning and the end of the data section so start.s knows the
> range to copy ? and then a loop in start.s to copy the data.
> 
> I wonder if these BSP's are only suitable for execute from flash systems
> where you dont need to do the store -> ram copy of initialised data.
> 
> Thats ultimately how i will run but i am running from RAM at the moment
> to ease (i thought !) being up and debugging.
> 
> 
> 
> On 20/02/13 17:25, Joel wrote:
>> On 2/20/2013 10:37 AM, Matthew J Fletcher wrote:
>>> Hi
>>>
>>> I dont define CONFIGURE_INITAL_EXTENSIONS so i was surprised to even
>>> be in this code. A #error in confdefs.h shows that its the
>>> RTEMS_NEWLIB define thats causing that path to be taken.
>>>
>>> The faulting line is the function pointer call into
>>> Callouts.thread_create as Callouts in uninitialised.
>>>
>>> I guess i am missing some #define that will setup this for me, i've
>>> looked in the samples folder and they just seem to #define the drivers
>>> they need, then #define the number of resources, then #define
>>> CONFIGURE_RTEMS_INIT_TASKS_TABLE, then #define CONFIG_INIT and include
>>> confdefs.h so i am a bit confused about the problem i am seeing.
>>>
>>>
>> There is very likely nothing wrong with your configuration via confdefs.h.
>>
>> Assuming you are completely up to date... there is almost certainly
>> something
>> wrong with your layout or handling of initialized data.
>>
>> Check Configuration_Initial_Extensions. It is initialized data and if it
>> doesn't have
>> pointers to the newlib extensions at download or by the time you get to
>> boot_card(),
>> then something is broken.  If it is correct and is overwritten by the
>> time you get to
>> using it, then something is overwriting it.
>>
>> Memory layout and program initialization issues are a big part of
>> mysterious
>> failures at this point in a BSP.
>>
>>>
>>> -- 
>>>
>>> regards
>>> ---
>>> Matthew J Fletcher
>>>
>>