From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Thu, 30 Apr 2015 20:14:13 +0200 From: Gilles Chanteperdrix Message-ID: <20150430181413.GY1993@hermes.click-hack.org> References: <20150430161730.GX1993@hermes.click-hack.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Xenomai] Ipipe-core patched kernel fails to start when certain platform drivers are enabled List-Id: Discussions about the Xenomai project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Hongfei Cheng Cc: xenomai@xenomai.org On Thu, Apr 30, 2015 at 11:12:58AM -0700, Hongfei Cheng wrote: > On Thu, Apr 30, 2015 at 9:17 AM, Gilles Chanteperdrix > wrote: > > On Thu, Apr 30, 2015 at 08:53:10AM -0700, Hongfei Cheng wrote: > >> We've been working on porting the I-pipe core to an ARMv8/AArch64 > >> platform (Qualcomm msm8994). > >> > >> Taking the advice we received from this forum, our approach has been > >> to add and enable the I-pipe core patches on this new architecture one > >> (small) step at a time. > >> > >> The development platform is currently configured and patched as follows: > >> 1). Only 1 CPU core is enabled (via kernel command line). > >> 2). Interrupt controller, GPIO controller, and platform drivers are > >> patched following the porting guide and the existing ipipe-core code, > >> along with the relevant discussions on this list. > >> 3). I-pipe spinlocks are applied to the instances where we think > >> require "ipipe protection", although we are still uncertain if this > >> work is complete in our code. > > > > Each spinlock you turn into an ipipe spinlock bears a risk of creating > > large masking sections, so, this is something you should not do a > > lot. The porting guide warns about that. This is something > > important. Do only this when it is really needed, and not before > > having examined every section where this spinlock is used by Linux > > to see if it has no chance of creating a large masking section. If > > it does, you will have to find other workarounds. > > > >> 4). High resolution counter is not yet supported as we're exploring > >> different way(s) to implement TSC. > >> 5). CPU_FREQ and CPU_IDLE are *not yet* disabled, mainly due to the > >> dependency of big.LITTLE architecture vendor-specific code. > > > > This is bad. Probably a source of troubles. Disable them. > > > >> > >> Below is what we've observed so far: > >> 1). Hardware timer appears to be running properly with > >> arch_timer_ack() being called regularly and reliably. > >> 2). I-pipe is indeed grabbing the interrupt (through examining the call stack). > >> 3). The kernel startup process comes to a screeching halt when probing > >> certain platform drivers, such as ipa or pcie. No kernel oops is > >> shown. In this kernel state, the *only* task being scheduled is the > >> watchdog process. > >> > >> I believe there are "holes", to borrow the term from Gilles, in the > >> platform drivers. However the few platform drivers which call > >> generic_handle_irq have all been replaced with > >> ipipe_handle_demuxed_irq. > > > > This looks wrong. Only when the irq is demuxed should you use > > ipipe_handle_demuxed_irq. If the parent irq is a plain Linux irq, > > there is no reason to replace generic_handle_irq with > > ipipe_handle_demuxed_irq. In the GPIO case, the demux function is > > run as an interrupt ack callback, so it runs "ahead of the > > pipeline", and is not executed in Linux domain so can not use > > generic_handle_irq. > > > >> > >> My questions are: > >> 1). Has anyone encountered similar experience while porting I-pipe > >> core? > > > > Porting the I-pipe code to a new ARM board has always been full of > > surprises for me, it has always required to understand some new > > problems, and avoid them. I have always found the I-pipe tracer to > > be a great help in that case. Of course, enabling the I-pipe debug > > options is a must, also (though it can create double faults > > conditions when something goes really wrong). > > > > > >> 2). Could such behavior be the result of missing or incorrectly > >> applied I-pipe spinlocks? > > > > No > > > >> > >> I'll put the kernel config, patched code, and startup logs in the > >> cloud and post the link here. > > > > I do not think it is necessary. > > > > -- > > Gilles. > > Thank you, Gilles, for your always prompt and insightful response. > We'll re-examine the problematic places in the code, based on your > input and comments. > > By the way, Gilles, have you been able to squeeze supporting > I-pipe/Xenomai on ARMv8/HiKey-board into your busy schedule? Not yet, but this should not be long now. -- Gilles.