Running RTEMS on a LEON2 from ROM
Mike Looijmans
mike.looijmans at topic.nl
Thu Jul 27 12:50:45 UTC 2017
On 27-07-17 13:07, Jiri Gaisler wrote:
>
>
> On 07/27/2017 12:23 PM, Jiri Gaisler wrote:
>>
>> 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.
>
> I saw in your hello.num that _Per_CPU_Information should be 0x40003000.
> I assigned this value to %g6 before execution and now the program runs
> to end:
>
> *** BEGIN OF TEST HELLO WORLD ***
> Hello World
> *** END OF TEST HELLO WORLD ***
>
> This looks good, just fix the start.S to set %g6 and you should have a
> working binary..! Meanwhile, I will fix the VMA/LVA problem in sis -
> thanks for spotting this...
Ah, indeed. Setting that magic %g6 register got lost while moving things
around for ROM boot.
I added a "set _Per_CPU_Information, %g6" prior to the card_boot call, and now
the hello program runs okay in simulation.
Tried on target, using "grmon2 -leon2 -ni -u". There it only works if i "run
0", press ctrl-C within a second or so, and then "cont". Without breaking, it
just sits there, and if I ctrl-C after a minute or so, it just says "program
terminated normally". But at least it stopped crashing...
If you're interested, this is the current state:
https://github.com/topic-embedded-products/rtems/commits/bsp-miamil2
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
More information about the users
mailing list