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
>> (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.
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.