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
