Crash in _User_extensions_Thread_create

[Joel Sherrill]

On 2/20/2013 2:39 PM, 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.
>
I don't know this BSP that well. If the .data section has the proper 
values in it
when you get to boot_card(), then it is OK.

In some systems, the RAM would be loaded from Flash by start.S or something
similarly early.

In all cases, if you get to rtems_initialize_executive_early() (or even the
bsp_get_work_area() methods) and .data isn't right, you are in trouble.

Sebastian Huber should comment.

--joel
>
> 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
>>>


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985