rtems_cache_coherent_allocate() crash on CPU unaligned memory access

[Mike Looijmans]

The system has a LEON2 CPU that has 512MB RAM attached.

I want to use 128MB of that memory as cache coherent memory, so I've mapped it 
to a non-cacheable region of the LEON2 address space, at 0xB0000000. The lower 
256 is mapped to 0x40000000.

In the bsp_start() routine, just like e.g. the Zynq BSP, I call (simplified code):

   rtems_cache_coherent_add_area(0xB0000000, 0x08000000);

The driver calls, at some point (I also tried passing "8" or "PAGE_SIZE" as 
alignment parameter instead of "0"):

   rtems_cache_coherent_allocate(256*1024, 0, 0);


The result is always (as reported by grmon):

   IU in error mode (tt = 0x07, mem address not aligned)
   0x4016c008: c600a004  ld  [%g2 + 0x4], %g3  <_Heap_Block_allocate+20>

Note: If I don't call rtems_cache_coherent_add_area() in the BSP startup, 
there's no crash, but rtems_cache_coherent_allocate will actually use the 
normal heap instead of the coherent one.

Why I'm doing this: The hardware writes to the (shared) DDR controller 
directly, and the LEON2 snoop unit cannot "see" that. Hence I want the LEON2 
to read/write the memory that the hardware accesses without using the data 
cache, otherwise it won't be coherent. I've verified with grmon that this 
memory map really does work correctly.


Some extra debugging info:

grmon2> dis _Heap_Block_allocate
        0x4016bff4: 9de3bfa0  save  %sp, -96, %sp        <_Heap_Block_allocate+0>
        0x4016bff8: c2066004  ld  [%i1 + 0x4], %g1       <_Heap_Block_allocate+4>
        0x4016bffc: ba06bff8  add  %i2, -8, %i5          <_Heap_Block_allocate+8>
        0x4016c000: 82087ffe  and  %g1, 0xFFFFFFFE, %g1  <_Heap_Block_allocate+12>
        0x4016c004: 84064001  add  %i1, %g1, %g2         <_Heap_Block_allocate+16>
    0=> 0x4016c008: c600a004  ld  [%g2 + 0x4], %g3       <_Heap_Block_allocate+20>
        0x4016c00c: b8100018  mov  %i0, %i4              <_Heap_Block_allocate+24>
        0x4016c010: 8088e001  andcc  %g3, 0x1, %g0       <_Heap_Block_allocate+28>
        0x4016c014: 1280000f  bne  0x4016C050            <_Heap_Block_allocate+32>
        0x4016c018: 96274019  sub  %i5, %i1, %o3         <_Heap_Block_allocate+36>
        0x4016c01c: f806600c  ld  [%i1 + 0xC], %i4       <_Heap_Block_allocate+40>
        0x4016c020: da066008  ld  [%i1 + 0x8], %o5       <_Heap_Block_allocate+44>
        0x4016c024: de062044  ld  [%i0 + 0x44], %o7      <_Heap_Block_allocate+48>
        0x4016c028: c806204c  ld  [%i0 + 0x4C], %g4      <_Heap_Block_allocate+52>
        0x4016c02c: da272008  st  %o5, [%i4 + 0x8]       <_Heap_Block_allocate+56>


grmon2> bt

        %pc          %sp
   #0   0x4016c008   0x4efffc10   <_Heap_Block_allocate+0x14>
   #1   0x4016b7ac   0x4efffc70   <_Heap_Allocate_aligned_with_boundary+0x1e4>
   #2   0x40163f44   0x4efffcd8   <rtems_cache_coherent_allocate+0x28>
   #3   0x4011873c   0x4efffd38   <mydriver_core_probe+0x778>
   #4   0x40116228   0x4efffdb0   <mydriver_initialize+0x7c>
   #5   0x40171db0   0x4efffe10   <rtems_io_initialize+0x4c>
   #6   0x4016aaec   0x4efffe70   <_IO_Initialize_all_drivers+0x2c>
   #7   0x4016aa24   0x4efffed0   <rtems_initialize_device_drivers+0x4>
   #8   0x40161384   0x4effff30   <boot_card+0x44>


Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijmans at topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail