[Yasha]

This in particular is for the WHR-HP-G54. I have done the mod, however, the wiki doesn't list the actual functions of the GPIO's outside of the Input/Output, and the GPIO's don't/can't match up exactly to the G/GS mod. So, I'm hoping that the module can be edited by some means to conform to the pins I've done.

~ # nvram show | grep gpio
reset_gpio=7
gpio1=ses_led
wl0gpio0=0
wl0gpio1=0
wl0gpio2=2
wl0gpio3=0
size: 21052 bytes (11716 left)
gpio14=ses_button

What I have assigned using the gpio utility and verifying with a multimeter:
DI=GPIO6:AOSS LED
DO=GPIO5:bridge switch
CS=GPIO7:DIAG LED
CLK=GPIO3:next to extra LED slot
n/a=GPIO1:Bridge LED

Deviation from G/GS mods:
GPIO7==OUTPUT
GPIO5==OUTPUT**Substituted for GPIO6 as GPIO5 is input on WHR-HP-G54
GPIO3==OUTPUT
GPIO4==INPUT**Substituted for GPIO5 as this is the reset button functionality.
--------------------------------------------------------------------------------------------------
As the drivers/modules are included, and the FS is squashFS is my ONLY recourse to build the firmware myself with an altered mmc.o? Ideas, suggestions, volunteer to build it(as linux and I are still barely on speaking terms)?

[Yasha]

No one? *shoots at a cricket chirping*

[Yasha]

The GPIO's are listed at http://www.dd-wrt.com/wiki/index.php/WHR-HP-G54, but I am unclear on how to proceed.

Doesn't the GPIO have to corraspond on an input to output basis? DI=Data In, so it should HAVE to be on an designated output on the router, correct? IF this is so, then I can't hook up the connections the same as a G/GS linksys model, right? Given that, that means I have to build, or have built a custom mmc driver, yes?

Anyone?

[Cricri]

I've gopt no idea what you are talking about. Is that something cool that I could do to my WHR-G54S as well?

[Yasha]

[Cricri]

Checking the wiki now, sounds good. Thanks!

[Yasha]

I refuse to give up on this, somebody's gotta know...

[JohnnyPrimus]

i can compile mmc.o for you, i may not be able to get to it tonight, but the source modifications should be pretty trivial.

[Yasha]

[JohnnyPrimus]

Referring to http://support.warwick.net/~ryan/wrt54g-v4/v4_sd_done.html I am under the impression that the functionality of a certain GPIO port can indeed be defined in the MMC.O module. I'm not an expert on GPIO, so don't quote me, but I believe each GPIO pin can be used for either input or output, as defined in the kernel driver that is using it, thus modifying the defines in the mmc as below ought to run your sd card.

Can anyone verify? I'd think that compiling the module and adding it to your firmware via the firmware mod utility would be fairly safe (it was on mine, despite errors in my initial defines), but I'd hate to blow up your house or something :D

#define SD_DI (1 << 6)
#define SD_DO (1 << 5)
#define SD_CLK (1 << 3)
#define SD_CS (1 << 7)

[Yasha]

Trying to avoid re-find gpio's and the like I FINALLY got mmc.c to build on my ubuntu VM install. That said, it still doesn't work.

Here's what I changed, this is all I need to do from the one listed at http://kiel.kool.dk/mmc.c , right?:
#define SD_DI 0x40
#define SD_DO 0x20
#define SD_CLK 0x08
#define SD_CS 0x80

given that the above matches with this:
DI=GPIO6:AOSS LED
DO=GPIO5:bridge switch
CLK=GPIO3:next to extra LED slot
CS=GPIO7:DIAG LED

I thought I could just use the straightup hex values, am I wrong?

EDIT: Bleh, did it both ways, no joy...
<4>mmc Hardware init
<4>mmc Card init
<4>mmc Card init
<4>mmc: error in mmc_card_init (1)
<4>mmc: error in mmc_init (-1)

[Yasha]

It is however compiling with warnings, which "seem" significant, perhaps it's simply not compiling correctly?:

yasha@laptopvm:~/mmcdriver$ make
/home/yasha/whiterussian/openwrt/staging_dir_mipsel/bin/mipsel-linux-uclibc-gcc -O2 -DMODULE -D__KERNEL__ -W -Wall -Wstrict-prototypes -Wmissing-prototypes -fno-strict-aliasing -mips32 -isystem /home/yasha/whiterussian/openwrt/toolchain_build_mipsel/linux-2.4.30/include -fno-pic -mno-abicalls -mlong-calls -c -o mmc.o mmc.c
mmc.c: In function `mmc_open':
mmc.c:278: warning: unused variable `device'
mmc.c: At top level:
mmc.c:324: warning: unused parameter 'filp'
/home/yasha/whiterussian/openwrt/toolchain_build_mipsel/linux-2.4.30/include/asm/uaccess.h:130: warning: unused parameter 'type'
mmc.c:276: warning: unused parameter 'inode'
mmc.c:49: warning: 'gpioaddr_control' defined but not used
mmc.c:517: warning: 'mmc_check_media_change' defined but not used

[llowrey]

I am running into the same issue with my WHR-G54S. GPIO4 is the reset and not at all compatible with the stock mmc module.

I have not yet soldered any wires but I can help you test the module you built using my oscilloscope. I can at least verify that the right GPIOs are toggling. I'll probably get to wiring things up in a few days.

Your compiler warnings are not important, as far as I can tell. The code you changed to redefine the GPIOs looks correct to me. Can you send me the mmc.o file to test?

[JohnnyPrimus]

The mmc.c included with DD-WRT v23 SP1 and later includes some changes that may prevent the version you're compiling from working.

Here is the version from 23 sp2 source tree. I modified it such that it should work for wrt v1, wrt v4, and your buffalo setup.

type dmesg after booting to check that everything went well, it shoud look something like this:

<0>mmc: Device does not use v1 GPIO layout, trying to use v4 GPIO layout
<0>mmc: Device does not use v4 GPIO layout, trying to use Buffalo GPIO layout
<0>Size = 500224, hardsectsize = 512, sectors = 1000448
<6>Partition check:
<6> mmca: p1


to compile (you probably already know this), stick mmc.c from this archive in ~/DD-WRT/src/router/mmc, then:
cd ~/DD-WRT/src/router
make mmc

and mmc.o should compile.

The binary mmc.o is also included if you'd rather skip the compilation.

http://www.partners.biz/dd-wrt/mmc-buffalo.tar

-JP

[Yasha]

For some reason I couldn't get to here last night, think it was my lovely ISP's DNS servers here. Anyhow, yeah, it seems to work just fine, I went ahead and replaced the working mmc.o on my other router with one I built, worked fine. But I'll try yours Jonnyprimus when I get home just to double-check, I'm fairly sure I hooked it up right, but it may just not that it doesn't like those GPIO's.