OpenWrt Forum Archive

Topic: mmc-over-gpio not working on wrt54gl brcm-47xx

The content of this topic has been archived on 30 Apr 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

card works nicely with recent dd-wrt v24, openwrt 8.09.1 + mmc 1.3.4 but on brcm-47xx I get (debugging enabled in kernel_menuconfig)

Is mmc over gpio officially broken on broadcom 2.6 ? Did it ever work?  ..bud

mmc_spi spi32765.0: ASSUMING 3.2-3.4 V slot power
mmc0: clock 0Hz busmode 0 powermode 0 cs 0 Vdd 0 width 0 timing 0
mmc_spi spi32765.0: SD/MMC host mmc0, no DMA, no WP, no poweroff
gpio-mmc: MMC-Card "default" attached to GPIO pins di=2, do=4, clk=3, cs=7
mmc0: clock 0Hz busmode 2 powermode 1 cs 1 Vdd 21 width 0 timing 0
mmc0: clock 400000Hz busmode 2 powermode 2 cs 1 Vdd 21 width 0 timing 0
mmc_spi spi32765.0: can't change chip-select polarity
mmc0: starting CMD0 arg 00000000 flags 000000c0
mmc0: req done (CMD0): -51: 00000000 00000000 00000000 00000000
mmc0: starting CMD8 arg 000001aa flags 000002f5
mmc0: req done (CMD8): -51: 00000000 00000000 00000000 00000000
mmc0: starting CMD5 arg 00000000 flags 000002e1
mmc0: req failed (CMD5): -51, retrying...
mmc0: req failed (CMD5): -51, retrying...
mmc0: req failed (CMD5): -51, retrying...
mmc0: req done (CMD5): -51: 00000000 00000000 00000000 00000000
mmc0: starting CMD55 arg 00000000 flags 000000f5
mmc0: req done (CMD55): -51: 00000000 00000000 00000000 00000000
mmc0: starting CMD55 arg 00000000 flags 000000f5
mmc0: req done (CMD55): -51: 00000000 00000000 00000000 00000000
mmc0: starting CMD55 arg 00000000 flags 000000f5
mmc0: req done (CMD55): -51: 00000000 00000000 00000000 00000000
mmc0: starting CMD55 arg 00000000 flags 000000f5
mmc0: req done (CMD55): -51: 00000000 00000000 00000000 00000000
mmc0: starting CMD1 arg 00000000 flags 000000e1
mmc0: req done (CMD1): -51: 00000000 00000000 00000000 00000000
mmc0: clock 0Hz busmode 2 powermode 0 cs 1 Vdd 0 width 0 timing 0

the trac ticket is here
https://dev.openwrt.org/ticket/5489

Read the other threads. It's broken and noone is interested in fixing it....

Well I am interested to have it fixed... but you are right I missed some posts, to make it easier I summarize and post link in the mentioned threads to this discussion. the status seems to be:

mb is still maintaing the driver and it shouldn't be broken
http://forum.openwrt.org/viewtopic.php?pid=90207#p90207

the b43 driver blocked mmc gpios (supposedly fixed by 06/2009, see ticket)
http://forum.openwrt.org/viewtopic.php?id=19346
http://forum.openwrt.org/viewtopic.php?id=19127
http://forum.openwrt.org/viewtopic.php?id=18203
https://dev.openwrt.org/ticket/4274

it is working on Buffalo WHR-G54S if kmod-diag is disabled, same problem as above with b43
http://forum.openwrt.org/viewtopic.php?pid=86596#p86596

thread describing problems with mmc over gpio on kernel 2.6
http://forum.openwrt.org/viewtopic.php?id=19084

I'll pm mbuesch about this thread.  ... bud

just tried rev16746 without wireless drivers .. the white led stays now off and the dmesg output additionally states a spi poweroff in the end ... bud

