Crash in _User_extensions_Thread_create

[Sebastian Huber]

On 02/20/2013 09:55 PM, Joel Sherrill wrote:
> 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.

For ARM I would use the current RTEMS master branch and not RTEMS 4.10.  The 
ARM BSPs use now a shared linker command file and a BSP specific memory map 
definition.

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.