Problems in boot_card() with configuration
Matthew J Fletcher
amimjf at gmail.com
Fri Feb 15 19:54:41 UTC 2013
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
>
More information about the users
mailing list