Hi Jakob,
On Sat, Feb 20, 2016 at 2:12 AM, Jakob Viketoft <jakob.viket...@aacmicrotec.com> wrote: > Hello Hesham, > > ________________________________________ > From: Hesham Almatary [heshamelmat...@gmail.com] > Sent: Friday, February 19, 2016 15:51 > To: Jakob Viketoft > Cc: devel@rtems.org > Subject: Re: OpenRISC patch series... > >>Hi Jakob, >> >>On Fri, Feb 19, 2016 at 11:59 PM, Jakob Viketoft >><jakob.viket...@aacmicrotec.com> wrote: >>> >>> ________________________________________ >>> From: Sebastian Huber [sebastian.hu...@embedded-brains.de] >>> Sent: Friday, February 19, 2016 13:44 >>> To: Jakob Viketoft; devel@rtems.org >>> Subject: Re: OpenRISC patch series... >>> >>> >On 19/02/16 13:40, Jakob Viketoft wrote: >>> >> ________________________________________ >>> >> From: devel [devel-boun...@rtems.org] on behalf of Sebastian Huber >>> >> [sebastian.hu...@embedded-brains.de] >>> >> Sent: Friday, February 19, 2016 13:37 >>> >> To:devel@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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
