<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 4, 2016 at 2:04 PM, Joel Sherrill <span dir="ltr"><<a href="mailto:joel@rtems.org" target="_blank">joel@rtems.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Mon, Jan 4, 2016 at 3:48 AM, Sebastian Huber <span dir="ltr"><<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
<br>
On 23/12/15 22:22, Marcos Díaz wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
That patch didn't work,<br>
one reason is that it has a mistake:<br>
in kern_tc.c you defined this macro:<br>
<br>
#define _Timecounter_Release(lock_context) \<br>
+ *_ISR_lock_ISR_disable_and_acquire*(&_Timecounter_Lock, lock_context)<br>
<br>
I think you meant:<br>
<br>
*_ISR_lock_Release_and_ISR_enable*(&_Timecounter_Lock, lock_context)<br>
</blockquote>
<br>
Its strange, that this didn't lead to failures in Qemu.<br>
<br></blockquote><div><br></div></span><div>Qemu doesn't do cycle or instruction level simulation.</div></div></div></div></blockquote><div><br></div><div>I'm not sure if I fully understand this statement, but FWIW qemu can do per-instruction emulation, in fact I fixed one 7 years ago <a href="https://lists.nongnu.org/archive/html/qemu-devel/2009-08/msg01153.html">https://lists.nongnu.org/archive/html/qemu-devel/2009-08/msg01153.html</a></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> It does blocks of instructions between potential control flow points. Perhaps this is enough to make real hardware and the simulation behave differently in this case.</div><div><br></div><div>For sure, it reduces the potential race conditions showing up in SMP applications since it is alternating blocks of instructions on each simulated core.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
The other reason is that as I said, the driver checks for the flag PENDSTSET of the ICSR register, and I think this approach is wrong, because that flag goes down when the tick interrupt is attended. I used the solution I proposed before, but I'm still seeing some errors. I'll let you know what I find.<br>
</blockquote>
<br>
Would you mind testing the attached second version of the patch?<span><font color="#888888"><br>
<br>
-- <br>
Sebastian Huber, embedded brains GmbH<br>
<br>
Address : Dornierstr. 4, D-82178 Puchheim, Germany<br>
Phone : <a href="tel:%2B49%2089%20189%2047%2041-16" value="+4989189474116" target="_blank">+49 89 189 47 41-16</a><br>
Fax : <a href="tel:%2B49%2089%20189%2047%2041-09" value="+4989189474109" target="_blank">+49 89 189 47 41-09</a><br>
E-Mail : <a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a><br>
PGP : Public key available on request.<br>
<br>
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.<br>
<br>
</font></span><br></span><span class="">_______________________________________________<br>
devel mailing list<br>
<a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br></span></blockquote></div><br></div></div>
<br>_______________________________________________<br>
devel mailing list<br>
<a href="mailto:devel@rtems.org">devel@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><br>Daniel F. Gutson<br>Chief Engineering Officer, SPD<br><br>San Lorenzo 47, 3rd Floor, Office 5<br>Córdoba, Argentina<br><br>Phone: +54 351 4217888 / +54 351 4218211<br>Skype: dgutson<br>LinkedIn: <a href="http://ar.linkedin.com/in/danielgutson" target="_blank">http://ar.linkedin.com/in/danielgutson</a><br></div>
</div></div>