gpio-mmc: Failed to request mmc_spi module.
mmc_spi spi32765.0: ASSUMING 3.2-3.4 V slot power
mmc0: clock 0Hz busmode 0 powermode 0 cs 0 Vdd 0 width 0 timing 0
mmc_spi spi32765.0: SD/MMC host mmc0, no DMA, no WP, no poweroff
gpio-mmc: MMC-Card "default" attached to GPIO pins di=2, do=4, clk=3, cs=7
mmc0: clock 0Hz busmode 2 powermode 1 cs 1 Vdd 21 width 0 timing 0
mmc_spi spi32765.0: mmc_spi: power up (21)
mmc0: clock 400000Hz busmode 2 powermode 2 cs 1 Vdd 21 width 0 timing 0
mmc_spi spi32765.0: mmc_spi: power on (21)
mmc_spi spi32765.0: can't change chip-select polarity
mmc_spi spi32765.0: mmc_spi:  clock to 400000 Hz, 0
mmc0: starting CMD0 arg 00000000 flags 000000c0
mmc_spi spi32765.0:   mmc_spi: CMD0, resp R1
mmc_spi spi32765.0:   ... CMD0 response SPI_R1: INVALID RESPONSE, e0
mmc0: req done (CMD0): -51: 00000000 00000000 00000000 00000000
mmc0: starting CMD8 arg 000001aa flags 000002f5
mmc_spi spi32765.0:   mmc_spi: CMD8, resp R3/R4/R7
mmc_spi spi32765.0:   ... CMD8 response SPI_R3/R4/R: INVALID RESPONSE, e0
mmc0: req done (CMD8): -51: 00000000 00000000 00000000 00000000
mmc0: starting CMD5 arg 00000000 flags 000002e1
mmc_spi spi32765.0:   mmc_spi: CMD5, resp R3/R4/R7
mmc_spi spi32765.0:   ... CMD5 response SPI_R3/R4/R: INVALID RESPONSE, e0
mmc0: req failed (CMD5): -51, retrying...
mmc_spi spi32765.0:   mmc_spi: CMD5, resp R3/R4/R7
mmc_spi spi32765.0:   ... CMD5 response SPI_R3/R4/R: INVALID RESPONSE, e0
mmc0: req failed (CMD5): -51, retrying...
mmc_spi spi32765.0:   mmc_spi: CMD5, resp R3/R4/R7
mmc_spi spi32765.0:   ... CMD5 response SPI_R3/R4/R: INVALID RESPONSE, e0
mmc0: req failed (CMD5): -51, retrying...
mmc_spi spi32765.0:   mmc_spi: CMD5, resp R3/R4/R7
mmc_spi spi32765.0:   ... CMD5 response SPI_R3/R4/R: INVALID RESPONSE, e0
mmc0: req done (CMD5): -51: 00000000 00000000 00000000 00000000
mmc0: starting CMD55 arg 00000000 flags 000000f5
mmc_spi spi32765.0:   mmc_spi: CMD55, resp R1
mmc_spi spi32765.0:   ... CMD55 response SPI_R1: INVALID RESPONSE, e0
mmc0: req done (CMD55): -51: 00000000 00000000 00000000 00000000
mmc0: starting CMD55 arg 00000000 flags 000000f5
mmc_spi spi32765.0:   mmc_spi: CMD55, resp R1
mmc_spi spi32765.0:   ... CMD55 response SPI_R1: INVALID RESPONSE, e0
mmc0: req done (CMD55): -51: 00000000 00000000 00000000 00000000
mmc0: starting CMD55 arg 00000000 flags 000000f5
mmc_spi spi32765.0:   mmc_spi: CMD55, resp R1
mmc_spi spi32765.0:   ... CMD55 response SPI_R1: INVALID RESPONSE, e0
mmc0: req done (CMD55): -51: 00000000 00000000 00000000 00000000
mmc0: starting CMD55 arg 00000000 flags 000000f5
mmc_spi spi32765.0:   mmc_spi: CMD55, resp R1
mmc_spi spi32765.0:   ... CMD55 response SPI_R1: INVALID RESPONSE, e0
mmc0: req done (CMD55): -51: 00000000 00000000 00000000 00000000
mmc0: starting CMD1 arg 00000000 flags 000000e1
mmc_spi spi32765.0:   mmc_spi: CMD1, resp R1
mmc_spi spi32765.0:   ... CMD1 response SPI_R1: INVALID RESPONSE, e0
mmc0: req done (CMD1): -51: 00000000 00000000 00000000 00000000
mmc0: clock 0Hz busmode 2 powermode 0 cs 1 Vdd 0 width 0 timing 0
mmc_spi spi32765.0: mmc_spi: power off (0)
Dogge wrote:

