Kernel configuration issue (CONFIG_OMAP_MUX)

201 views
Skip to first unread message

Antti Seppanen

unread,
Apr 19, 2009, 5:09:19 PM4/19/09
to Beagle Board
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 Seppänen | PGP public key:
antti (á) hervanta.com | http://www.hervanta.com/~antti
OH3HMI
GSM +358-40-7540919

Preston Wilson

unread,
Apr 19, 2009, 5:36:29 PM4/19/09
to Beagle Board
"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

Antti Seppanen

unread,
Apr 20, 2009, 2:49:22 AM4/20/09
to Beagle Board
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.

Koen Kooi

unread,
Apr 20, 2009, 3:11:06 AM4/20/09
to beagl...@googlegroups.com

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

regards,

Koen

PGP.sig

Antti Seppanen

unread,
Apr 20, 2009, 1:13:02 PM4/20/09
to beagl...@googlegroups.com

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.

Preston Wilson

unread,
Apr 20, 2009, 1:52:36 PM4/20/09
to Beagle Board
On Apr 20, 1:13 pm, Antti Seppanen <an...@hervanta.com> wrote:

> > 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
Reply all
Reply to author
Forward
0 new messages