Problems in boot_card() with configuration

Fri Feb 15 14:24:00 UTC 2013

Hmmm.. So you ended up with the default configuration info.. Just there to ensure things link..

Folks.. Any ideas?

Matthew J Fletcher <amimjf at gmail.com> wrote:

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<mailto: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<mailto: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<mailto: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<mailto: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<mailto:rtems-users at rtems.org>
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<mailto:rtems-users at rtems.org>
http://www.rtems.org/mailman/listinfo/rtems-users
_______________________________________________
rtems-users mailing list
rtems-users at rtems.org<mailto:rtems-users at rtems.org>
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/f9f97ef5/attachment-0001.html>