Read the other threads. It's broken and noone is interested in fixing it....

It is NOT broken.
Please stop spreading that FUD, people.

I did test it recently (two or three weeks ago) and it does work PROPERLY, if you correctly set up your configuration.

Make sure that the GPIO config is correct.
Make sure that a GPIO is only used ONCE. (Make sure that other apps/modules do not use the GPIO)

To say it again. It does work. There's nothing to fix. Saying that "noone is interested in fixing it" is plain _wrong_ because it does work.

thx michael for answering. Still the gpio's are fine, it works with kernel 2.4 ...

I also disabled kmod-diag and disabled wireless modules just for the sake of testing... see 2 posts above ..
Does the 'mmc_spi spi32765.0:   ... CMD55 response SPI_R1: INVALID RESPONSE, e0'  mean anything to you?

... bud
'

bud wrote:

thx michael for answering. Still the gpio's are fine, it works with kernel 2.4 ...

I also disabled kmod-diag and disabled wireless modules just for the sake of testing... see 2 posts above ..
Does the 'mmc_spi spi32765.0:   ... CMD55 response SPI_R1: INVALID RESPONSE, e0'  mean anything to you?

... bud
'

This is not an error from any subsystem that I maintain. It's an error from the generic mmc-spi subsystem. If you think it's a bug in that subsystem, please contact its maintainer.

Hi,

I confirm also that gpiommc module can't work correctly if wireless is enabled.
If I disabled wireless, and reboot my WRT54GL router, SD Card reader worked fine.

I had the same problem if diag module installed.
I am using kernel 2.6.28

Here is the following partitions on my SD Card 2Go.
cat /proc/partitions
major minor  #blocks  name

  31        0        256 mtdblock0
  31        1       3776 mtdblock1
  31        2       3009 mtdblock2
  31        3       1600 mtdblock3
  31        4         64 mtdblock4
179        0    1921024 mmcblk0
179        1     501084 mmcblk0p1
179        2          1 mmcblk0p2
179        5     501084 mmcblk0p5
179        6     917104 mmcblk0p6


Phil

(Last edited by pisorce on 4 Sep 2009, 08:37)

Phil writes :
In the following system log you can see SD Card 2GB is enabled.
But When I enable wireless AP, mounted partitions are disabled.

-------------------------------------------------------------
mmc_spi spi32766.0: can't change chip-select polarity
mmc0: host does not support reading read-only switch. assuming write-enable.
mmc0: new SD card on SPI
mmcblk0: mmc0:0000 SD02G 1.83 GiB
mmcblk0: p1 p2 < p5 p6 >
EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended
attempt to access beyond end of device
mmcblk0p2: rw=0, want=4, limit=2
EXT2-fs: unable to read superblock
attempt to access beyond end of device
mmcblk0p2: rw=0, want=4, limit=2
EXT3-fs: unable to read superblock
EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended
EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended
br-lan: port 1(eth0.0) entering disabled state
device eth0 left promiscuous mode
device eth0.0 left promiscuous mode
br-lan: port 1(eth0.0) entering disabled state
device eth0.0 entered promiscuous mode
device eth0 entered promiscuous mode
br-lan: topology change detected, propagating
br-lan: port 1(eth0.0) entering forwarding state
br-lan: port 1(eth0.0) entering disabled state
br-lan: topology change detected, propagating
br-lan: port 1(eth0.0) entering forwarding state
input: b43-phy0 as /devices/virtual/input/input0
b43 ssb0:3: firmware: requesting b43/ucode5.fw
b43 ssb0:3: firmware: requesting b43/pcm5.fw
b43 ssb0:3: firmware: requesting b43/b0g0initvals5.fw
b43 ssb0:3: firmware: requesting b43/b0g0bsinitvals5.fw
b43-phy0: Loading firmware version 410.2160 (2007-05-26 15:32:10)
Registered led device: b43-phy0::tx
Registered led device: b43-phy0::rx
Registered led device: b43-phy0::radio
b43-phy0: Radio turned on by software
device wlan0 entered promiscuous mode
wlan0: deauthenticating by local choice (reason=3)
br-lan: port 2(wlan0) entering disabled state
input: b43-phy0 as /devices/virtual/input/input1
b43-phy0: Loading firmware version 410.2160 (2007-05-26 15:32:10)
Registered led device: b43-phy0::tx
Registered led device: b43-phy0::rx
Registered led device: b43-phy0::radio
br-lan: topology change detected, propagating
br-lan: port 2(wlan0) entering forwarding state
mmcblk0: error -145 sending read/write command
end_request: I/O error, dev mmcblk0, sector 1092
mmcblk0: error -145 sending read/write command
end_request: I/O error, dev mmcblk0, sector 1092
mmcblk0: error -145 sending read/write command
end_request: I/O error, dev mmcblk0, sector 64
Buffer I/O error on device mmcblk0p1, logical block 1
lost page write due to I/O error on mmcblk0p1
EXT2-fs error (device mmcblk0p1): ext2_readdir: bad page in #2
root@OpenWrt:~#

