Problems in boot_card() with configuration

Matthew J Fletcher amimjf at gmail.com
Fri Feb 15 11:53:35 UTC 2013


Thanks all, but my problem was much simpler, not including confdefs.h I
copied one of the included samples and am getting much further.
 On 14 Feb 2013 20:14, "Joel Sherrill" <joel.sherrill at oarcorp.com> wrote:

> On 2/14/2013 2:00 PM, Matthew J Fletcher wrote:
>
>> On 14/02/13 19:38, Gedare Bloom wrote:
>>
>>> On Thu, Feb 14, 2013 at 2:16 PM, Joel Sherrill
>>> <joel.sherrill at oarcorp.com> wrote:
>>>
>>>> On 2/14/2013 1:09 PM, Matthew J Fletcher wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I am using RTEMS 4.10.2, and a custom BSP based on the ARM rtl22xx.
>>>>>
>>>>> I am running through the asm startup ok and calling into boot_card(),
>>>>> stepping through its all working fine, work_area_start, work_area_size,
>>>>> heap_start and heap_size are setup as i expect from my linkscript.
>>>>>
>>>>> But the test of "work_area_size <= Configuration.work_space_size" fails
>>>>> because Configuration.work_space_size looks like 0xfffffff, the only
>>>>> place that assigns to Configuration.work_space_size is a few lines
>>>>> further down.
>>>>>
>>>>> Does this code presume that the BSP has set the Configuration structure
>>>>> to zero, or the whole memory ? even so the aforementioned test seems
>>>>> odd
>>>>> as its just testing memory has been initialised.
>>>>>
>>>>>  We do assume the .bss section is initialized to 0, although I'm not
>>> sure if that is still a necessary assumption. But I don't think that
>>> is the problem here, because if the value of
>>> Configuration.work_space_size was 0 then this test would still fail.
>>>
>>> The work_space_size calculation is done in the
>>> cpukit/sapi/include/confdefs.h file, but that can be a bit messy to
>>> try to figure out.
>>>
>>>  Or am i missing some RTEMS initialisation call that needs to be done
>>>>> before boot_card() ?
>>>>>
>>>> No but there may be some basic C language assumptions not
>>>> being met. Configuration is in the .data section and that value
>>>> does not look like it was initialized to.
>>>>
>>>> Is your download correct?
>>>>
>>>>  You can disassemble your binary image and inspect the value of the
>>> Configuration.work_space_size field in the data section.
>>>
>> Sorry i dont seem to have the objdump skills, i did a -D (disassemble
>> all sections), although it produced massive output i dont see a
>> structure called 'Configuration', i get a block like
>>
>> 814085f4 <Configuration>:
>> 814085f4:       00000000        andeq   r0, r0, r0
>> 814085f8:       00010830        andeq   r0, r1, r0, lsr r8
>>
> This isn't code but this is enough to see that what is in memory and used
> by the code is NOT what was in the object. The workspace_address field
> is 0. The second field is the size and is 0x00010830. You saw 0xFFFFFFFFF.
>
> Either the download didn't go where you thought, memory access isn't
> setup write, etc.
>
> Download and look at those two addresses BEFORE you run at all.
> If you don't see those values, it is nothing to do with RTEMS. :)
>
> .bss is uninitialized global and static date. It gets zeroed.
> .data is your global and static data that is initialized.
>
>> 814085fc:       00000000        andeq   r0, r0, r0
>> 81408600:       00002710        andeq   r2, r0, r0, lsl r7
>> 81408604:       00000032        andeq   r0, r0, r2, lsr r0
>> 81408608:       8118d3a0        tsthi   r8, r0, lsr #7
>> 8140860c:       00001000        andeq   r1, r0, r0
>> 81408610:       00001000        andeq   r1, r0, r0
>>         ...
>> 81408620:       00000002        andeq   r0, r0, r2
>> 81408624:       00000002        andeq   r0, r0, r2
>> 81408628:       8140868c        smlalbbhi       r8, r0, ip, r6
>> 8140862c:       00000001        andeq   r0, r0, r1
>> 81408630:       8140866c        cmphi   r0, ip, ror #12
>>
>> is it possible to pretty print that in some way ?
>>
>>
>>  - Matthew
>>>>> ______________________________**_________________
>>>>> 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>
>>>>>
>>>>
>>>>
>>>> --
>>>> 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
>>>>
>>>>
>>>> ______________________________**_________________
>>>> 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>
>>>>
>>> ______________________________**_________________
>> 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>
>>
>
>
> --
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20130215/38538d10/attachment-0001.html>


More information about the users mailing list