Crash in _User_extensions_Thread_create
Matthew J Fletcher
amimjf at gmail.com
Thu Feb 21 13:45:58 UTC 2013
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 ?
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the users