If I disable wireless AP SD Card becomes enabled.
See system log

br-lan: port 2(wlan0) entering disabled state
br-lan: port 1(eth0.0) entering disabled state
device eth0 left promiscuous mode
device wlan0 left promiscuous mode
br-lan: port 2(wlan0) entering disabled state
device eth0.0 left promiscuous mode
br-lan: port 1(eth0.0) entering disabled state
device eth0.0 entered promiscuous mode
device eth0 entered promiscuous mode
br-lan: topology change detected, propagating
br-lan: port 1(eth0.0) entering forwarding state
device wlan0 entered promiscuous mode
br-lan: topology change detected, propagating
br-lan: port 2(wlan0) entering forwarding state
br-lan: port 2(wlan0) entering disabled state
br-lan: port 1(eth0.0) entering disabled state
br-lan: topology change detected, propagating
br-lan: port 2(wlan0) entering forwarding state
br-lan: topology change detected, propagating
br-lan: port 1(eth0.0) entering forwarding state
br-lan: port 2(wlan0) entering disabled state
root@OpenWrt:~# df -k
Filesystem           1k-blocks      Used Available Use% Mounted on
rootfs                    1408      1408         0 100% /
/dev/root                 1408      1408         0 100% /rom
tmpfs                     6860      1128      5732  16% /tmp
tmpfs                      512         0       512   0% /dev
/dev/mtdblock3            1600      1328       272  83% /jffs
mini_fo:/jffs             1408      1408         0 100% /
/dev/mmcblk0p1          485246     45246    414946  10% /mnt/mmcblk0p1
/dev/mmcblk0p5          485246      2318    457874   1% /mnt/mmcblk0p5
/dev/mmcblk0p6          902680       904    855924   0% /mnt/mmcblk0p6
root@OpenWrt:~#

I didn't need to reboot my router. SD Card and all partions became available.

Phil

(Last edited by pisorce on 4 Sep 2009, 09:16)

interesting .. never switched on wireless during testing I've done

.. eventually it seemed to be an incompatibility of a no name card (which runs under kernel 2.4 flawlessly) with the mmc driver for kernel 2.6

2 newly purchased sandisk cards are working, slowly but at least .. working at all

I will doublecheck your findings with wlan on my sdmodded wrt54gl

which gpio's do you use?

... bud

(Last edited by bud on 7 Sep 2009, 09:30)

Yes, it's true, as soon the b43 wireless driver is upped it fiddles with the LEDs/GPIO and effectively inhibits kmod-mmc-over-gpio.

The kmod-b43 driver puts quite a bunch of GPIO lines under its control in its init, so it's quite unlikely that you'll find sufficient GPIO pins unaffected by it to get it to successfully drive your SD/MMC. I'm using pins 2, 3, 4 and 7 here on my WRT54GL.

