Re: [Xenomai-help] Adeos patched kernel hangs mounting root file system

[Bob Feretich <bob.feretich@domain.hid>]

[-- Attachment #1: Type: text/plain, Size: 2017 bytes --]

  On the BeagleBoard...

    * The SD card/MMC is attached to the OMAP3530 chip MMC1 hardware
      Port. (The chip has 3 SD/MMC ports, numbered 1, 2, and 3.) The
      BeagleBoard connects the MMC2 port to an expansion connector and
      its not used in my application. The BeagleBoard does not use MMC3
      (not connected to anything).
    * The MMC1 hardware port is the first mmc port and is referred to in
      the kernel mmc0.
    * The OMAP controller for this port interrupts on IRQ 83.
    * The OMAP controller also uses SDMA channels 60 and 61 which
      results in other IRQs from the DMA controller.
    * The Card Detect signal from the SD card/MMC interface is wired to
      a TPS65950 chip
    * This TPS65950 chip presents the Card Detect interrupt to the
      OMAP3530 via sys_nirq[0]. This signal is mapped to IRQ 7. The
      TPS65950 can funnel up to 18 interrupts into sys_nirq[0].
    * The Level 2 interrupt handler maps the Card Detect interrupt to
      IRQ 384.  IRQ 384 is the first IRQ of the TWL4030 GPIO IRQ space.
      Apparently the the TWL4030 interrupt mapping is used for the TPS65950.
    * My SD card has two partitions. The first is a FAT partition
      containing the u-boot and kernel boot image. The second is a ext3
      partition containing the root file system.

It's possible that the kernel is expecting a Card Detect interrupt to 
proceed with the mounting of the root file system. I noticed that the 
/proc/interrupts listing that I mailed you showed 2 interrupts each on 
IRQ 384 and on IRQ 7.
Does Xenomai support TWL4030 style Level 2 interrupts?
Could pending interrupts have gotten lost when when Adeos initializes?

Regards,
Bob Feretich

On 7/19/2010 5:15 PM, Bob Feretich wrote:
> The debounce clock is not the source of the problem.
> On the 2430 chip, the debounce clock is under software control. For 
> the OMAP3 chips, its been placed under hardware control. So the 2.6.31 
> kernel classifies the  this message as a warning...
... snipped ...


[-- Attachment #2: Type: text/html, Size: 2578 bytes --]