Xenomai booted with the 2.6.33 kernel on BeagleBoard!
I built the below 2.6.33 kernels...
Something obviously changed in the kernel between 2.6.31 and 2.6.33 to suppress the IRQ 378 interrupts that occurred at boot time. This change *may* be the reason that Xenomai works on the Beagleboard at 2.6.33, but not at 2.6.31.

I suspect that the Adeos patch may have trouble handling Level 2 interrupts coming through a twl4030 device. I know that it is an OMAP design practice to route the SD/MMC Card Detect interrupt through this device. The device also controls several voltage regulators supplying power to the board and OMAP chip. Overvoltage/undervoltage/thermal alerts may also be originated by this device.

The easiest way to test the twl4030 interrupt handling may be to use the SD Card for a removable file system (not root). If the file system automounts when the SD Card is plugged in, that would indicate that the twl4030 interrupts are being handled correctly. From the available documentation, the micro-SD card slot on the IGEPv2 should be able to be used for this testing.

My current dilemma is to figure out how to move the pieces of Angstrom that I want from the 2.6.32 kernel system to the 2.6.33 kernel ahead of the Angstrom train. :-(

Many thanks for you help Gilles.

Now that I can see Xenomai running, is there any documentation that describes useful things I can poke to obtain Xenomai state, status and statistics? (for example the meanings of the data in the /proc/Xemomai directory)

Regards,
Bob Feretich

On 7/20/2010 2:24 PM, Gilles Chanteperdrix wrote:
Bob Feretich wrote:
  I have downloaded the 2.6.33 omap kernel and I 'm starting to work 
with it. I'll write again when I have a clean boot of the vanilla kernel 
and tried to boot again with the Adeos patch.

I think that I figured out how to tell OpenEmbedded to build it.

When you display /proc/interrupts on the IGEPv2, do you see interrupts 
occuring at IRQs greater or equal to IRQ 384?
Do you see the same number reflected in IRQ 7?
I see this:
           CPU0
  7:     104068        INTC  TWL4030-PIH
 12:          4        INTC  DMA
 37:       1408        INTC  gp timer
 56:     313486        INTC  i2c_omap
 61:          0        INTC  i2c_omap
 74:         42        INTC  serial
 77:         93        INTC  ehci_hcd:usb2
 83:         66        INTC  mmc0
 86:         12        INTC  mmc1
 92:          1        INTC  musb_hdrc
336:        809        GPIO  eth0
378:          0     twl4030  twl4030_usb
384:          0     twl4030  mmc0

I believe the interrupts tagged "twl4030" are chained interrupts. Having
looked at the code, these interrupts are not chained the usual way
because they require i2c communication, which in turn requires a context
allowed to sleep, so they are dispatched by a kernel thread.