Agreed, and basically what I was trying to say, you worded it more concisely.
My effort to make broadcom-mmc work on my board included using some flavor of the 1.3.5 version, plus some further modifications which I did so long ago I don't remember what I had to change. I will be impressed if I don't have to recreate a few of the changes to get this to work, which is why I said my board is a good "fringe case" for testing. It is the same Askey OEM board as used in the old Siemens SE505v1. I have not tried the DD-WRT MMC support to see if it works, as I don't want to run DD-WRT anyway - it's just the only thing that would boot at the moment. On old boards like mine there is no USB core in the SoC, while some boards have enough accessible/reusable GPIO points but no USB traced out to the board even when it is available in the SoC, so this SDHC driver can still be useful and should never be completely deprecated. Obviously the end user would prefer to use USB if it were relatively easy to do so, even purely based on throughput. My old router is 125MHz so the MMC throughput is rather horrible, and it used to take a good 5-10 minutes to completely boot with the MMC overlay, but once it was running it wasn't so bad. Admittedly even a CIFS or NFS overlay would be faster, but I was aiming for a self-sufficient setup more importantly over speed. Without any USB option, MMC was and will continue to be the only way to relatively easily expand the available space while not relying on network resources (CIFS/NFS/etc). The CFE is braindead as is (TFTP only accepts 2MB max, even though flash is 4MB, so you have to "monkeybars" with a tiny recovery image and then use mtd to flash the final larger one), and trying to reflow a larger flash on the board would undoubtedly be difficult if it even worked at all, and would probably need some CFE modifications to work completely and properly. And then there is the problem of only having 8MB of RAM... most people would just toss this thing and upgrade, but I enjoy challenges I guess. I was even running swap on the MMC... :O On Sat, 2010-01-16 at 20:35 +0100, bud.d...@suisse.org wrote: > Well, I extensively tested mmc mod for broadcom platform because I > figured it to be the cheapest way to have more space on a openwrt > router, namely the wrt54gl. Eventually I think usb is now the way to go. > > My tests for the sdmodded wrt54gl resulted in > brcm-2.4 - broadcom-mmc, mmc 1.3.5 from forum and sdhc were stable and > usable (sorted by speed) > brcm47xx - mmc kernel module is essentially working but very very slow, > eats all cpu time when transferring and sometimes dies for reasons I > couldnt figure out. Also it was choosy which sdcard to accept. > > I also tried dd-wrt, they use mmc 1.3.5 by the way, and found it as > stable and fast as was to be expected from the above findings. > > > Essentially I have the wrt54gl now running the flash jffs fs overlayed > with sd card ext3 overlaying root. Only draw back is that I can't use > the button the anymore to switch on off the wlan because its gpio lane > is used. > > .. I also agree, let's put it to trunk and wait, if somebody complains, > especially as this is not totally new, but based on work already in trunk. > > .. bud > > > On 16.01.2010 19:36, Spudz76 wrote: > > I have an MMC-over-GPIO enabled Broadcom but I can't get it to take a > > proper flash and boot for some reason with more recent checkouts. It > > runs (gasp) DD-WRT just fine though so I'm confused. If I can get it > > working again I'll test this, especially since I had to do a whole lot > > of fiddling with the original broadcom-mmc package to get it to work in > > the first place (back when it worked in general) so it would be a good > > "fringe" model to test (not a standard WRT54G with MMC mod). It's one > > of the old Belkin F5D7230-4 units with no serial console (no UART even) > > so it's that much more difficult to figure out why I get no completed > > boot. I may try to figure out how to install a UART so I can get the > > console output, but old posts regarding such said the expansion/bus > > header didn't have one of the higher address lines which would be > > required for a 16550. > > > > We need to figure out how to test things like this, or some method of > > deciding whether an untested patch can go in with a single vouch that it > > works (usually from the submitter). Something like this is probably not > > used that much so I'd personally say toss it in and see if anyone > > complains that it doesn't work, as it's not exactly a core piece that > > could affect a large user base if it didn't work. And, the original > > version doesn't really work that well in the first place in my > > experience, so if this one doesn't either then its not much worse at > > least. Other patches though certainly could use a more complete test > > phase, maybe set up a test zone where users could sign up and input the > > equipment they have available and be able to connect a patch with a > > capable tester? > > > > On Sat, 2010-01-16 at 15:32 +0100, bud.d...@suisse.org wrote: > >> Thanks a lot. What about the open actions list.. any comments? > >> > >> Regarding testers: I will put a request/announcement in the forum as > >> soon the module is in the trunk. I myself am using it for months now and > >> discovered no problems. > >> > >> bud > >> > >> On 16.01.2010 15:19, Jo-Philipp Wich wrote: > >>> -----BEGIN PGP SIGNED MESSAGE----- > >>> Hash: SHA1 > >>> > >>> Hi, > >>> > >>> the problem with this particular patch is the inability to test it :) > >>> Afaik none of the developers has a mmc-enabled broadcom box to try it out. > >>> > >>> > >>> I'll look into it later, to see whether it compiles and add it to trunk > >>> then. > >>> > >>> > >>> ~ JoW > >>> -----BEGIN PGP SIGNATURE----- > >>> Version: GnuPG v1.4.9 (GNU/Linux) > >>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > >>> > >>> iEYEARECAAYFAktRyucACgkQdputYINPTPMdRgCcCJ4j16lTYFD1CoR1L4UwAGg/ > >>> Dp4AoJ0t/1+HRh/YARTg2d5I1XS2in+4 > >>> =XO0c > >>> -----END PGP SIGNATURE----- > >>> _______________________________________________ > > > _______________________________________________ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
