Problems in boot_card() with configuration

Fri Feb 15 14:20:14 UTC 2013

Joel,

I simply had not put
#define CONFIGURE_INIT
#include <rtems/confdefs.h>

Anywhere in the code,  bit of a schoolboy error so the Configuration
structure was not setup. I was creating my own bsp and just forgot that I
needed bits from on of the samples as well.
On 15 Feb 2013 14:10, "Joel Sherrill" <Joel.Sherrill at oarcorp.com> wrote:

>  Could you post or privately email the broken code? I am curious if we can do anything to help avoid this or at least make it easier to debug or know what tolook for in the future.
>
> Thanks
>
> Matthew J Fletcher <amimjf at gmail.com> wrote:
>
>
>  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/b4f81e8f/attachment-0001.html>