Running RTEMS on a LEON2 from ROM

[Jiri Gaisler]

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
how you do it with standalone sis:

$ sparc-rtems4.12-sis -leon2 application.exe

> hi 100
> go
> hi
> reg

With gdb:

$ sparc-rtems4.12-gdb application.exe

$ target sim -leon2
$ load
$ run

The trace buffer does not work in gdb, so I would use standalone sis to
debug the low-level boot problems. Once your application boots, you can
use gdb + some front-end (e.g. ddd) for high-level debugging.


>
>
>
> 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
>
>
>
> _______________________________________________
> users mailing list
> users at rtems.org
> http://lists.rtems.org/mailman/listinfo/users