On Wed, Feb 18, 2015 at 08:17:26PM +0100, Jan Kiszka wrote: > On 2015-02-18 20:05, Gilles Chanteperdrix wrote: > > On Wed, Feb 18, 2015 at 08:00:54PM +0100, Jan Kiszka wrote: > >> On 2015-02-18 19:49, Gilles Chanteperdrix wrote: > >>> On Wed, Feb 18, 2015 at 07:46:02PM +0100, Jan Kiszka wrote: > >>>> On 2015-02-18 19:26, Gilles Chanteperdrix wrote: > >>>>> On Wed, Feb 18, 2015 at 07:21:41PM +0100, Jan Kiszka wrote: > >>>>>> On 2015-02-18 19:13, Gilles Chanteperdrix wrote: > >>>>>>> On Wed, Feb 18, 2015 at 07:12:43PM +0100, Jan Kiszka wrote: > >>>>>>>> On 2015-02-18 18:55, Gilles Chanteperdrix wrote: > >>>>>>>>> On Wed, Feb 18, 2015 at 06:52:14PM +0100, Jan Kiszka wrote: > >>>>>>>>>> Hi Gilles, > >>>>>>>>>> > >>>>>>>>>> I noticed on ARM (AM335 TI board) that the SIGDEBUG if the related > >>>>>>>>>> test > >>>>>>>>>> apparently only gets delivered to the receiver after it invokes a > >>>>>>>>>> syscall, not on return from its secondary mode migration. > >>>>>>>>>> Therefore the > >>>>>>>>>> page fault test of the sigdebug smokey test fails (tested with > >>>>>>>>>> Xenomai > >>>>>>>>>> 3), and I bet the watchdog test as well. Is this a known > >>>>>>>>>> limitation? > >>>>>>>>> > >>>>>>>>> Xenomai 2.6 sigdebug works fine on omap3 (very near from an > >>>>>>>> > >>>>>>>> Will try 2.6 next. > >>>>>>>> > >>>>>>>>> arm33xx). That being said, the AM3xx port is not part of the main > >>>>>>>>> line I-pipe, and based on a non mainline kernel, so it is difficult > >>>>>>>>> for me to answer this question. > >>>>>>>> > >>>>>>>> Then I'm possibly not building all recommended bits - I'm on 3.14 > >>>>>>>> I-pipe > >>>>>>>> upstream. That seems to work fine in general. Which version are you > >>>>>>>> referring to? > >>>>>>> > >>>>>>> The one documented in arm/patches/README > >>>>>> > >>>>>> https://github.com/RobertCNelson/linux-dev/commits/am33x-v3.8? There is > >>>>>> nothing explicitly stated regarding the AM3xx board, just that > >>>>>> reference > >>>>>> in the context of the Beaglebone. > >>>>>> > >>>>>> Anyway, I thought that syscall and exception handling should not be > >>>>>> dependent on board patches, should they? > >>>>> > >>>>> If you had been using a Linux fork (which I assumed you did, > >>>>> because you mentioned a processor which is not mainline officially), > >>>>> it would have been very possible for the Linux fork you used to > >>>>> break the changes in entry.S due to a bad conflict resolution. > >>>>> Linux forks very often tend to push changes in generic code even > >>>>> though they should not. > >>>> > >>>> The TI AM335x (Cortex-A8) comes with full mainline support, even for > >>>> 3.14. That's probably why vanilla I-pipe 3.14 works for us. > >>>> > >>>> Against all odds, I just got Debian installed into an Integrator/CP > >>>> machine model. Let's see if I can debug the issue that way. But I will > >>>> keep porting I-pipe to the Versatile Express in mind. > >>> > >>> If you have an ARM board, why going over all these contorsions? Why > >>> not simply enabling the I-pipe tracer and looking at what happens > >>> when you observe the problem you observe ? > >> > >> Because it's easier to debug than to trace such an issue. Emulation, and > >> even more virtualization, is more handy than real hw. E.g., this > >> particular board has the nice feature of not booting up automatically > >> when being power-cycled. > > > > I would tend to think that having to port the I-pipe to a virtual > > board consumes useless time, and useless maintenance time (because > > once you add the support for a board it takes time to maintain it), > > as is installing a debian distribution for that virtual board. > > During all that time you would have had the time to fix the bug 10 > > times using printk and the I-pipe tracer. And also, ARM processors > > have a nice feature called JTAG, which is much more reliable than > > hoping that a virtual hardware will have the same behaviour than > > real hardware. > > The Versatile Express is the ARM reference board, not something > arbitrary virtual. It's also what you get when you obtain the Fast Model > (CPU and system emulator) from ARM.
Nevertheless, it is a board that nobody uses for real projects, so adding support for it is still a waste of resources. > > Yes, there is JTAG, but virtual debugging still covers most of our > problems and remains faster (shorter setup and boot times). Almost all > of the nasty x86 issues I hacked on in the past yeats were reproducible > in KVM. All of the nasty ARM issues I hacked on in the past years were debugged on real hardware, most of them with creative use of the I-pipe tracer. For the fast compilation and boot time, I use mkrootfs: https://git.xenomai.org/mkrootfs.git/ -- Gilles. _______________________________________________ Xenomai mailing list [email protected] http://www.xenomai.org/mailman/listinfo/xenomai
