Crash in _User_extensions_Thread_create
Matthew J Fletcher
amimjf at gmail.com
Thu Feb 21 14:16:42 UTC 2013
Following up to myself,.. i added the following bit of Thumb asm before
boot_card() in start.s
ldr r1, =_etext // -> ROM data start
ldr r2, =_data // -> data start
ldr r3, =_edata // -> end of data
loop_a: ldr r0,[r1]
cmp, r2,r3 // check if data to move
along with the _data and _edata symbols to mark the start and end of the
Not the most pretty Thumb asm i guess but it makes the rtl22xx BSP now have
initialised variables with the correct value.
On 21 February 2013 13:45, Matthew J Fletcher <amimjf at gmail.com> wrote:
> 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:
>>>> Ok so looking at the rtl22xx BSP as an example i can see the linker
>>>> creates a .data section like so,
>>>> .data :
>>>> _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
>>> 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
> Matthew J Fletcher
Matthew J Fletcher
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the users