Problems in boot_card() with configuration
Gedare Bloom
gedare at rtems.org
Fri Feb 15 20:18:46 UTC 2013
Thank you for the post-mortem on your problem. If you think there is
some way to improve the documentation feel free to suggest it.
Experienced users tend not to notice oversights in documentation. And
if you're really ambitious, submitting a documentation patch for the
improvement would be even more helpful. :)
-Gedare
On Fri, Feb 15, 2013 at 2:54 PM, Matthew J Fletcher <amimjf at gmail.com> wrote:
> Hi,
>
> I've been reading the online documentation (one of the best bits of
> RTEMS, imho), and reading code as well and have a better understanding
> of my problems.
>
> I might be using RTEMS in a slightly odd way, i configured for the
> rtl22xx BSP as thats pretty close to my board, but i did not build the
> samples, i then linked librtemscpu.a and librtemsbsp.a against my codebase.
>
> What i failed to fully grasp that you need create an instance of various
> global structures like;
>
> Configuration
> Configuration_RTEMS_API
>
> This is needs to be done via a set of defines like follows,..
>
> Although i guess you could poke at the global structures in the
> 'Configuration' blocks before boot_code().
>
> ---------- snip ------------
> #include <bsp.h>
>
> #define CONFIGURE_IDLE_TASK_BODY rtems_idle
>
> /* NOTICE: the clock driver is explicitly disabled */
> #define CONFIGURE_APPLICATION_DOES_NOT_NEED_CLOCK_DRIVER
> #define CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER
> #define CONFIGURE_APPLICATION_NEEDS_LIBBLOCK
>
> #define CONFIGURE_DISABLE_CLASSIC_API_NOTEPADS
>
> /*
> * define OS memory consumption here, RTEMS is pretty lean, but dont go
> bonkers
> */
> #define CONFIGURE_MAXIMUM_TASKS 20
> #define CONFIGURE_MAXIMUM_TIMERS 20
> #define CONFIGURE_MAXIMUM_SEMAPHORES 20
> #define CONFIGURE_MAXIMUM_MESSAGE_QUEUES 20
> #define CONFIGURE_MAXIMUM_PARTITIONS 5
> #define CONFIGURE_MAXIMUM_REGIONS 5
> #define CONFIGURE_MAXIMUM_PORTS 0
> #define CONFIGURE_MAXIMUM_PERIODS 0
> #define CONFIGURE_MAXIMUM_USER_EXTENSIONS 0
>
> #define CONFIGURE_USE_DEVFS_AS_BASE_FILESYSTEM
> #define CONFIGURE_RTEMS_INIT_TASKS_TABLE
>
> #define CONFIGURE_INIT
> #include <rtems/confdefs.h>
>
> --------- snip --------------
>
>
> Its also crucialy important to only have one "#define CONFIGURE_INIT
> #include <rtems/confdefs.h>" and have it in your application and not in
> some sample or test linked against in error.
>
> - Matthew
>
>
>
> On 15/02/13 14:24, Joel Sherrill wrote:
>> 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
>> <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
>> <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
>> <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
More information about the users
mailing list