Kernel configuration issue (CONFIG_OMAP_MUX)

Hello,

I was compiling my custom kernel from OpenEmbedded sources (linux-omap-2.6.28-r27). My system root fs is running on the second partition of an SD card and everything works just fine until I turn on CONFIG_OMAP_MUX. That leads to a situation where kernel can't anymore mount root file system:
  http://pastebin.com/m7b817c4b
If I turn off CONFIG_OMAP_MUX everything is back to normal:
  http://pastebin.com/m42c5ca52
This is quite nasty as I would need I2C2 and CONFIG_I2C2_OMAP_BEAGLE autoselects CONFIG_OMAP_MUX.

Before I try dig more deeply into this I would be glad if anyone had any ideas how to solve this.

"Antti Seppanen" wrote:

Hello,

I was compiling my custom kernel from OpenEmbedded sources
(linux-omap-2.6.28-r27). My system root fs is running on the second partition
of an SD card and everything works just fine until I turn on CONFIG_OMAP_MUX.
That leads to a situation where kernel can't anymore mount root file system:
  http://pastebin.com/m7b817c4b
If I turn off CONFIG_OMAP_MUX everything is back to normal:
  http://pastebin.com/m42c5ca52
This is quite nasty as I would need I2C2 and CONFIG_I2C2_OMAP_BEAGLE
autoselects CONFIG_OMAP_MUX.

Before I try dig more deeply into this I would be glad if anyone had any ideas
how to solve this.

I am seeing the exact same thing on my Rev C2 board, but on my Rev B5
board I do not have this problem. I had not posted yet, as I have not
had time to look into it, and I suspect I am doing something wrong.
My Rev C2 board works fine with other images.

What Rev beagle board are you using?

-Preston

Sun, 19 Apr 2009, Preston Wilson wrote:

(linux-omap-2.6.28-r27). My system root fs is running on the second partition
of an SD card and everything works just fine until I turn on CONFIG_OMAP_MUX.
That leads to a situation where kernel can't anymore mount root file system:
  http://pastebin.com/m7b817c4b

What Rev beagle board are you using?

I ran the tests with rev C1D. A quick test with 2.6.27-r5 (also built from OE sources) seemed to work even with CONGIG_OMAP_MUX=y.

I will test my non-working kernel with a rev B4 board this evening.

That is sounding like mux handling changed between ES2.x and ES3.x.

regards,

Koen

Seems that I was able to solve this (sort of). Details below.

Mon, 20 Apr 2009, Koen Kooi wrote:

"Antti Seppanen" wrote:

of an SD card and everything works just fine until I turn on CONFIG_OMAP_MUX.
That leads to a situation where kernel can't anymore mount root file system:

I am seeing the exact same thing on my Rev C2 board, but on my Rev B5
board I do not have this problem. I had not posted yet, as I have not
had time to look into it, and I suspect I am doing something wrong.
My Rev C2 board works fine with other images.

That is sounding like mux handling changed between ES2.x and ES3.x.

It was mux handling indeed, but the cause was not in OMAP silicon revision but in GPIO delta between Beagle rev B and rev C. Rev B has MMC1_WP connected to GPIO 23 (omap ball AG9) whereas rev C has it connected to GPIO 29 (omap ball AH8) Enabling CONFIG_OMAP_MUX causes these pins to be initialised as per follows:
  arch/arm/mach-omap2/mux.c:
  MUX_CFG_34XX("AG9_3430_USB1FS_PHY_MM1_RXDM", 0x5ee,
                 OMAP34XX_MUX_MODE5 | OMAP34XX_PIN_INPUT_PULLDOWN)
  MUX_CFG_34XX("AH8_34XX_GPIO29", 0x5fa,
                 OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_INPUT)

For rev B this is okay as MMC1_WP is at ball AH8 which is set as GPIO (Mode 4), but for rev C these do not work. Furthermore this isn't an issue with kernel 2.6.27 and older as MMC host driver does not use MMC WP. However, .28 and later have this feature enabled.

So, in short: rev C && 2.6.28 && CONFIG_OMAP_MUX (set by e.g. I2C2_OMAP_BEAGLE on .28) kills MMC.

Thank you! I will look at how this impacts my setup and report back,
but it could be tomorrow before I can do that.

-Preston