<p dir="ltr">Gedare,</p>
<p dir="ltr">Its just a ARM7 variant, different to rtl22xx but not that exciting. Only difference really is that its all in thumb mode.<br>
</p>
<div class="gmail_quote">On 15 Feb 2013 14:22, "Gedare Bloom" <<a href="mailto:gedare@rtems.org">gedare@rtems.org</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I usually would start with the hello world and ticker samples for new<br>
BSP development. That limits the uncertainty I have.<br>
<br>
Are you planning to release your BSP / submit it to be included with RTEMS?<br>
<br>
On Fri, Feb 15, 2013 at 9:20 AM, Matthew J Fletcher <<a href="mailto:amimjf@gmail.com">amimjf@gmail.com</a>> wrote:<br>
> Joel,<br>
><br>
> I simply had not put<br>
> #define CONFIGURE_INIT<br>
> #include <rtems/confdefs.h><br>
><br>
> Anywhere in the code,  bit of a schoolboy error so the Configuration<br>
> structure was not setup. I was creating my own bsp and just forgot that I<br>
> needed bits from on of the samples as well.<br>
><br>
> On 15 Feb 2013 14:10, "Joel Sherrill" <<a href="mailto:Joel.Sherrill@oarcorp.com">Joel.Sherrill@oarcorp.com</a>> wrote:<br>
>><br>
>> Could you post or privately email the broken code? I am curious if we can<br>
>> do anything to help avoid this or at least make it easier to debug or know<br>
>> what tolook for in the future.<br>
>><br>
>> Thanks<br>
>><br>
>> Matthew J Fletcher <<a href="mailto:amimjf@gmail.com">amimjf@gmail.com</a>> wrote:<br>
>><br>
>> Thanks all, but my problem was much simpler, not including confdefs.h I<br>
>> copied one of the included samples and am getting much further.<br>
>><br>
>> On 14 Feb 2013 20:14, "Joel Sherrill" <<a href="mailto:joel.sherrill@oarcorp.com">joel.sherrill@oarcorp.com</a>> wrote:<br>
>>><br>
>>> On 2/14/2013 2:00 PM, Matthew J Fletcher wrote:<br>
>>>><br>
>>>> On 14/02/13 19:38, Gedare Bloom wrote:<br>
>>>>><br>
>>>>> On Thu, Feb 14, 2013 at 2:16 PM, Joel Sherrill<br>
>>>>> <<a href="mailto:joel.sherrill@oarcorp.com">joel.sherrill@oarcorp.com</a>> wrote:<br>
>>>>>><br>
>>>>>> On 2/14/2013 1:09 PM, Matthew J Fletcher wrote:<br>
>>>>>>><br>
>>>>>>> Hi,<br>
>>>>>>><br>
>>>>>>> I am using RTEMS 4.10.2, and a custom BSP based on the ARM rtl22xx.<br>
>>>>>>><br>
>>>>>>> I am running through the asm startup ok and calling into boot_card(),<br>
>>>>>>> stepping through its all working fine, work_area_start,<br>
>>>>>>> work_area_size,<br>
>>>>>>> heap_start and heap_size are setup as i expect from my linkscript.<br>
>>>>>>><br>
>>>>>>> But the test of "work_area_size <= Configuration.work_space_size"<br>
>>>>>>> fails<br>
>>>>>>> because Configuration.work_space_size looks like 0xfffffff, the only<br>
>>>>>>> place that assigns to Configuration.work_space_size is a few lines<br>
>>>>>>> further down.<br>
>>>>>>><br>
>>>>>>> Does this code presume that the BSP has set the Configuration<br>
>>>>>>> structure<br>
>>>>>>> to zero, or the whole memory ? even so the aforementioned test seems<br>
>>>>>>> odd<br>
>>>>>>> as its just testing memory has been initialised.<br>
>>>>>>><br>
>>>>> We do assume the .bss section is initialized to 0, although I'm not<br>
>>>>> sure if that is still a necessary assumption. But I don't think that<br>
>>>>> is the problem here, because if the value of<br>
>>>>> Configuration.work_space_size was 0 then this test would still fail.<br>
>>>>><br>
>>>>> The work_space_size calculation is done in the<br>
>>>>> cpukit/sapi/include/confdefs.h file, but that can be a bit messy to<br>
>>>>> try to figure out.<br>
>>>>><br>
>>>>>>> Or am i missing some RTEMS initialisation call that needs to be done<br>
>>>>>>> before boot_card() ?<br>
>>>>>><br>
>>>>>> No but there may be some basic C language assumptions not<br>
>>>>>> being met. Configuration is in the .data section and that value<br>
>>>>>> does not look like it was initialized to.<br>
>>>>>><br>
>>>>>> Is your download correct?<br>
>>>>>><br>
>>>>> You can disassemble your binary image and inspect the value of the<br>
>>>>> Configuration.work_space_size field in the data section.<br>
>>>><br>
>>>> Sorry i dont seem to have the objdump skills, i did a -D (disassemble<br>
>>>> all sections), although it produced massive output i dont see a<br>
>>>> structure called 'Configuration', i get a block like<br>
>>>><br>
>>>> 814085f4 <Configuration>:<br>
>>>> 814085f4:       00000000        andeq   r0, r0, r0<br>
>>>> 814085f8:       00010830        andeq   r0, r1, r0, lsr r8<br>
>>><br>
>>> This isn't code but this is enough to see that what is in memory and used<br>
>>> by the code is NOT what was in the object. The workspace_address field<br>
>>> is 0. The second field is the size and is 0x00010830. You saw<br>
>>> 0xFFFFFFFFF.<br>
>>><br>
>>> Either the download didn't go where you thought, memory access isn't<br>
>>> setup write, etc.<br>
>>><br>
>>> Download and look at those two addresses BEFORE you run at all.<br>
>>> If you don't see those values, it is nothing to do with RTEMS. :)<br>
>>><br>
>>> .bss is uninitialized global and static date. It gets zeroed.<br>
>>> .data is your global and static data that is initialized.<br>
>>>><br>
>>>> 814085fc:       00000000        andeq   r0, r0, r0<br>
>>>> 81408600:       00002710        andeq   r2, r0, r0, lsl r7<br>
>>>> 81408604:       00000032        andeq   r0, r0, r2, lsr r0<br>
>>>> 81408608:       8118d3a0        tsthi   r8, r0, lsr #7<br>
>>>> 8140860c:       00001000        andeq   r1, r0, r0<br>
>>>> 81408610:       00001000        andeq   r1, r0, r0<br>
>>>>         ...<br>
>>>> 81408620:       00000002        andeq   r0, r0, r2<br>
>>>> 81408624:       00000002        andeq   r0, r0, r2<br>
>>>> 81408628:       8140868c        smlalbbhi       r8, r0, ip, r6<br>
>>>> 8140862c:       00000001        andeq   r0, r0, r1<br>
>>>> 81408630:       8140866c        cmphi   r0, ip, ror #12<br>
>>>><br>
>>>> is it possible to pretty print that in some way ?<br>
>>>><br>
>>>><br>
>>>>>>> - Matthew<br>
>>>>>>> _______________________________________________<br>
>>>>>>> rtems-users mailing list<br>
>>>>>>> <a href="mailto:rtems-users@rtems.org">rtems-users@rtems.org</a><br>
>>>>>>> <a href="http://www.rtems.org/mailman/listinfo/rtems-users" target="_blank">http://www.rtems.org/mailman/listinfo/rtems-users</a><br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>> --<br>
>>>>>> Joel Sherrill, Ph.D.             Director of Research & Development<br>
>>>>>> joel.sherrill@OARcorp.com        On-Line Applications Research<br>
>>>>>> Ask me about RTEMS: a free RTOS  Huntsville AL 35805<br>
>>>>>> Support Available                (256) 722-9985<br>
>>>>>><br>
>>>>>><br>
>>>>>> _______________________________________________<br>
>>>>>> rtems-users mailing list<br>
>>>>>> <a href="mailto:rtems-users@rtems.org">rtems-users@rtems.org</a><br>
>>>>>> <a href="http://www.rtems.org/mailman/listinfo/rtems-users" target="_blank">http://www.rtems.org/mailman/listinfo/rtems-users</a><br>
>>>><br>
>>>> _______________________________________________<br>
>>>> rtems-users mailing list<br>
>>>> <a href="mailto:rtems-users@rtems.org">rtems-users@rtems.org</a><br>
>>>> <a href="http://www.rtems.org/mailman/listinfo/rtems-users" target="_blank">http://www.rtems.org/mailman/listinfo/rtems-users</a><br>
>>><br>
>>><br>
>>><br>
>>> --<br>
>>> Joel Sherrill, Ph.D.             Director of Research & Development<br>
>>> joel.sherrill@OARcorp.com        On-Line Applications Research<br>
>>> Ask me about RTEMS: a free RTOS  Huntsville AL 35805<br>
>>> Support Available                (256) 722-9985<br>
>>><br>
><br>
</blockquote></div>