BB-xM: CONFIG_OMAP_MUX causes kernel panic (unable to mount root fs)

Hello all,
I am trying to get SPI working on a BeaggleBoard XM.
I have downloaded the OE tree and enabled CONFIG_OMAP_MUX in the
beagleboard defconfig (kernel psp-2.6.32), but this causes a kernel
panic during boot:

[ 31.247039] mmc0: new high speed SDHC card at address e624
[ 31.252868] mmcblk0: mmc0:e624 SU04G 3.69 GiB (ro)
[ 31.257965] mmcblk0: p1 p2
[ 31.309631] VFS: Cannot open root device "mmcblk0p2" or
[ 31.316711] Please append a correct "root=" boot option; here are the
available partitions:
[ 31.325164] 1f00 512 mtdblock0 (driver?)
[ 31.330169] 1f01 1920 mtdblock1 (driver?)
[ 31.335174] 1f02 128 mtdblock2 (driver?)
[ 31.340179] 1f03 4096 mtdblock3 (driver?)
[ 31.345214] 1f04 255488 mtdblock4 (driver?)
[ 31.350219] b300 3872256 mmcblk0 driver: mmcblk
[ 31.355499] b301 72261 mmcblk0p1
[ 31.359802] b302 3799372 mmcblk0p2
[ 31.364135] Kernel panic - not syncing: VFS: Unable to mount root fs
on unknown-block(179,2)

I have tried removing all camera patches from the BB recipe but the
problem remains. The same kernel boots fine on a regular (non XM)
I suspect this is caused by the kernel incorrectly changing the muxxing
of some pins related to MMC1, but without any luck so far.

It seems that there are some ball differences between OMAP3530 and
DM3730 that affect MMC1, however I haven;t been able to pinpoint the
problem yet.
I have found out that DM3730 in beagleboard XM is CBP package, while OE
is configured for CBB which is the package of the OMAP3530 used.
However, I am not sure this is the cause of the problem.

So far I have been trying with linux-omap-psp-2.6.32-r95, I just checked out r97 and will give it a shot.

I am trying to hunt down all the places where the ball muxing is set in
the kernel but haven't found a solution yet.

Has anyone managed to build a working kernel (using OE) with

Thanks a lot

Don't do that, muxing is broken in the kernel, set the mux in uboot instead


For beagle board all the pin configurations are done in u-boot. It uses GPIO 171/172 & 173 to read the board ID and based on that it configures the OMAP pins for different functions.


OK, I will try the U-boot method, though it is strange that most SPI patches around and the Pinmux guide in the wiki present kernel muxing as a viable option.

Is this the case for XM only or for non-XM too?