So what I am doing is taking the current trunk and patching the b43 to stop controlling any GPIO pins except #0 and #1 (Power and WLAN LEDs), which don't affect my card. This works fine and I can use wireless and my card simultaneously.

But there are still other minor and major issues.

One of them is being unable to access the last 8 * 512byte blocks (the last 4k page) of my card. Trying to do so (reading or writing) renders the card unusable for all following accesses until I disable/reenable the card (or reboot).

The other one is being unable to reliably execute programs directly from the card. It's not about data integrity, which is fine and easily verified by diffing (with a diff executable not located on the card *g*). Since i'm not really into how things work in the linux kernel, let alone executing stuff, I can only guess. Maybe it's got something to do with mmaps not working properly? Since I get all kind of strange errors from bus errors to segfaults and which usually go away when trying to execute the program a second time or so (maybe due to the text being served from the buffer cache).

Unfortunately I don't understand this whole mmc infrastructure and neither do I understand what causes the problems in connection with program execution, so I was unable to hunt down the problems any further.


Regards,
Niels Böhm

blubberdiblub wrote:

Yes, it's true, as soon the b43 wireless driver is upped it fiddles with the LEDs/GPIO and effectively inhibits kmod-mmc-over-gpio.

The kmod-b43 driver puts quite a bunch of GPIO lines under its control in its init, so it's quite unlikely that you'll find sufficient GPIO pins unaffected by it to get it to successfully drive your SD/MMC. I'm using pins 2, 3, 4 and 7 here on my WRT54GL.

So what I am doing is taking the current trunk and patching the b43 to stop controlling any GPIO pins except #0 and #1 (Power and WLAN LEDs), which don't affect my card. This works fine and I can use wireless and my card simultaneously.

Nice, could you post the patch? maybe they could make a patched b43 package to download from the openwrt repository too.

ok i did it, we just need to apply this diff reversed: https://dev.openwrt.org/attachment/tick … ain.c.diff
so, we need 0x1 instead of 0xF in these 2 places changed

I had trouble with the compiled module b43, i tried pretty much every combination except trunk (backfire tag, backfire branch, just b43, all of mac80211 recompiled, backfire tag hostapd, branch hostapd), and they always crashed b43 or hostapd. Go figure... SO, what i did was patch the binary module (i disassembled it and patched the two 0F->01). If you want to do it yourselves on backfire 10.03 b43.ko, offset 5150: 0F->01 and offet 5A6C: 0F->01. Just these 2 bytes and i finally could use mmc and b43 at the same time without any problem whatsoever.

naplam wrote:

ok i did it, we just need to apply this diff reversed: https://dev.openwrt.org/attachment/tick … ain.c.diff
so, we need 0x1 instead of 0xF in these 2 places changed

I had trouble with the compiled module b43, i tried pretty much every combination except trunk (backfire tag, backfire branch, just b43, all of mac80211 recompiled, backfire tag hostapd, branch hostapd), and they always crashed b43 or hostapd. Go figure... SO, what i did was patch the binary module (i disassembled it and patched the two 0F->01). If you want to do it yourselves on backfire 10.03 b43.ko, offset 5150: 0F->01 and offet 5A6C: 0F->01. Just these 2 bytes and i finally could use mmc and b43 at the same time without any problem whatsoever.

Hi naplam,
Can you explain how you do this? Thanks in advice. I

hmm.. what exactly? edit a file with a hex editor?

naplam wrote:

hmm.. what exactly? edit a file with a hex editor?

The problem is i can't find the file. Do i have to build it and then compile it? please tell me where to find it. Im using backfire kernel 2.6.32.10 #20

gpio-mmc: Failed to request mmc_spi module.
mmc_spi spi32766.0: ASSUMING 3.2-3.4 V slot power
mmc_spi spi32766.0: SD/MMC host mmc0, no DMA, no WP, no poweroff
gpio-mmc: MMC-Card "mmc" attached to GPIO pins di=2, do=4, clk=3, cs=7
mmc_spi spi32766.0: can't change chip-select polarity

I get this when wifi activated as discussed before

