Modify

Opened 8 years ago

Closed 8 years ago

Last modified 3 years ago

#6343 closed enhancement (fixed)

new broadcom-sdhc package

Reported by: bud.dhay@… Owned by: developers
Priority: normal Milestone: Barrier Breaker 14.07
Component: packages Version: Trunk
Keywords: sd sdmod sdhc mmc driver broadcom Cc:

Description

As announced on the devel mailing list here is the packaged/enhanced version of the sd, sdhc, mmc card driver for 2.4 kernels on broadcom.

This driver was developed by Chris Krusch. See
http://4mul8.ca/openwrt/
It is based on the optimized mmc.o version 1.3.5 from the forum.

It is even faster and adds support for sdhc cards. Also it has now a overlay_root option in the init script.

Therefore the old outdated broadcom-mmc package should be removed when including this package in trunk.

Patch attached. Thanks bud

Attachments (2)

broadcom-sdhc-package.patch (94.4 KB) - added by bud.dhay@… 8 years ago.
the broadcom-sdhc package
README.txt (5.8 KB) - added by anonymous 8 years ago.

Download all attachments as: .zip

Change History (21)

Changed 8 years ago by bud.dhay@…

the broadcom-sdhc package

comment:1 Changed 8 years ago by anonymous

LOL...

Get a router with USB if you need extra storage...

comment:2 Changed 8 years ago by spoil@…

I'd advocate adding it. It's extremely valuable.

But, as a matter of fact, the version that's available has two bugs in itself:

A) the sdcard.conf-file needs to be chmodded to 700, else you'll debug forever why it doesn't source it
B) the current implementation of /etc/init.d/sdcard does not work with dbg=0 (small bug in the eval of the start()call).

comment:3 Changed 8 years ago by bud.dhay@…

regarding A

the package installs /etc/sdcard.conf with mask 755

regarding B

this has been fixed in this package .. it's therefor and for other changes version 2.0.2 instead of 2.0.1 which is available on http://4mul8.ca/openwrt/ .

I'll attach the Readme.txt containing the Change Log.

.. bud

Changed 8 years ago by anonymous

comment:4 Changed 8 years ago by bud.dhay@…

Statement A above is wrong of course. The package installs /etc/sdcard.conf with mask 644 as it should be ..

merry xmas .. bud

comment:5 follow-up: Changed 8 years ago by jow

  • Resolution set to fixed
  • Status changed from new to closed

broadcom-sdhc added in r19172, broadcom-mmc removed in r19173.

comment:6 in reply to: ↑ 5 Changed 8 years ago by Tony Butler <spudz76@…>

Crashes on my BCM4702 platform (RT210W) which uses GPIOs 0/1/3/6, but worked with specially modified old mmc driver 1.3.5. The platform itself is similar to the original WRT54Gv1 with MiniPCI card, just the usable GPIOs are different. I tried it just with configure and go (same crash) and also setting the gpiomask to 0x004B first (like with the old mmc driver). After attempted load the gpiomask gets reset back to 0x0000. Perhaps I need to remove the repurposed GPIO entries from diag so it doesn't know they used to be LEDs and such?

The kernel spits this out, in case it is useful:
<code>
[INF] sdhc: Version: 2.0.2 Parms: major=0 din=3 dout=1 clk=6 cs=0 maxsec=32 rahead=2 dbg=001f
Data bus error, epc == c00ca720, ra == c00ca6cc
Oops in traps.c::do_be, line 385:
$0 : 00000000 1000fc00 00000000 00000002 00000001 00000008 00000040 00000001
$8 : c00d0000 c00d0000 c00d0000 c00d0000 b800006c 801a0000 801a0000 ffffffff
$16: c00d0000 c00d0000 c00d0000 c00d0000 80010000 80ade780 c00d0000 004b8d48
$24: 00000001 00000001 80a78000 80a79e40 c00d0000 c00ca6cc
Hi : ffffdfcc
Lo : 00000abc
epc : c00ca720 Not tainted
Status: 1000fc03
Cause : 0000001c
PrId : 00024000
Process insmod (pid: 358, stackpage=80a78000)
Stack: 000ce000 00000000 00000003 00000001 00000006 00000000 00000020

