On Wed, Feb 18, 2015 at 08:27:12PM +0100, Gilles Chanteperdrix wrote:
> 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/
And NFS, of course.
--
Gilles.
_______________________________________________
Xenomai mailing list
[email protected]
http://www.xenomai.org/mailman/listinfo/xenomai
