OpenRISC patch series...

[Jakob Viketoft]

Hello Hesham,

________________________________________
From: Hesham Almatary [heshamelmatary at gmail.com]
Sent: Friday, February 19, 2016 15:51
To: Jakob Viketoft
Cc: devel at rtems.org
Subject: Re: OpenRISC patch series...

>Hi Jakob,
>
>On Fri, Feb 19, 2016 at 11:59 PM, Jakob Viketoft
><jakob.viketoft at aacmicrotec.com> wrote:
>>
>> ________________________________________
>> From: Sebastian Huber [sebastian.huber at embedded-brains.de]
>> Sent: Friday, February 19, 2016 13:44
>> To: Jakob Viketoft; devel at rtems.org
>> Subject: Re: OpenRISC patch series...
>>
>> >On 19/02/16 13:40, Jakob Viketoft wrote:
>> >> ________________________________________
>> >> From: devel [devel-bounces at rtems.org] on behalf of Sebastian Huber [sebastian.huber at embedded-brains.de]
>> >> Sent: Friday, February 19, 2016 13:37
>> >> To:devel at rtems.org
>> >> Subject: Re: OpenRISC patch series...
>> >>
>> >>> >Are these patches relative to the 4.11 branch or the master?
>> >> Sorry that I forgot to mention that, they are relative to 4.11 as of d85db176e7d5bcb832ce0764d7db8b94090c4256.
>> >
>> >Ok, please rebase them on the master. Once they are integrated, we
>> >should discuss if they are back ported to 4.11.
>>
>> Ok, does the format work on this first set? I assume it's okay to resend all 7 patches again, rebased on master.
>>
>> As for the backporting, most of the changes are crucial for having OpenRISC working at all since there were some mistakes in _ISR_enable/disable and also the link scripts was a pure copy of an arm-variant that didn't make much sense and got the stack wrong. I.e. I hope it will be able to make it to 4.11.
>>
>The port was working fine late 2014 on both or1ksim and QEMU.
>Actually it passed the 467 out of 503 tests part of RTEMS Tester at
>this time. In 2015, the port supported running or1k on real hardware
>FPGA/Atlys and that's why the BSP name changes from or1ksim to
>generic_or1k.

>Have you tested the changes on real hardware and/or simulator? I
>noticed you said you're using your own toolchain and not RSB. This
>might not work for RTEMS, as the port assumes the upstream tools built
>by RSB (except for GCC since it didn't get upstream yet). The other
>option is to add your own changes to or1k gcc [1] and push any other
>patches upstream like what Sebastian suggested.
>
>[1] https://github.com/openrisc/or1k-gcc/tree/or1k-5.2.0

Yes, we have run it quite extensively on real hardware for a while now. I also know that the test code in RTEMS passes without fail, but when we use it with some more advanced software which make heavy use of threads and signals, it went berserk on the watchdog list. A more demanding test using extended ticker.c code showed it to be the error in ISR_enable/disable (along with some needed bugfixes in RTEMS on signals). Some of the changes are for readability where hardcoded values were used for registers or bits in them, and others had to do with setting up the system into a known state each boot. Without that we would require a power cycling of the board each time instead of a simple re-load of the application software. If you would review the patches on a simple code read basis, I don't think you would disagree much with what has been put there, I'm happy to answer any question or concern that you might have.

I didn't say we didn't use RSB to build the toolchain, I just have it pointed to use our internal repos in cases where we have had to add code to complement what's available upstream. To distinct it from a "standard" build of RSB we simply added the name -aac- to avoid confusion, but if it's a big problem we might revert this or keep the config.sub patch only in our tree.

Jakob Viketoft
Senior Engineer in RTL and embedded software

ÅAC Microtec AB
Dag Hammarskjölds väg 48
SE-751 83 Uppsala, Sweden

T: +46 702 80 95 97
http://www.aacmicrotec.com