00000002 0000001f 80ade780 00000005 c00c6000 004be898 ffffffea 00000060
80ade780 80aba000 004b8d48 00000005 80014a48 fffffffe 000001f2 000007df
00000002 00000060 c00c0000 c00c6060 00005d90 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 ...

Call Trace: [<80014a48>] [<c00c6060>] [<80008aa0>] [<8005bd3c>]

Code: a163bd41 a126bd43 a047bd42 <91820000> 00a62825 00852025 00641827 00621824 a1830000
</code>

I will attempt to answer some of my own questions with further research and testing, and may post some patches if I figure it out. Let me know if I should just open a new ticket for this, I figured adding to this one was probably more organized and if this is appropriate then someone else can reopen it (I'll leave it closed).

comment:7 Changed 8 years ago by Tony Butler <spudz76@…>

OK, removed the LEDs from diag, no help.

I reviewed how I had changed the old mmc driver to make it work on this platform and discovered I replaced every direct register call with the appropriate sb_gpio*() calls. I seem to recall having the same sort of problems with the original driver as well, until I made it bit-bang the GPIO lines via the standard board support system calls rather than directly via registers. For some reason manually touching the registers makes this board freak out - not sure yet if it is due to the registers being in different places and the sb_gpio*() calls just map it properly, or what, but I will check that out as I go along.

I will try to implement the same updates to this driver and see if that fixes it up, and then others can test to ensure it works on newer cores as well. I may just add a config option for "noregs" to switch between GPIO access modes as it might be smarter until we know the "noregs" mode works on all boards equally as well as the direct register mode. If I find that the sb_gpio*() calls do automatically remap the registers on all boards, then it probably makes sense to just use them and drop the manual register settings from the config file (since they can be dangerous anyway).

comment:8 Changed 8 years ago by bud.dhay@…

I actually don't have no knowledge of the gpio internals you're talking about.

Can you explain the difference in a bit more detail? Would there be dangers to the devices of testers? Nobody want's to turn their handicraft turned to paperweight.

I am gonna try to reach the two people that I know did work on mmc modules. Maybe they can contribute, if only in writing.

Maybe you should start a new ticket with a proper subject on this?

thanks bud

comment:9 Changed 8 years ago by Tony Butler <spudz76@…>

The original work about this 4702 (WRT54G v1) problem and the patches I based my modifications on were provided originally by "jnjn" in this thread beginning with this post:
https://forum.openwrt.org/viewtopic.php?pid=45042#p45042

comment:10 Changed 8 years ago by bud.dhay@…

Interesting read. Thanks for pointing me.

I understand 2 things.
a) the use of sb_gpio* is slower
b) sb_gpio is part of the closed source broadcom binaries?

Is there any way to try one way and switch to the other if the first fails?

bud

comment:11 Changed 8 years ago by Tony Butler <spudz76@…>

Considering the access to the (incorrect) register addresses directly causes a segfault and crashes the module while it's still in "initializing" state and leaves the stub half registered until reboot, and the sb_gpio*() method would be successful on all boards, there isn't much of a way to do any failover. There may be ways to decide which method to use based on /proc/cpuinfo or nvram contents ('boardtype' and friends).

In that thread, I also found the 4702 core allegedly has the registers at +0x7000 offset from the defaults. I tried these and it no longer segfaults but it still doesn't successfully init the card - same result as with the 1.3.5 optimized mmc driver.

The sb_gpio*() calls may be slower, but this is also because it arbitrates between multiple processes which may want to change GPIOs at the same time. Example, you are feverishly accessing the sdhc while some other process uses /proc/diag/led/power or such to flip the LED state - there is a possibility of them touching the registers simultaneously, if they both used direct register access, and then what would happen? Also, "slower" may not actually amount to much - I have no results as to the speed difference, but I was pretty happy getting ~300KB/s transfers on a 125MHz core using the sb_gpio*() calls. I would like to see the actual difference on a router that can do both.

