OpenRISC patch series...

[Hesham Almatary]

Hi Jakob,



On Sat, Feb 20, 2016 at 2:12 AM, Jakob Viketoft
<jakob.viketoft at aacmicrotec.com> wrote:
> 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.
Great, thanks for the details and contributing back with the fixes.
I am interested to know what hardware (FPGA board and RTL SoC) did you
use? It might be a good idea to have a list of targets that the port
has run on since the hardware implementation is very flexible.

> 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

Yes I totally support the readability-related patches.

 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.
>
Do any of the patches add code that assumes your new "aac" additions?
I'll have to setup the RTEMS dev env, apply the patches and perhaps
run a few test cases and RTEMS Tester.

> 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



-- 
Hesham