SD Karte oder MMC Card über Slot 2 machbar?
-
- Einsteiger
- Beiträge: 369
- Registriert: Samstag 29. Mai 2004, 01:50
-
- Einsteiger
- Beiträge: 123
- Registriert: Montag 28. November 2005, 11:31
Dies ist wirklich eine gute Nachrichtracker hat geschrieben:Und siehe da jetzt mountet er sein root von der SD-Karte
Was klemmt denn beim Schreiben? Wird die Karte mit der mount option "sync" gemountet und/oder sind die Parameter für kupdated so eingestellt, dass geänderte Blöcke bald auf der Karte landen?racker hat geschrieben:Wenn das mit dem Schreiben noch besser klappt wird das eine feine Sache.
-
- Einsteiger
- Beiträge: 369
- Registriert: Samstag 29. Mai 2004, 01:50
Die CPU-Last.just_me hat geschrieben:Was klemmt denn beim Schreiben?
Die besten Ergebnisse sind im Moment beim Mounten mit sync und schreiben
von 512 Byte Blöcken. Dann geht die CPU-Last wenigstens ab und zu unter 90%.
Ansonsten liegt sie zwischen 95 und 99,9%, die Rate bei 22,5 kbyte/s
Lesen liegt zwischen 75% und 85% bzw. 220 kbyte/s.
-
- Einsteiger
- Beiträge: 123
- Registriert: Montag 28. November 2005, 11:31
das hört sich so an, also ob für jeden zu schreibenden Block mehrere geschrieben würden.racker hat geschrieben:Die besten Ergebnisse sind im Moment beim Mounten mit sync und schreiben von 512 Byte Blöcken.
Ist die Partition mit der option "noatime" gemountet?
Welches Dateisystem verwendest Du? (Reiser4?^)
Kommt irgendetwas ins Log, wenn Du mit der option "debug" mountest?
Eigentlich sollte die mount option "async" bessere Schreibraten zeigen als die option "sync". Vielleicht testweise mal ein printk(".") in die Funktion mmc_write_block() einfügen?
-
- Einsteiger
- Beiträge: 369
- Registriert: Samstag 29. Mai 2004, 01:50
Getestet wurde bisher mit vfat, ext2 und ext3. Wobei ich wieder bei vfat bin,
es soll ja auch mit dem Foto klappen .
Sicher gibt es Mountoptionen die noch etwas Geschwindigkeit herausholen,
sie lösen aber nicht das Problem.
Async geht doppelt so schnell - nur bei 100% Last macht das kein Spaß-
und wenn danach der Buffer geflusht wird ist die Kiste wieder blockiert.
Warten wir erst einmal die Ergebnisse von TaGana ab, damit das Teil auch auf
den anderen Boxen funktioniert. Dann ist hoffentlich die Tester-Basis größer
und das optimieren macht mehr Sinn.
Im Moment habe ich sowieso ein Verständnisproblem mit spin_lock_irq und
spin_unlock_irq. Sollten die Funktionen nicht umgekehrt aufgerufen werden?
es soll ja auch mit dem Foto klappen .
Sicher gibt es Mountoptionen die noch etwas Geschwindigkeit herausholen,
sie lösen aber nicht das Problem.
Async geht doppelt so schnell - nur bei 100% Last macht das kein Spaß-
und wenn danach der Buffer geflusht wird ist die Kiste wieder blockiert.
Warten wir erst einmal die Ergebnisse von TaGana ab, damit das Teil auch auf
den anderen Boxen funktioniert. Dann ist hoffentlich die Tester-Basis größer
und das optimieren macht mehr Sinn.
Im Moment habe ich sowieso ein Verständnisproblem mit spin_lock_irq und
spin_unlock_irq. Sollten die Funktionen nicht umgekehrt aufgerufen werden?
Code: Alles auswählen
...
else if (cmd == READ)
{
spin_unlock_irq(&io_request_lock);
for (i = 0; i < nr_sectors; i++)
{
rc = mmc_read_block(buffer_address, mmc_address);
if (rc != 0)
{
printk("mmc: error in mmc_read_block (%d)\n", rc);
code = 0;
break;
}
else
{
mmc_address += hd_hardsectsizes[0];
buffer_address += hd_hardsectsizes[0];
}
}
spin_lock_irq(&io_request_lock);
}
else if (cmd == WRITE)
{
spin_unlock_irq(&io_request_lock);
for (i = 0; i < nr_sectors; i++)
{
rc = mmc_write_block(mmc_address, buffer_address);
if (rc != 0)
{
printk("mmc: error in mmc_write_block (%d)\n", rc);
code = 0;
break;
}
else
{
mmc_address += hd_hardsectsizes[0];
buffer_address += hd_hardsectsizes[0];
}
}
spin_lock_irq(&io_request_lock);
...
-
- Einsteiger
- Beiträge: 123
- Registriert: Montag 28. November 2005, 11:31
Nein, dass ist schon in Ordnung: der io_request_lock bezieht sich meines Wissens nur auf die io_request queue (und der io_request_lock wird gehalten beim Eintritt in mmc_request()). Da die Queue selber während der mmc_read_block() und mmc_write_block() nicht angefasst wird braucht der Lock dort nicht gehalten zu werden. (Es ist kein Lock für die Hardware, wie man zunächst annehmen könnte)racker hat geschrieben:Im Moment habe ich sowieso ein Verständnisproblem mit spin_lock_irq und spin_unlock_irq. Sollten die Funktionen nicht umgekehrt aufgerufen werden?
Wenn man dem 'Level darüber' mitteilen könnte/würde, dass es nur einige wenige (ich weiss nicht, wieviel die Dateisysteme jeweils gerne hätten um rund zu laufen) zu schreibende Blöcke für das mmc device puffern würde, dann sollte es eigentlich besser werden.Async geht doppelt so schnell - nur bei 100% Last macht das kein Spaß- und wenn danach der Buffer geflusht wird ist die Kiste wieder blockiert.
Wo man dies macht weiss ich allerdings nicht
-
- Tuxboxer
- Beiträge: 5873
- Registriert: Samstag 23. Februar 2002, 22:46
VCC und GND ist klar, aber welche Reihenfolge der IO Pins sollte ich wählen damit sie dann mit dem Treiber laufen.DBoxBaer hat geschrieben:racker hat geschrieben: Vlt. sollte man sich jetzt darüber einigen wie das Teil angeschlossen wird.
Nicht jeder, der eine MMC/SD Karte einbauen will kauft sich das IDE-Interface. Ein simples Durchschleifen der Pins mit Anschlussmöglichkeit würde schon reichen.
Bezüglich Anschlussbelegung:
"Meine" Pfostenstecker sind alle so beschaltet (von oben)
VCC GND
IO IO
IO IO
Und davon habe ich 5 Stück in meinem Layout...
Ist die orbrige Belegung die "Draufsicht" auf die Pins des Moduls oder von unten?
Nachtrag:
Habe jetzt mal "wahllos" die IO Pins verteilt.
So passt das Leiterplatten Layout am besten.
Gruß Gorcon
-
- Interessierter
- Beiträge: 30
- Registriert: Montag 14. Februar 2005, 11:58
-
- Tuxboxer
- Beiträge: 5873
- Registriert: Samstag 23. Februar 2002, 22:46
-
- Interessierter
- Beiträge: 30
- Registriert: Montag 14. Februar 2005, 11:58
-
- Senior Member
- Beiträge: 255
- Registriert: Donnerstag 25. August 2005, 11:34
Mit Karte ist wohl eher die SD-Card gemeint. Da die gar nicht somgerald21 hat geschrieben:Hmm, ich dachte auf dem IDE sind 5 Pfostenstecker drauf?Gorcon hat geschrieben:So viele Pins hat die Karte aber nicht.mgerald21 hat geschrieben:Hmm, und wie sieht es mit dem 4Bit Modus für SD Karten aus!?!?
Da braucht man doch ein paar Pins mehr!!
1x VCC
1x GND
1x CLK
1x CS
1x CMD/DI
4x DO[0:3]
viele Pins hat, braucht man auch nicht so viele an dem
Connector.
4 Bit Transfer vom CPLD erwarte ich aber sowieso eher nicht, wenn
überhaupt. Er kann aber hoffentlich die CPU entlasten, wenn er die
Serialisierung (das "Pin-Wackeln") übernimmt.
Wenn es um grosse Geschwindigkeiten geht: Dann klemmt besser
einen fertigen Card-Reader an das IDE Kabel. Sowas gibts nämlich
auch.
Ciao,
DboxBaer
... und der Rest ist dann Software (TM)
-
- Tuxboxer
- Beiträge: 5873
- Registriert: Samstag 23. Februar 2002, 22:46
-
- Klöppelliese
- Beiträge: 1644
- Registriert: Donnerstag 8. August 2002, 12:51
-
- Interessierter
- Beiträge: 30
- Registriert: Montag 14. Februar 2005, 11:58
DBoxBaer hat geschrieben:
Mit Karte ist wohl eher die SD-Card gemeint. Da die gar nicht so
viele Pins hat, braucht man auch nicht so viele an dem
Connector.
4 Bit Transfer vom CPLD erwarte ich aber sowieso eher nicht, wenn
überhaupt. Er kann aber hoffentlich die CPU entlasten, wenn er die
Serialisierung (das "Pin-Wackeln") übernimmt.
Wenn es um grosse Geschwindigkeiten geht: Dann klemmt besser
einen fertigen Card-Reader an das IDE Kabel. Sowas gibts nämlich
auch.
Ciao,
DboxBaer
Nene, eine SD Karte hat 9 Pins. Im SPI Mode werden nur 6 verwendet, aber im SD-Mode (4 Bit) alle Neune.
-
- Einsteiger
- Beiträge: 123
- Registriert: Montag 28. November 2005, 11:31
Wenn schon einmal das IDE Interface eingebaut ist und es auch ein CompactFlash sein darf, bietet sich ein CompactFlash auf IDE Adapter an.DBoxBaer hat geschrieben: Wenn es um grosse Geschwindigkeiten geht: Dann klemmt besser
einen fertigen Card-Reader an das IDE Kabel. Sowas gibts nämlich
auch.
Gibts in 40plg/44plg female/male:
http://www.sintech.cn/en/products/cf-ide/CF-IDE.html
Achja, an so einem Adapter müsste sich auch ein Microdrive ganz wohl fühlen:
http://de.wikipedia.org/wiki/Microdrive
Vielleicht käme man dann sogar ohne Netzteil aus?
PS: Ich cross-poste diesen Beitrag noch im Thread: "IDE-Schnittstelle 2" http://forum.tuxbox-cvs.sourceforge.net ... hp?t=39462 .
Damit's wiedergefunden werden kann Diskussionen bitte dort
-
- Senior Member
- Beiträge: 255
- Registriert: Donnerstag 25. August 2005, 11:34
Aaah, ok.mgerald21 hat geschrieben: Nene, eine SD Karte hat 9 Pins. Im SPI Mode werden nur 6 verwendet, aber im SD-Mode (4 Bit) alle Neune.
Und zählen müsste ich dafür nicht mal können, oben in dem Bild sind
Zahlen in den Kontakten eingezeichnet :-)
Wird aber mit dem CPLD trotzdem nix, das geben die Resourcen
wohl sicher nicht mehr her, jedenfalls so wie mein Design den im
Moment ausquetscht.
-
- Einsteiger
- Beiträge: 311
- Registriert: Mittwoch 27. April 2005, 19:02
-
- Tuxboxer
- Beiträge: 5873
- Registriert: Samstag 23. Februar 2002, 22:46
Das kommt man bei einer 2,5" Platte auch. (ein kleiner Schaltregler reicht da)Achja, an so einem Adapter müsste sich auch ein Microdrive ganz wohl fühlen:
http://de.wikipedia.org/wiki/Microdrive
Vielleicht käme man dann sogar ohne Netzteil aus?
Gruß Gorcon
-
- Wissender
- Beiträge: 1839
- Registriert: Sonntag 17. August 2003, 01:39
-
- Interessierter
- Beiträge: 30
- Registriert: Montag 14. Februar 2005, 11:58
Yep, denke schon (auf eigenes Risiko)Qnkel hat geschrieben:So wie ich das sehe kann man das ja schon nachbauen, oder?
Wann werden die Treiber etc. dafür im CSV bzw. Images sein.
Ich habs mal an ne Sagem angeschlossen. Da der Modemstecker der Sagem aber nicht alle GPIO Pins der Nokia hat musste ich mit den vorhandenen auskommen; D.h. PB16, PB17, PA8 und PA9 und den Treiber dementsprechend anpassen.
Am Anfang hat gar nichts funktioniert. Immer "mmc Init *1*" Fehler. Zuerst dachte ich es liegt an der HW bzw. an dem modifizierten Treiber. Nach 1 Stunde hab ich dann gemerkt, dass man den Treiber nicht mit Optimierung "-Os" übersetzen darf. Nehme an das CLK wackeln ist der Karte dann zu schnell.
Auf jeden Fall funkts und man die SD Partition mounten, lesen und schreiben. Kernel mit VFAT etc. support ist vorausgesetzt.
Im Moment versuche ich (mal auf eigene Faust) den Treiber zu erweitern vorallem in Richtung card_detect. D.h. die Karte im Betrieb ziehen und stecken.
-
- Einsteiger
- Beiträge: 369
- Registriert: Samstag 29. Mai 2004, 01:50
-
- Interessierter
- Beiträge: 30
- Registriert: Montag 14. Februar 2005, 11:58
-
- Erleuchteter
- Beiträge: 682
- Registriert: Samstag 13. Juli 2002, 10:05
-
- Einsteiger
- Beiträge: 369
- Registriert: Samstag 29. Mai 2004, 01:50
-
- Developer
- Beiträge: 279
- Registriert: Mittwoch 26. Juni 2002, 22:19
So, ich hab jetzt auch mal meinen Lötkolben geschwungen und meine alte 32MB MMC eingebaut.
Init läuft alles einwandfrei.
Wenn ich per ftp Musik auf die Karte schiebe, komme ich auf ne Datenrate von ca. 75kByte/s.
Abspielen mit dem Audioplayer stockt zwar ab und zu, geht aber sonst schon ganz gut.
Das der Treiber nicht läuft, wenn er mit dem -O2 flag kompiliert wurde, kann ich bestätigen.
Init läuft alles einwandfrei.
Wenn ich per ftp Musik auf die Karte schiebe, komme ich auf ne Datenrate von ca. 75kByte/s.
Abspielen mit dem Audioplayer stockt zwar ab und zu, geht aber sonst schon ganz gut.
Das der Treiber nicht läuft, wenn er mit dem -O2 flag kompiliert wurde, kann ich bestätigen.
Gruß
Der Papst
Der Papst