(Last edited by elvisrv on 23 Jun 2010, 16:02)

make sure it works with wifi down.
b43.ko is in the directory where all kernel modules are: /lib/modules/[kernel version]

naplam wrote:

make sure it works with wifi down.
b43.ko is in the directory where all kernel modules are: /lib/modules/[kernel version]

Yes, If i disable wifi it works perfect. No luck when i activated so far. I already found the b43.ko So i opened b43.ko in ghex2 but, i still dont get it. where am i supposed to change the bites? Sorry to ask alot? i'm new to openwrt.

Thanks in advice

elvisrv wrote:
naplam wrote:

make sure it works with wifi down.
b43.ko is in the directory where all kernel modules are: /lib/modules/[kernel version]

Yes, If i disable wifi it works perfect. No luck when i activated so far. I already found the b43.ko So i opened b43.ko in ghex2 but, i still dont get it. where am i supposed to change the bites? Sorry to ask alot? i'm new to openwrt.

Thanks in advice

Hi,
My offset 5150 was: 21 and 5A6C: 0F, although I changed them. Now i have offset 5150: 01 and offset 5A6C: 01
I get these errors

gpio-mmc: GPIO based MMC-Card "mmc" removed
gpio-mmc: Failed to request mmc_spi module.
mmc_spi spi32765.0: ASSUMING 3.2-3.4 V slot power
mmc_spi spi32765.0: SD/MMC host mmc0, no DMA, no WP, no poweroff
gpio-mmc: MMC-Card "mmc" attached to GPIO pins di=2, do=4, clk=3, cs=7
mmc_spi spi32765.0: can't change chip-select polarity
mmc0: card claims to support voltages below the defined range. These will be ignored.
mmc0: unrecognised CSD structure version 0
mmc0: error -22 whilst initialising MMC card

Can you send me your b43.ko to simplify things? elvisrv@gmail.com
Thanks in advice

(Last edited by elvisrv on 24 Jun 2010, 17:21)

naplam wrote:

ok i did it, we just need to apply this diff reversed: https://dev.openwrt.org/attachment/tick … ain.c.diff
so, we need 0x1 instead of 0xF in these 2 places changed

I had trouble with the compiled module b43, i tried pretty much every combination except trunk (backfire tag, backfire branch, just b43, all of mac80211 recompiled, backfire tag hostapd, branch hostapd), and they always crashed b43 or hostapd. Go figure... SO, what i did was patch the binary module (i disassembled it and patched the two 0F->01). If you want to do it yourselves on backfire 10.03 b43.ko, offset 5150: 0F->01 and offet 5A6C: 0F->01. Just these 2 bytes and i finally could use mmc and b43 at the same time without any problem whatsoever.

Naplam,
I am using backfire-10.03.1-rc4 on a WRT54G (v3.1). The offsets 5150 & 5A6C did not have the values you mentioned, I still went ahead and changed them to 01 but the router crashed on bootup. It was quite obvious since the source file might have changed from the version you used and the one I am using. Anyway, I could not find the actual b43 source file. It would be a great help if you pointed out the location of the b43 source file (in backfire) and explain in brief as to how I can compile this file alone to get the b43.ko file.

I have a doubt, how is b43.ko different from b43legacy.ko?

good

in 10.03.1-rc4 edit /etc/modules.d/30-b43 and replace 'b43' with 'b43 gpiomask=0x1' to disable the usage of gpios by b43

i still get the gpio-mmc warnings.. but at least i am able to mount the sd-card this way with wireless active

(Last edited by tsod on 24 Dec 2010, 00:28)

blubberdiblub wrote:

...
The other one is being unable to reliably execute programs directly from the card. It's not about data integrity, which is fine and easily verified by diffing (with a diff executable not located on the card *g*). Since i'm not really into how things work in the linux kernel, let alone executing stuff, I can only guess. Maybe it's got something to do with mmaps not working properly? Since I get all kind of strange errors from bus errors to segfaults and which usually go away when trying to execute the program a second time or so (maybe due to the text being served from the buffer cache).
...

Looks like this is still in issue (backfire 24999 built from source)

The discussion might have continued from here.