So, what I am currently doing is adding a gpio.c file to your package which will further abstract the GPIO access within spi.c and etc, and allow easy selection of which mode to use via module parms. Once I have it set up to work properly on my old board with the sb_gpio calls, then I'll submit the patch and you can try it on your WRT54GL where original tests were conducted and test speeds of both modes.

comment:12 Changed 8 years ago by bud.dhay@…

Sounds good to me. Please add a dmesg/kernel print output that clearly states what access mode it is in. Just to be sure later in the tests.

And again... Is this part of the binary proprietary broadcom code?
Just out of interest, because I have the loose suspicion that that the kernel 2.6 gpio mmc module's instability might be rooted in other processes accessing gpios. If it's closed it would be obviously no option for mmc-gpio.

thx bud

comment:13 Changed 8 years ago by Chris.Krusch@…

The SDHC driver has an option to override the address of the GPIO registers
because I assumed different versions of routers might locate the GPIO
registers in different locations. I¹ve never tested it as I only have a
WRT54GL. Looks like in the posting someone has tried with the correct GPIO
addresses for WRT54G version 1.1 with no luck (gets rid of the exception but
still doesn¹t work correctly)...

The goal of using GPIO directly was to optimize speed but does make it less
compatible with different broadcom chipsets.... This code uses direct access
to the GPIO registers in exactly the same way that the 1.3.5 driver did
(being based on it).

Not a bad idea to have a slower, but more compatible mode that uses the
sb_gpio calls... The i2c openwrt stuff uses it :
http://nuwiki.openwrt.org/oldwiki/OpenWrtDocs/Customizing/Hardware/I2C_RTC .
I haven¹t looked at how the mmc over gpio stuff works in the 2.6 kernel...

...Chris

comment:14 Changed 8 years ago by bud.dhay@…

Would using sb_gpio calls mean that the access to the gpios is moderated again and the user might use the ses button again?

On the common wrt54gl sdmod the ses button gpio line is wired to the sdcard. Right now pushing the button kills the sdcard module.

bud

comment:15 Changed 8 years ago by bud.dhay@…

arrrgh .. jow checked in the wrong version. Please do not use the version in trunk right now, but the patch above. I will post when the correct version is in trunk.

bud

comment:16 Changed 8 years ago by Tony Butler <spudz76@…>

Regarding the SES button, I don't think the sb_gpio calls allow for moderated access quite that way, you can't register multiple uses for each GPIO. In order for that to work you'd need to flip the GPIO back to normal use whenever the card was not being accessed, but still if you happened to use the button while the card was in use it would screw up, there is no way to buffer/multiplex. Which signal is the SES button GPIO being used for on that board? Still as input (DI)?

comment:17 Changed 8 years ago by bud.dhay@…

sorry for the confusion, actually i modified 2.0.1 into 2.0.2 ..
obviously the original author also released an updated version in
between. i was in contact with chris krusch and understood he would like it in
buildroot but wouldn't have the time to bugfix and integrate and that he
would like me to do it.

i will clear matters up with him and report back. the package right now
will work but lacks the root overlay feature i added.

comment:18 Changed 8 years ago by bud.dhay@…

SES button. I honestly don't know. I got the device modded and it is done like this

http://www.darkhaven.org/mediawiki/index.php/WRT54G-TM_MMC/SD_Mod#GPIO_Solder_Points

.. also i can tell that when i once when testing wrote on the sdcard and pushed the button, just out of curiosity, i oopsed the kernel.

thanks for explaining, bud

comment:19 Changed 3 years ago by jow

  • Milestone changed from Attitude Adjustment 12.09 to Barrier Breaker 14.07

Milestone Attitude Adjustment 12.09 deleted

Add Comment

Modify Ticket

Action
as closed .
The resolution will be deleted. Next status will be 'reopened'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.