ARM - after update from rtems4.9.3 to rtems-4.9.5 Unlimited Task Test fails

[Joachim Rahn]

Hi Joel,

thanks for the fast answer

On 01.03.2011 17:09, Joel Sherrill wrote:
> On 03/01/2011 07:48 AM, Joachim Rahn wrote:
>> Hi all,
>>
>> after updating from rtems-4.9.3 to rtems-4.9.5 the "Unlimited Task Test" on my
>> ARM cpu at91sam9263 fails with a message like...
>>
>> [...skip...]
>> task 19 ending.
>> task 20 ending.
>> task 21 ending.
>> task 7 ending.
>> task 8 ending.
>>
>> INSN_LDR
>> data_abort at address 0x20018CD8, instruction: 0xE5932000,   spsr = 0x20000013
>> active thread thread 0x0A010001
>> Previous sp=0x200629A8 lr=0x200135E0 and actual cpsr=60000097
>>   0x20038E30 0x20056EA8 0x0000117C 0x200629E0 0x200629C4 0x200135E0
>>   0x20018CB8 0x20038E30 0x20056EA8 0x20026EC0 0x20026EC0 0x20062A18
>>   0x200629E4 0x20010100 0x200135AC 0x00000000 0x00000000 0x00000000
>>   0x00000000 0x20056EA8 0x20038E30 0x60000013 0x600000D3 0x00000000
>>   0x00000000 0x20062A28 0x20062A1C 0x2000AE48 0x2000FFF8 0x20062A4C
>>   0x20062A2C 0x2000ADA0 0x2000AE24 0x521C9845 0x20056EA8 0x00000000
>>   0x00000000 0x2002ACD8 0x20062A64 0x20062A50 0x20000348 0x2000AD28
>>   0x00000008 0x00000001 0x20062A84 0x20062A68 0x2001C2D4 0x20000310
>>
>> [...skip...]
>>
>> which commonly means the cpu tries to access non available memory.
>>
>> After removing the bugfix bug1718 the "Unlimited Task Test" works fine.
>>
>> (https://www.rtems.org/bugzilla/show_bug.cgi?id=1718)
>>
>> *** rtems-4.9.3: ./cpukit/sapi/include/confdefs.h *** unlimited task test works
>> [...skip...]
>>
>>    #define CONFIGURE_MEMORY_PER_TASK_FOR_POSIX_API \
>>      _Configure_From_workspace( \
>>        sizeof (POSIX_API_Control) + \
>>       (sizeof (void *) * (CONFIGURE_MAXIMUM_POSIX_KEYS)) \
>>      )
>>
>> [...skip...]
>>
>> *** rtems-4.9.5: ./cpukit/sapi/include/confdefs.h *** unlimited task test doesn't work
>> [...skip...]
>>    #define CONFIGURE_MEMORY_PER_TASK_FOR_POSIX_API \
>>      _Configure_From_workspace( \
>>        CONFIGURE_MINIMUM_TASK_STACK_SIZE + \
>>        sizeof (POSIX_API_Control) + \
>>       (sizeof (void *) * (CONFIGURE_MAXIMUM_POSIX_KEYS)) \
>>      )
>> [...skip...]
>>
>> Any hints respectively does anyone observe the same?
>>
> That patch wouldn't directly cause that failure.
> The only think I can see is that does change the
> amount of workspace reserved up front (by a lot).
>
> Is this a BSP which is in the RTEMS tree?

No, it's our own board based on the ATMEL at91sam9263 cpu.
Our board is very similar to the ATMEL evaluation
board AT91SAM9263-EK but with more RAM.
As starting point we used the BSP CSB337 which has a comparable
linkcmds and bspstart.c.

> I am
> suspicious that there isn't enough memory for
> the workspace/heap and the BSP initialization
> isn't recognizing this.  Eventually the task stacks,
> heap, etc all collide, there is corruption and you crash.
>

hmm, we have 128M or 0x08000000 bytes of RAM

here are the adresses of the RAM

-I- _sdram_base              = 0x20000000 - 536870912
-I- _sdram_size              = 0x8000000 - 134217728

> So we would need to know the following:
>
> + address of end of BSS
> + start of memory for heap and length
> + start of memory for RTEMS workspace and length.
> + amount of RAM
>

here my debug output in bsp_start,

-I- _bss_start_              = 0x20029BE0 - 537041888
-I- _bss_end_                = 0x2002FB00 - 537066240

between _bss_end_ end work_space_start we defined a gap in memory
holding the mmu_table and some other stuff

-I- work_space_start         = 0x20038000 - 537100288
-I- work_space_size          = 0x5A9A8 - 371112
-I- heap_start               = 0x200929A8 - 537471400
-I- heap_size                = 0x7F6D658 - 133617240

BTW: As far as I understand start of the workspace has to be defined in
     the BSP. The debug-output of workspace_size was get by a call to
     rtems_configuration_get_work_space_size() wich in fact is defined
     by RTEMS like:
     #define rtems_configuration_get_work_space_size() \
             (Configuration.work_space_size)

     What I can't see at the moment is who initializes the value of Configuration.work_space_size
     and when will the value of Configuration.work_space_size be initialized ???

> Assuming that the workspace/heap are from end of
> BSS to the end of RAM.

as mentioned before between end of BSS and start of heap we defined a gap in linkcmds...

Cheers,
--
Joachim

________________________________

Helmholtz-Zentrum Berlin für Materialien und Energie GmbH

Mitglied der Hermann von Helmholtz-Gemeinschaft Deutscher Forschungszentren e.V

Aufsichtsrat: Vorsitzender Prof. Dr. Dr. h.c. mult. Joachim Treusch, stv. Vorsitzende Dr. Beatrix Vierkorn- Rudolph
Geschäftsführer: Prof. Dr. Anke Rita Kaysser-Pyzalla, Prof. Dr. Dr. h.c. Wolfgang Eberhardt, Dr. Ulrich Breuer

Sitz Berlin, AG Charlottenburg, 89 HRB 5583

Postadresse:
Hahn-Meitner-Platz 1
D-14109 Berlin

http://www.helmholtz-berlin.de