Running RTEMS on a LEON2 from ROM

Mike Looijmans mike.looijmans at
Wed Jul 26 05:25:24 UTC 2017

On 25-07-17 18:10, Jiri Gaisler wrote:
> On 07/25/2017 03:43 PM, Mike Looijmans wrote:
>> On 25-07-17 15:06, Mike Looijmans wrote:
>>> On 25-07-17 14:42, Jiri Gaisler wrote:
>>>> On 07/25/2017 02:36 PM, Mike Looijmans wrote:
>>>>> On 25-07-17 12:51, Mike Looijmans wrote:
>>>>>> On 25-07-17 12:13, Jiri Gaisler wrote:
>>>>>>> I haven't looked at this for a while, but I remember that the trap
>>>>>>> table
>>>>>>> usually sits in the beginning of the .text segment. RTEMS overwrites
>>>>>>> the
>>>>>>> trap entries at boot so if the trap table is in PROM, you will get a
>>>>>>> memory exception trap. To run from PROM, you will need to allocate a
>>>>>>> new
>>>>>>> trap table in RAM (4k aligned) and change the %tbr register to
>>>>>>> point to
>>>>>>> it. This has to be done early before the trap table is
>>>>>>> initialized by
>>>>>> Any hint on where this trap table allocation should happen in RTEMS
>>>>>> code?
>>>>>>> RTEMS. An elegant way of doing this would be to place the trap
>>>>>>> table in
>>>>>>> a separate linker section, and then putting it to the desired place
>>>>>>> with
>>>>>>> a custom linker file. The %tbr register should then be
>>>>>>> initialized to
>>>>>>> the start of the trap table section.
>>>>>> Simplest would be to put the trap table at the start of RAM (which
>>>>>> will always have page alignment) and let the data segment follow on
>>>>>> that.
>>>>>> Simply directing the table into the data segment would work as well,
>>>>>> I guess, the init code copies it on boot along with the rest of the
>>>>>> initialized data then.
>>>>> I did just that, the trap table now is at start of RAM, I left a small
>>>>> init vector at address 0 in ROM to jump to the startup code.
>>>>> After copying the .data segment into RAM, I set the %tbr register,
>>>>> enable traps and continue. The table is indeed there at the first 4k
>>>>> of RAM now.
>>>>> This executes okay, but no improvement yet. It does not even reach a
>>>>> breakpoint at "bsp_pretasking_hook".
>>>>> Still RTEMS silently locks up. I'm soft of bisecting now how far it
>>>>> goes, since the backtrace is still blank ....
>>>> Why don't you run your code in the sis simulator? If you build RSB from
>>>> git, you will also get sis with leon2 support. You can then enable a
>>>> large trace buffer and execute the prom image until it crashes ...
>>> Uh, well mostly because up until 10 seconds ago I had no idea what a
>>> "sis simulator" is.
>> I tried running "sparc-rtems4.11-sis", load the application. Looks
>> okay in memory. It stops at the first access to the 0x80000000 address
>> range (LEON2 config registers) when the program tries to set up memory
>> and uart config and such. That's about 10 instructions, the real thing
>> got a lot further than that.
>> I'm looking for some document or website that explains how this should
>> work...
> There are some README files in the gdb sources under sim/erc32. Here is

Hmm, cannot find anything in anything i've downloaded and installed so far.

I found a PDF manual on the ESA site though, that explains a bit more.

> 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.

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

Please consider the environment before printing this e-mail

More information about the users mailing list