OpenRISC patch series...

Fri Feb 19 15:44:43 UTC 2016

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

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

First I need to point out that we have a custom BSP which uses much of the common or1k stuff, but where we haven't run generic_or1k directly. In my patches however, I have patched all the relevant work that we have done in our BSP back to the generic_or1k one. I would also like to add the interrupt handler there, but I haven't done so at this point. We would also like to upstream our BSP as well, but we haven't quite sorted out yet how we want to go about with the drivers since we at the moment compile with out-of-tree drivers for practical (git-repo) reasons.
FPGA boards and RTL SoC are all custom, but you can read a bit more about them here:
http://www.aacmicrotec.com/index.php/2012-04-17-12-17-04/products/space-wire-avionics

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

They shouldn't, with the only exception the config.sub file. Where we have code in our BSP which are in that directory alone, I have ported them back to the generic_or1k port to help benefit anyone else running or1k in RTEMS.
Let me just rebase the patches off of master and repost before you do too much, I noticed some strangeness has crept into some of the diff's for some reason.

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