Running RTEMS on a LEON2 from ROM

[Mike Looijmans]

On 26-07-17 13:10, Mike Looijmans wrote:
> On 26-07-17 10:21, Jiri Gaisler wrote:
>>
>>
>> On 07/26/2017 07:25 AM, Mike Looijmans wrote:
>>>
>>>> how you do it with standalone sis:
>>>>
>>>> $ sparc-rtems4.12-sis -leon2 application.exe
>>>>
>>>>> hi 100
>>>>> go
>>>>> hi
>>>>> reg
>>>
>>> Doesn't get very far, there's apparently no (working) memory at
>>> 0x40000000 in the simulator, it always reads back as "0", so any
>>> access to RAM results in a crash in the simulator.
>>>
>>>
>>>
>>
>> Are  you sure you are building sis and gdb from RSB head? sis in the
>> regular gdb does not support leon2 yet.
>> To advance things, you can send me your application binary and I can run
>> it in the simulator and send you the traces. If you are on 64-bit ubuntu
>> 16.04, I can also provide you with binaries for sis/gdb, or the whole RSB.
> 
> I built the current HEAD of the RSB, and ran using the simulator from that. 
> The result is the same.
> 
> Did some more digging. The problem appears to be that the simulator populates 
> the memory segments using the VMA values instead of the LMA values. So it 
> writes the data segment to RAM at 0x40000000, instead of in ROM, directly 
> following the text segment, as the boot code expects. I can see the data 
> segment contents there just after loading the elf.
> 
> When the code starts, it copies the data segment from ROM into RAM and that 
> will copy the empty ROM part onto the RAM, resulting in the all-zero data in 
> RAM that I see.
> 
> Can I load a binary image into sis? (so not an elf but a raw ROM image)
> 
> I'll try using objdump to concat the text and data into a single segment elf 
> for the simulator. Or maybe patch the VMA address to match the LMA.

That worked. According to SIS, the crash happens here:

https://git.rtems.org/rtems/tree/cpukit/score/src/heap.c?h=4.11#n274

 From sis, i can see:

     18156  0000da3c  81c3e008  retl
     18158  0000da40  01000000  nop
     18159  00006eec  c41fbff8  ldd  [ %fp + -8 ], %g2
     18162  00006ef0  b406401a  add  %i1, %i2, %i2
     18163  00006ef4  f020a008  st  %i0, [ %g2 + 8 ]
     18166  00006ef8  f020a00c  st  %i0, [ %g2 + 0xc ]
     18169  00006efc  f4208000  st  %i2, [ %g2 ]
     18172  00006f00  8220c002  sub  %g3, %g2, %g1
     18173  00006f04  88106001  or  %g1, 1, %g4
     18174  00006f08  c820a004  st  %g4, [ %g2 + 4 ]
     18177  00006f0c  c43e2020  std  %g2, [ %i0 + 0x20 ]
     18181  00006f10  c4262008  st  %g2, [ %i0 + 8 ]
     18184  00006f14  c426200c  st  %g2, [ %i0 + 0xc ]
     18187  00006f18  f6262010  st  %i3, [ %i0 + 0x10 ]
     18190  00006f1c  fa262014  st  %i5, [ %i0 + 0x14 ]
     18193  00006f20  f2262018  st  %i1, [ %i0 + 0x18 ]
     18196  00006f24  f426201c  st  %i2, [ %i0 + 0x1c ]
     18199  00006f28  c220c000  st  %g1, [ %g3 ]
     18203  40000090  91d020ff  ta  0xff
sis> reg

	  INS       LOCALS      OUTS     GLOBALS
    0:  40002500   91CFE0F0   51CF6D70   00000000
    1:  00000000   00006F28   00000008   51CF6D70
    2:  00000068   00006F2C   0A39EDAF   40007380
    3:  00000010   00000000   00000007   91CFE0F0
    4:  400FFE70   00000000   FFFFFFFF   51CF6D71
    5:  40002568   00000000   00000008   00000000
    6:  400FFE10   00000000   400FFDB0   00000000
    7:  00006EE4   00000000   00006DD0   00000000

  psr: 00400FC3   wim: 00000002   tbr: 40000090   y: 00000000


Looked this address up in the "objdump -S" output, and that shows the 
following source code and assembly there:

   /* Heap control */
   heap->page_size = page_size;
     6f18:	f6 26 20 10 	st  %i3, [ %i0 + 0x10 ]
   heap->min_block_size = min_block_size;
     6f1c:	fa 26 20 14 	st  %i5, [ %i0 + 0x14 ]
   heap->area_begin = heap_area_begin;
     6f20:	f2 26 20 18 	st  %i1, [ %i0 + 0x18 ]
   heap->area_end = heap_area_end;
     6f24:	f4 26 20 1c 	st  %i2, [ %i0 + 0x1c ]
   heap->last_block = last_block;
   _Heap_Free_list_head( heap )->next = first_block;
   _Heap_Free_list_tail( heap )->prev = first_block;

   /* Last block */
   last_block->prev_size = first_block_size;
     6f28:	c2 20 c0 00 	st  %g1, [ %g3 ]


Something's up with the heap initialization. Haven't found out what exactly 
though. %g3=91CFE0F0 but should be in the RAM range (400XXXXX) for that "st" 
to make sense.



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