Running RTEMS on a LEON2 from ROM

Jiri Gaisler jiri at gaisler.se
Thu Jul 27 10:23:15 UTC 2017



On 07/27/2017 07:49 AM, Mike Looijmans wrote:
> On 27-07-17 07:46, Mike Looijmans wrote:
>> On 26-07-17 17:41, Jiri Gaisler wrote:
>>>
>>>
>>> On 07/26/2017 04:17 PM, Jiri Gaisler wrote:
>>>>
>>>> On 07/26/2017 03:24 PM, Mike Looijmans wrote:
>>>>> On 26-07-17 13:36, Mike Looijmans wrote:
>>>>>> 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.
>>>>>>
>>>>> "_Heap_Initialize" is called twice. Once from
>>>>> _Workspace_Handler_initialization with sensible values, and the
>>>>> second
>>>>> time it's called from RTEMS_Malloc_Initialize, with the heap_end set
>>>>> to 0x91CFE0FF which isn't valid and causes the crash.
>>>>>
>>>> _Heap_Initialize is called twice, this is normal. However, the SPARC
>>>> port has a peculiar way of passing the top of memory, it does that by
>>>> writing it to a symbol called rdb_start, which is located at vector
>>>> 0x7c  in the trap table. In normal cases, rdb_start is at address
>>>> 400007c0. I guess when the trap table is relocated, the value is lost
>>>> somehow and overwritten with a assembly instruction.
>>>>
>>>> Normal leon2 executable:
>>>>
>>>> (gdb) p /x rdb_start
>>>> $2 = 0x40fffe80
>>>> (gdb)
>>>>
>>>> You binary after boot:
>>>>
>>>> (gdb) p /x rdb_start
>>>> $3 = 0x91d020ff
>>>> (gdb)
>>>>
>>>> If you recreate the trap table in RAM, make sure that the rdb_start is
>>>> properly set to end of RAM.
>>>>
>>>> Jiri.
>>> Let me clarify this. The rdb_start is set by either the prom loader,
>>> grmon or simulator to the top of available RAM (64-byte aligned), RTEMS
>>> then use the value to allocate the stack and heap. So your boot code
>>> must write this value before the system starts initializing. If you
>>> have
>>> 1 Mbyte of RAM, then set 0x400007c0 = 0x400fffe0 and it should work.
>>> The
>>> reason for this is historical, but it allows the same executable to run
>>> on different boards with varying amount of memory.
>>
>> Ok, adding ".word RAM_END-16" at that location fixes the crash in the
>> heap init.
>> Also printk seems to work now.
>>
>>
>> sis> go
>> resuming at 0x00000000
>> work_area_start = 0x40003540
>> work_area_size = 1018496 0x000F8A80
>> end = 0x400FBFC0
>> current stack pointer = 0x400FFF40
>> rdb_start = 0x400FFFC0
>> work_area_start = 0x40003540
>> work_area_size = 1018496 0x000F8A80
>> end = 0x400FBFC0
>> current stack pointer = 0x400FFF40
>> heap_start = 0x4000737E
>> heap_size = 1002562
>> Memory exception at 1000014 (illegal address)
>> IU in error mode (255)
>>      78366  40000090  91d020ff  ta  0xff
>>
>> The cause is at 0x8f84, disassembling that points to the
>> "_Scheduler_Update_heir" routine, which was called from
>> _Scheduler_default_Start_idle
>>
>> Some thread object here points at 0x10000000 which is an invalid
>> memory location.
>
> This smells like another "special" trap table entry - 0x1000000000 is
> the "nop" instruction, which fills about three quarters of the trap
> table.
>
>

This is probably a problem in your start.S . register %g6 contains
per-CPU information and is set early in booting in start.S:

 292         sethi   %hi(_Per_CPU_Information), %g6 ! get per-CPU control
 293         add     %g6, %lo(_Per_CPU_Information), %g6

The value of %g6 in your code is 0x000F4C79, ie points to PROM rather
than RAM. Check your start.S and make sure %g6 is setup correctly.

Jiri.





More information about the users mailing list