Crash in _User_extensions_Thread_create

[Matthew J Fletcher]

Sebastian,

Ok, i've got the latest GIT sources, but i still dont see how the rtl22xx
BSP works (and it does not work for me).

start.s does not do any data section copy, it just does a zero'ing of the
bss and then calls boot_card(), how can that work with initialised data ?

the start.s thats in the arm/shared folder calls the bsp_start_hook_1 which
does the bsp_start_copy_sections() which uses the hand rolled memcpy
function to copy data as well as other sections.

Is the rtl22xx just a broken BSP that i should not be using ?

- Matthew


On 21 February 2013 08:55, Sebastian Huber <
sebastian.huber at embedded-brains.de> wrote:

> 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<sebastian.huber at embedded-brains.de>
> PGP     : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
> ______________________________**_________________
> rtems-users mailing list
> rtems-users at rtems.org
> http://www.rtems.org/mailman/**listinfo/rtems-users<http://www.rtems.org/mailman/listinfo/rtems-users>
>



-- 

regards
---
Matthew J Fletcher
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20130221/cdcd86ec/attachment.html>