On Thu Oct 17 2013 14:39:37 GMT+0200, Charles Steinkuehler
<char...@steinkuehler.net> wrote:
On 10/17/2013 4:29 AM, Gilles Chanteperdrix wrote:
On 10/17/2013 02:58 AM, Charles Steinkuehler wrote:
On 10/16/2013 2:41 PM, Charles Steinkuehler wrote:
On 10/16/2013 11:12 AM, Charles Steinkuehler wrote:
I'll test with ipipe disabled, go through the Arm Porting guide, and
see
where that gets me...
After building a patched kernel without ipipe or xenomai enabled:
$ egrep '(IPIPE|XENO)' KERNEL/.config
# CONFIG_XENOMAI is not set
CONFIG_XENO_GENERIC_STACKPOOL=y
CONFIG_XENO_FASTSYNCH_DEP=y
CONFIG_XENO_FASTSYNCH=y
# CONFIG_IPIPE is not set
...the mmc issue seems fixed. So according to the porting guide, this
indicates a likely problem with interrupts or the interrupt controller
(as Gilles indicated).
Based on the ARM porting guide, the first thing I did was to disable IRQ
muting by simply commenting out the two calls to:
ipipe_pic_muter_register
...in<linux>/drivers/gpio/gpio-omap.c
This results in a kernel that DOES NOT HANG with ipipe enabled!
It does not really make sense: when I-pipe is enabled but Xenomai
disabled, the PIC muting is only used to tweak the interrupt controller
priority. Since there are only secondary mode irqs, they all should use
the same priority.
I am confused as well, particularly by the fact that adding back the
xenomai patches (but leaving the gpio IRQ masking disabled) gets me back
to the hung mmc task.
Is arch/arm/mach-omap2/irq.c modified by the BeagleBone patches, if yes,
could you put the modified version somewhere I could have a look at it?
The minor patch to the irq file doesn't seem likely to cause problems,
but there is a *LOT* of mmc driver code that is changed between mainline
and the BeagleBone kernel, much of it related to DMA.
If I got it it right the device tree handling is also complete new (
arch / arm / boot / dts /) compared to mainline?
If so, the enhanced DMA (edma) should also be taken into account ?
--
Ralf
I've put up my full kernel build tree in case you want to look at any
other files. The top directory is the scripts and patches used to build
the kernel. The actual kernel code already patched with the BeagleBone
patch set as well as ipipe and xenomai is in the KERNEL directory:
http://morpheus.steinkuehler.net/xenomai
Are the xenomai patches similar to the preempt-rt patch set in that they
can expose underlying flaws in driver code that is not SMP clean?
If so, I suspect something with the mmc and dma updates specific to the
BeagleBone patch set. Maybe I should be pestering the OMAP kernel list?
_______________________________________________
Xenomai mailing list
Xenomai@xenomai.org
http://www.xenomai.org/mailman/listinfo/xenomai
