<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 20, 2016 at 6:18 PM, Nick Withers <span dir="ltr"><<a href="mailto:nick.withers@anu.edu.au" target="_blank">nick.withers@anu.edu.au</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Wed, 2016-01-20 at 18:10 -0600, Joel Sherrill wrote:<br>
> I am glad you have a fix but I want to make sure I understand what<br>
> needs to<br>
> happen next.<br>
<br>
</span>No fix required, all is well.<br>
<span class=""><br></span></blockquote><div><br></div><div>Thanks for confirming this. Over the years, it is often hard to tell in the mailing</div><div>list archives if a problem needed a code change or not.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> Does the git commit you linked to need to be applied to a release<br>
> branch?<br>
<br>
</span>Don't believe so; the commit referenced below fixed an issue only<br>
introduced two months before on 4.11 ( <a href="https://git.rtems.org/rtems/comm
it/?h=4.11&id=32506647001a815e3c0daf25757d386104a07184" rel="noreferrer" target="_blank">https://git.rtems.org/rtems/comm<br>
it/?h=4.11&id=32506647001a815e3c0daf25757d386104a07184</a> )<br>
<span class=""><br></span></blockquote><div><br></div><div>Great.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> Are things OK on the master?<br>
<br>
</span>I believe so, 4.11 was only branched well after the fix.<br>
<br>
That said, I'm just trying to build master / 4.12 RSB to have a gander<br>
at the GCC 5.0 debug/65779 issue (and will retest there and post if<br>
there're any dramas). I have to debug some issues with RSB first though<br></blockquote><div><br></div><div>Yeah. I filed an issue for a 4.11 RSB issue yesterday. I tossed all my tools</div><div>and tried to build from scratch. Now I am missing some tools on 4.11. :(</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
:-P<br>
<div class="HOEnZb"><div class="h5"><br>
> --joel<br>
><br>
> On Wed, Jan 20, 2016 at 5:58 PM, Nick Withers <<br>
> <a href="mailto:nick.withers@anu.edu.au">nick.withers@anu.edu.au</a>><br>
> wrote:<br>
><br>
> > Hullo all,<br>
> ><br>
> > I've finally looked into this one again and thought I'd follow up<br>
> > for<br>
> > the archives... Long story short,<br>
> > <a href="https://git.rtems.org/rtems/commit/?h" rel="noreferrer" target="_blank">https://git.rtems.org/rtems/commit/?h</a><br>
> > =4.11&id=90ce69b0f19ab410d502fa93a64f02de55cf4a53 fixed it :-)<br>
> ><br>
> > On Thu, 2014-08-14 at 10:39 +1000, Nick Withers wrote:<br>
> > > On Wed, 2014-08-13 at 10:31 -0400, Gedare Bloom wrote:<br>
> > > > I'm not a powerpc expert, but I have some questions for you to<br>
> > > > consider.<br>
> > ><br>
> > > Thanks for taking the time, much appreciated.<br>
> > ><br>
> > > > How long does it take the openpic_settimer() to take effect?<br>
> > > > If the isr was delayed, could another timer interrupt fire<br>
> > > > before<br>
> > > > setting the inhibit bit? Will both interrupts be received? This<br>
> > > > is<br>
> > > > hw-dependent, and I don't know the answer for powerpc.<br>
> > ><br>
> > > Interestingly, my interpretation of the MPIC manual (2.3, from<br>
> > > points<br>
> > > 5<br>
> > > particularly) seems to suggest I should see two interrupts if I<br>
> > > break<br>
> > > at<br>
> > > my interrupt handler (after IACK, before End-of-Interrupt) before<br>
> > > the<br>
> > > openpic_settimer(), if the timer would fire again. I don't... But<br>
> > > there<br>
> > > are a few layers between my handler and the hardware and no doubt<br>
> > > I<br>
> > > just<br>
> > > dont understand it properly.<br>
> ><br>
> > Yeah, I'm full of it here.<br>
> ><br>
> > "Timer interrupts will function essentially as edge-triggered<br>
> > events.<br>
> > If the timer period expires while a previous interrupt from the<br>
> > same<br>
> > timer is pending, the subsequent interrupt will be lost". The<br>
> > interrupt's pending until EOI.<br>
> ><br>
> > > > Perhaps the<br>
> > > > powerpc ISR_Handler clears the interrupt source before calling<br>
> > > > the<br>
> > > > isr, so there might be time for another timer to fire? Or<br>
> > > > perhaps<br>
> > > > the<br>
> > > > hardware buffers multiple interrupts received from the same<br>
> > > > source.<br>
> > > > If<br>
> > > > so, then you would need to acknowledge the interrupt after<br>
> > > > clearing<br>
> > > > the inhibit bit, so another interrupt that was queued from the<br>
> > > > same<br>
> > > > source doesn't fire.<br>
> ><br>
> > powerpc/shared/irq/openpic_i8529_irq.c:C_dispatch_irq_handler()<br>
> > calls<br>
> >  openpic_eoi() after bsp_irq_dispatch_list(), so I think I'm in the<br>
> > clear here.<br>
> ><br>
> > Post<br>
> > <a href="https://git.rtems.org/rtems/commit/?h=4.11&id=90ce69b0f19ab410d502" rel="noreferrer" target="_blank">https://git.rtems.org/rtems/commit/?h=4.11&id=90ce69b0f19ab410d502</a><br>
> > fa93a64f02de55cf4a53 , things look good on the mvme3100 (updated<br>
> > test<br>
> > program attached).<br>
> ><br>
> > PSim still doesn't work as expected, but I'm reasonably convinced<br>
> > that's a PSim thing... As per below, the reported OpenPIC timer<br>
> > frequency's not valid and certainly not being honoured in terms of<br>
> > actual timings.<br>
> ><br>
> > Thanks all<br>
> ><br>
> > > > On Wed, Aug 13, 2014 at 3:58 AM, Nick Withers <<br>
> > > > <a href="mailto:nick.withers@anu.edu.au">nick.withers@anu.edu.au</a>> wrote:<br>
> > > > > Sorry, hit "Send" a bit quick...<br>
> > > > ><br>
> > > > > On Wed, 2014-08-13 at 16:42 +1000, Nick Withers wrote:<br>
> > > > > > On Tue, 2014-08-12 at 12:48 +1000, Nick Withers wrote:<br>
> > > > > > > Hullo all,<br>
> > > > > > ><br>
> > > > > > > Has anyone used an OpenPIC timer (see<br>
> > > > > > > "c/src/lib/libbsp/powerpc/shared/openpic/") in single<br>
> > > > > > > -shot<br>
> > > > > > > mode before?<br>
> > > > > > > I seem to be having some trouble with them, in particular<br>
> > > > > > > ensuring that<br>
> > > > > > > an ISR fires only once.<br>
> > > > > > ><br>
> > > > > > > According to "c/src/lib/libbsp/powerpc/mvme3100/README",<br>
> > > > > > > "The<br>
> > > > > > > setup<br>
> > > > > > > routine allows for specifying single-shot or periodic<br>
> > > > > > > mode",<br>
> > > > > > > but I can't<br>
> > > > > > > seem to see how to achieve the former.<br>
> > > > > > ><br>
> > > > > > > Going off<br>
> > > > > > > "c/src/lib/libcpu/powerpc/new<br>
> > > > > > > -exceptions/bspsupport/nested_irq_test.c" I<br>
> > > > > > > should at least openpic_maptimer(..., 0) and<br>
> > > > > > > openpic_inittimer(..., ...,<br>
> > > > > > > 0) to stop the timer. I've tried that in the ISR and the<br>
> > > > > > > openpic_inittimer() call can stall indefinitely in<br>
> > > > > > > openpic_safe_writefield() on "while<br>
> > > > > > > (openpic_read(addr=0xe1041120) &<br>
> > > > > > > OPENPIC_ACTIVITY);".<br>
> > > > > ><br>
> > > > > > Turns out the "OpenPIC" on at least the MVME3100 is<br>
> > > > > > actually an<br>
> > > > > > IBM<br>
> > > > > > MPIC, which has documentation[1]! Huzzah!<br>
> > > > > ><br>
> > > > > > So, to follow up, neigher openpic_inittimer() and<br>
> > > > > > openpic_maptimer()<br>
> > > > > > need to be called to halt the timer and prevent further<br>
> > > > > > interrupts (but<br>
> > > > > > need to be done to set the timer up before first use).<br>
> > > > > ><br>
> > > > > > An openpic_settimer(..., OPENPIC_TIMER_COUNT_INHIBIT, 0)<br>
> > > > > > will<br>
> > > > > > do it.<br>
> > > > > ><br>
> > > > > > Also note that for the hardware to latch a new time<br>
> > > > > > programmed<br>
> > > > > > through<br>
> > > > > > openpic_settimer(), the OPENPIC_TIMER_COUNT_INHIBIT bit has<br>
> > > > > > to<br>
> > > > > > transition from a 1 to a 0.<br>
> > > > ><br>
> > > > > So I think I'm driving the timer correctly (but if anyone<br>
> > > > > else's<br>
> > > > > ever<br>
> > > > > used 'em, a double-check'd be loverly :-P).<br>
> > > > ><br>
> > > > > Any yet, it seems I'm potentially getting a double-ISR-hit,<br>
> > > > > though I<br>
> > > > > haven't been able to trigger it reliably; it feels like some<br>
> > > > > kind<br>
> > > > > of fun<br>
> > > > > race condition.<br>
> > > > ><br>
> > > > > I've attached a minimised code sample (build with, e.g.,<br>
> > > > > "[g]make<br>
> > > > > RTEMS_ROOT=/home/nick/rtems/rtems-4.11 BSP=mvme3100") which<br>
> > > > > has<br>
> > > > > been<br>
> > > > > tested successfully (i.e., it shows the failure) through PSim<br>
> > > > > and<br>
> > > > > on<br>
> > > > > MVME3100 hardware (though it's timing-dependent, so YMMV!).<br>
> > > > > When<br>
> > > > > mvme3100_timer_set()'s called, it:<br>
> > > > >   - Asserts that a semaphore's locked*<br>
> > > > >   - Asserts that the timer's currently stopped<br>
> > > > >   - printk()s 's'<br>
> > > > >   - Starts the timer<br>
> > > > >   - printk()s 'S'<br>
> > > > >   - Blocks on the semaphore<br>
> > > > >   - Asserts that the semaphore's locked<br>
> > > > >   - printk()s '_'<br>
> > > > >   - returns<br>
> > > > ><br>
> > > > > The timer's vectored to mvme3100_timer_interrupt() and when<br>
> > > > > this<br>
> > > > > is<br>
> > > > > called, it:<br>
> > > > >   - Stops the timer (notionally, anyway! I've stepped through<br>
> > > > > it<br>
> > > > > in GDB<br>
> > > > > and it seems to work as expected), through<br>
> > > > > openpic_settimer(...,<br>
> > > > > OPENPIC_TIMER_COUNT_INHIBIT, 0)<br>
> > > > >   - printk()s 'p'<br>
> > > > >   - Increments the semaphore<br>
> > > > >   - printk()s 'P'<br>
> > > > ><br>
> > > > > So I'm expecting, for each '_'-delimited block of text, to<br>
> > > > > see<br>
> > > > > one set<br>
> > > > > of "s(...)S" for each "p(...)P".<br>
> > > > ><br>
> > > > > Here's part of a run in PSim:<br>
> > > > > ____<br>
> > > > ><br>
> > > > > psim-cmds:5: Error in sourced command file:<br>
> > > > > No symbol "the_source" in current context.<br>
> > > > > (gdb) run<br>
> > > > > Starting program:<br>
> > > > > /usr/home/nick/projects/sem_isr/sem_isr.debug<br>
> > > > > warning: failed to reevaluate condition for breakpoint 1: No<br>
> > > > > symbol "the_source" in current context.<br>
> > > > > OpenPIC Version 1.2 (2 CPUs and 17 IRQ sources) at 0x0C130000<br>
> > > > > OpenPIC Vendor 0 (Unknown), Device 0 (Unknown), Stepping 0<br>
> > > > > Overriding NumSources (17) from configuration with 16<br>
> > > > > OpenPIC timer frequency is 1 Hz<br>
> > > > > Starting...<br>
> > > > > sSpP_sSpP_sSpP_sSpP_sSpP_sSpP_sSpP_sSpP_sSpPpP_assertion<br>
> > > > > "rtems_semaphore_count(timer->semaphore) == 0" failed: file<br>
> > > > > "mvme3100_timer.c", line 207, function: mvme3100_timer_wait<br>
> > > > > ____<br>
> > > > ><br>
> > > > > [The reported OpenPIC timer frequency's not valid and<br>
> > > > > certainly<br>
> > > > > not<br>
> > > > > being honoured in terms of actual timings - this is expected<br>
> > > > > with<br>
> > > > > PSim,<br>
> > > > > isn't it?]<br>
> > > > ><br>
> > > > > That's consistent with what I see when running it on MVME3100<br>
> > > > > hardware<br>
> > > > > (albeit typically with different interleavings of the ISR /<br>
> > > > > task),<br>
> > > > > except that there's no obvious double-up (e.g., the "pPpP"<br>
> > > > > just<br>
> > > > > before<br>
> > > > > the assertion failure, above) - I presume because printk()'s<br>
> > > > > output<br>
> > > > > isn't guaranteed to make it out to a serial console before<br>
> > > > > the<br>
> > > > > assertion<br>
> > > > > crashes it...?<br>
> > > > ><br>
> > > > > I guess it'd be nice for me to provide code that perhaps<br>
> > > > > generates<br>
> > > > > interrupts in another manner. Would anyone have any<br>
> > > > > suggestions<br>
> > > > > here? is<br>
> > > > > there an rtems_interrupt_cause()-like that's implemented?<br>
> > > > > Even if<br>
> > > > > there<br>
> > > > > is it might be hard to get the timings right without a higher<br>
> > > > > -precision<br>
> > > > > timer.<br>
> > > > ><br>
> > > > > > > Any ideas? Perhaps I'm going about this the wrong way to<br>
> > > > > > > begin with...<br>
> > > > > > > What I'm after is a microsecond-precision-ish one-shot<br>
> > > > > > > timer<br>
> > > > > > > that'll be<br>
> > > > > > > used thousands of times per second.<br>
> > > > > > ><br>
> > > > > > > Ta all!<br>
> > > > > ><br>
> > > > > > [1]<br>
> > > > > > <a href="https://www-01.ibm.com/chips/techlib/techlib.nsf/techdocs/F" rel="noreferrer" target="_blank">https://www-01.ibm.com/chips/techlib/techlib.nsf/techdocs/F</a><br>
> > > > > > 2797<br>
> > > > > > 1551C9EED8E8525774A0048770A/$file/mpic_db_05_16_2011.pdf<br>
> > > > ><br>
> > > > > * Possibly dodgily: I implemented an rtems_semaphore_count<br>
> > > > > kludge, but<br>
> > > > > can't claim to actually understand what I did properly. I<br>
> > > > > have<br>
> > > > > observed<br>
> > > > > the same symptoms using a POSIX semaphore (which to my<br>
> > > > > knowledge<br>
> > > > > isn't<br>
> > > > > explicitly specified as being allowed in an RTEMS ISR, though<br>
> > > > > ISTR<br>
> > > > > seeing it somewhere before)<br>
> > > > > --<br>
> > > > > Nick Withers<br>
> > > > ><br>
> > > > > Embedded Systems Programmer<br>
> > > > > Department of Nuclear Physics, Research School of Physics and<br>
> > > > > Engineering<br>
> > > > > The Australian National University (CRICOS: 00120C)<br>
> ><br>
> > _______________________________________________<br>
> > users mailing list<br>
> > <a href="mailto:users@rtems.org">users@rtems.org</a><br>
> > <a href="http://lists.rtems.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/users</a><br>
> ><br>
</div></div></blockquote></div><br></div></div>