Sonstige Motorola FileSystem (MFAT)

Dieses Thema im Forum "Motorola Forum" wurde erstellt von gorgoyle, 7. Okt. 2006.

  1. gorgoyle

    gorgoyle VIP Mitglied

    Registriert seit:
    23. Sep. 2006
    Beiträge:
    298
    Zustimmungen:
    2
    (Nachtrag:
    USB-Timing lässt z.Zt. diese Methode scheitern, weil dann nur noch Nullen gelesen werden
    Hinweis: USB-Timing lässt sich irgendwo einstellen!)

    Ich interessiere mich für das FileSystem, das Motorola auf dem E770v einsetzt und
    vermutlich auch vom E770v auf dem SD erstellt wird, wenn dieser formatiert wird.

    Ich habe über dieses FS folgende Erkenntnisse gewonnen:

    Unter Linux:
    -mounten als fstype vfat oder umsdos klappt nich!
    -fsstat unterstützt FAT16 und sagt das "FS auf dem SD ist KEIN FAT16" bzw. er erkennt es nicht!
    -Block 1 trägt eine Signatur mit ASCII "FAT16"
    -Ein unter Linux als VFAT-formatierter SD wird vom Handy erkannt!!!
    UND
    -kann als Speicher-Medium benutzt werden
    -*.jar-Files in /b/mobile/kjava/ sind ausführbar


    Unter Windows XP:
    -Einbinden klappt! (darf man mounten sagen? *g*)
    -FS wird als FAT16 ausgewiesen
    -File-Attribute sind 'Read-Only', 'Archiv' und 'Hidden'
    -File-Attribut 'System' FEHLT!!! (FAT16?!?)


    Unter P2K-Commander:
    -neue unbekannte File-Attribute
    (File-Permissions) 0x00-0xff
    (P2K is gerade off bei mir (sux!) welche waren es?)
    'No-Copy','No-Use', 'No-Sense', ..

    (Ownership)
    0x00-0xff 255(+1?) Owner möglich, welche sind bekannt?

    -Nicht ALLE FILE-ATTRIBUTE WERDEN ERKANNT bzw. UNTERSTÜTZT!

    Das OS auf dem E770v liest die File-Permissions für '<app-ame>.jar' vom '<app-name>.pat'
    Der Audio-Player und die Golf-Demo besitzen ..

    WEITERE FILE-PERMISSIONS:
    /a/mobile/kjava: ./J2ME0.pat und ./J2ME5.pat
    BEACHTE DEN HEX-WERT für die File-Permissions!
    Die entsprechenden Bits werden nicht interpretiert und beim setzen der bekannten werden
    die unbekannten Bits auf '0' gesetzt, also gelöscht.


    Dieses FileSystem scheint mit dem FAT16-FileSystem verwandt aber
    nicht identisch zu sein. Ich möchte es daher benennen als:

    MFAT (Motorola FAT)!


    Fragen:
    - Welche Geräte benutzen MFAT noch? Alle aus der E- und V-Serie?
    - Was ist nötig, um den FAT16-Treiber von Windows zu modifizieren,
    um davon einen MFAt-Treiber abzuleiten, so daß man zumindest über
    den Card-Reader auf das MFAT-FS auf dem SD zugreifen kann?
    - Was ist nötig, um mittels 'Explorer' regulär über 'P2K.sys' und eine
    hier angedachte 'MFAT.sys' auf die FS im Handz zugreifen zu können?
    - Warum funktioniert VFAT auf dem E770v? "Abwärtskompatinbelität"
    oder spezieller Support?



    Vorschlag zur Organisation des Forum wegen OT entfernt
     
    #1 gorgoyle, 7. Okt. 2006
    Zuletzt bearbeitet: 17. Okt. 2006
  2. BlackyP

    BlackyP VIP Mitglied

    Registriert seit:
    21. Aug. 2006
    Beiträge:
    2.379
    Zustimmungen:
    12
    Ganz schön viel auf einmal ;)
    Beim V980 wird die TF-Karte z.B. nur mittels FAT formatiert (Format ist vom PC her bekannt).
     
  3. logofreax

    logofreax Gründer

    Registriert seit:
    21. Apr. 2006
    Beiträge:
    42.420
    Zustimmungen:
    1.039
    Also das Forum weiter zu unterteilen ist nicht vorgesehen weil es in meinen Augen unnütz wäre, weil sich doch sehr viel mit anderen Modellen überschneidet. Ich kenne das aus anderen Foren. Ist zwar im Ersten Moment übersichtlicher, aber im Endeffekt chaotischer.

    cu
    logofreax
     
  4. Meiner Einer

    Meiner Einer Vertrauensmitglied

    Registriert seit:
    21. Aug. 2006
    Beiträge:
    5.795
    Zustimmungen:
    15
    Du gehst wirklich ganz schön speziell rein. Aber wirklich wichtig ist diese Problematik nur für Programmierer, die ein Zugriff auf das Filesystem des Handys brauchen. Damit meine ich nicht die "Normal"-Zugriffe wie Dateien übertragen, löschen usw., denn da wird wird der Prozessor des Handys und dessen Soft tätig und baut das selber in das bestehende Filesystem ein. Das heißt, wie jeder PC auch, verwaltet es das Handy selber.

    Wichtig wäre es nur, wenn Du ein Programm schreiben wolltest, was z.B. eine Defragmentierung im Handy durchführt oder ein Datenrettungsprog zum Wiederherstellen versehentlich gelöschter Dateien. Nur dann muß man den Aufbau des Filesystems ganz genau kennen, weil dann die Kontrolle Dein Programm übernimmt.
    Oder aber für einen Flex-Editor, der aber (im PC) die Struktur auseinandernimmt und dann nach diversen Änderungen wieder neu zusammensetzt.

    Bist Du Programmierer? Wenn ja, hast Du vor, etwas in dieser Art zu schreiben?
    Ansonsten ist diese Problematik für alle übrigen User vielleicht "Interessant, zu wissen", aber ansonsten ohne Bedeutung.
    Sorry, aber dafür einen eigenen Bereich einzurichten, lohnt einfach nicht, es sei denn, da kommt wirklich was brauchbares rüber.
     
  5. gorgoyle

    gorgoyle VIP Mitglied

    Registriert seit:
    23. Sep. 2006
    Beiträge:
    298
    Zustimmungen:
    2
    Meine Interesse kommt daher, daß ich für Java-Apps File-Permission
    bezogene Attribute selber setzen möchte, um z.B. vom Handy aus
    mit einen Editor auf Dateien zugreifen kann oder mit PROS -> eine kleine
    Java-Application fürs Handy] (Shell+Basic mit Grafik-Befehlen), kleine
    Programme schreiben können möchte. Geht jedoch nicht weil die Apps
    keine FileSystem-Rechte besitzt.

    Außerdem wäre dann eine Java-App fürs Handy Cool um das mit dem
    Handy Stand-Alone lösen zu können. Ich las von einen File für den
    P2K-Commander, der hierfür gerade am entstehen ist.
    Ich vermute, daß MFAT ein modifiziertes FAT16 ist und deswegen
    FAT16 so gut wie vollständig funkzioniert. Ist interessant, wenn
    man mit einem Disk-Editor auf das FS zugreift, was denn was zu
    bedeuten hat.

    Werde nach docs für Fat16 suchen und nach Differenzen Ausschau
    halten. Außerdem wäre doch mit einen beliebigen File-Browser auf
    das Handy zugreifen können wäre doch eine schöne Sache.

    Mit einem Disk-Editor kann man den auch mutig gucken, was denn
    die anderen Bits so schönes machen.

    Ich sag es gibt Access-Allow Bits für:
    (/dev/)btspp:// und ich schätze er heißt (/dev/)irspp://
    und es gibt da auch irgendwo ein local://
    Wo sind denn die device-files denn untergebracht?
    Ein dickes File in /a/ wird ein File-System-File sein oder enthalten
    .. eine Art initrd
    komm da mal ran mit nen normalen user-tool! Wirds sicherlich wohl bald geben
    (push) aber erstmal basteln! (Linux ist wenn es dennoch geht!)

    Wer ein FS-Dump machen möchte, der kopiere /a mit P2K-Commander!
    It's not a bug .. it's a FEATURE!!! (wirklich?) Kann einer mal dem P2K-Author
    verraten, daß er einen Dump-FS-Button ins Menu aufnehmen kann und nur
    noch den Button mit "copy /a" verbinden muß?

    Die Größe des Files zeigt erstaunliche Eigenschaften! *ggg* E770v rulez!

    APROPOS FLASHER!!! Flaschen ist ja ne schicke Sache, aber so schnell
    wie ich mit copy /a mit P2K-Commander den kompletten Speicher
    ausgelesen habe, so schnell habt ihr noch nie geflascht! Sonst würdet
    ihr nicht sagen "Accu sollte voll sein!"

    Wenn Umgedreht der copy-Befehl nach /a so schnell funktioniert, dann
    dann geht das EXTREM SCHNELL! So lassen sich Handies im handumdrehen
    DEBRanden und alles ander: IMIGE auswählen, raufschieben (1 minute ?)
    *ding* fertig!

    Ich schätze mal, nach meinen Erfahrungen mit P2K-Commander und "normalen"
    Copy und dem beschriebenen FS-Dump werden viele erstmal sagen: So ein Quatsch!
    Aber kopiert doch mal DIREKT /a auf platte! (schwupps!)
    Guckt rein! Das sind 36(!) MB DATA vom handy! Schreibt Doch mal ne msm
    oder irgendeinen Text rein und sucht danach im neuen fs-dump! Findet ihr!
    Bleibt die Frage: warum sind es 36MB und nicht 32MB?
    Jemand der sich mit disassembling auskennt weiß dann sicher auch schnell zu
    sagen, zu welche cpu-Familie der code der java-vm gehört.
     
    #5 gorgoyle, 8. Okt. 2006
    Zuletzt bearbeitet: 8. Okt. 2006
  6. gorgoyle

    gorgoyle VIP Mitglied

    Registriert seit:
    23. Sep. 2006
    Beiträge:
    298
    Zustimmungen:
    2
    Habe in Wikipedia ne page Filesystem-Vergleich gefunden und im Jahre 2002 hat Microsoft ein neues FileSystem FATX gefunden.
    Es gibt weiter eine Seite, die sich die Mühe macht, die Unterschiede zwischen FATX und FAT16 aufzuzeigen. Ich sehe eine gewiße Möglichkeit, daß auf dem E770v und natürlich auch auf anderen FATX als FileSystem installiert ist.

    Wenn MFAT keine Unterschiede zu FATX aufweist, wäre die namentliche Unterscheidung sinnlos!

    Angenommen MFAT ist FATX - Dann ...
    - Wer linux hat, findet hier schon rudimentäre Treiber-Unterstützung, der EINIGE Unterschiede zwischen FATX und FAT16 berücksichtigt bzw. EINIGE Erweiterungen kennt und deswegen diese regulär im Browser als Menu-Optionen anbietet.

    Allerdings ist dort der Treiber, weil nach Meinung der Linux-XBox-Community ein FATX-Treiber ohne XBOX wenig Sinn macht, in einer Distribution integriert und so muß ich den erstmal rauslösen und gucken wie man ein Packet erstellt. Aber die Intuitive Bedienung von rpm und deb ..
    *schluck*

    Wenn ich geschafft habe, ein widerspenstiges Knoppix auf ein Notebook zu zwängen, dann werde ich auch gleich FATX austesten.
     
    #6 gorgoyle, 8. Okt. 2006
    Zuletzt bearbeitet: 10. Okt. 2006
  7. logofreax

    logofreax Gründer

    Registriert seit:
    21. Apr. 2006
    Beiträge:
    42.420
    Zustimmungen:
    1.039
    Wenn du die Verantortung dafür übernimmst und dem User ganz genau sagst wieviel Akku so ein Flash benötigt dann ändere ich das sofort.

    Fakt ist das ein voller Akku weniger Risiken brigt als ein voller Akku. Und es gibt immer noch User die es schaffen, das der Akku beim flashen auf einmal leer ist...ich spreche aus Erfahrung.

    cu
    logofreax
     
  8. Meiner Einer

    Meiner Einer Vertrauensmitglied

    Registriert seit:
    21. Aug. 2006
    Beiträge:
    5.795
    Zustimmungen:
    15
    @ gorgoyle

    Das mit dem superschnell auslesen glaube ich Dir nicht so ganz. Das aber nur am Rande.
    Ich will Dich jetzt nicht angreifen, aber ich vermute mal, Du hast Dich bisher nur mit dem Teil des Handys beschäftigt, der das Filesystem beinhaltet. Die Dateien, die der Commander sichtbar macht. Das ist aber nur ein ganz geringer Teil der vollständigen Soft des Handys.

    Aber jetzt zu Deinem Problem. Ich (und einige andere hier) waren schon mal Tester für eine Java-application, die von einem Softwarehaus als Auftrag für eine Sparkasse entwickelt wurde. Test soweit erfolgreich, allerdings sagte mir dann der dortige Programmierer, ein Neustart des Handys über diese Soft ist nicht möglich wegen fehlender Zugriffsrechte. Ich hoffe, das hilft Dir weiter, denn das hat nichts mit dem Filesystem an sich zu tun.

    Aber auch zu Deinem Filesystem... Motorola verwendet aus Kompatibilitätsgründen FAT16 auf der Speicherkarte. Aber nur, um diese Karten auch mit dem PC mittels Cardreader lesen/beschreiben zu können.
    So wie ich Moto kenne, verwenden die intern ein Filesystem, was ursprünglich auf Unix (nein, nicht Linux) verwendet wurde. Entsprechend modifiziert (vereinfacht).
    Ist bisher nur eine Vermutung meinerseits, aber sobald ich mein laufendes Projekt abgeschlossen habe, werde ich mir das mal genauer anschauen.

    Aber für Deine Java-Programmierung sollte das nicht von wirklicher Bedeutung sein, denn das Filesystem selber erscheint bei Dateizugriff weder an den aufrufenden Programmen, noch am seriell/USB - Anschluß. Die Geräte/Programme "sehen" und schreiben nur die Daten selber und diverse Steuerbefehle, inclusive Deiner Flagbits.
    Sollte es wirklich Unix-basiert sein, gibt es 8 Stück davon.
     
  9. gorgoyle

    gorgoyle VIP Mitglied

    Registriert seit:
    23. Sep. 2006
    Beiträge:
    298
    Zustimmungen:
    2
    Ich muß mir das ganze nochmal genau angucken.

    Hier nochmal so präzise wie aus meiner Erinnerung möglich:

    Sicher:
    - Ich habe /a nach C:\temp kopiert
    Unsicher:
    - Ich meine es dauerte nur 2-3 Minuten!
    Sicher:
    - Ich war verärgert, weil SO SCHELL kann das doch niemals geklappt haben!
    - Ich habe ein File erhalten das (ca. oder genau) 36MB groß ist. (36*1024*1024)
    Unsicher:
    - Ich vermute, daß dies vollständig der Spicher des E770v ist!
    Sicher:
    - Das File enthält keinen Daten-Müll sondern Daten u.a. aus SMS und dergleichen

    BEDINGT Sicher: (Also nicht ;))
    -WENN MAN SO auch wieder 36MB auf das E770v schieben KANN (???) --- DAAAANN bricht man alle
    bisherigen Flash-Rekordzeiten und DAMIT BIN ICH MIR SICHER!
    Hat das jemand schon mal ausprobiert? Wie schnell konntest du /a auslesen?
    Risiko ist HIER ein 36MB-File auf dem PC zu vergessen, daß solange Platz fortnimmt bis es gelöscht wird!

    ICH HABE NOCH NICHT GETESTET SO AUF DAS HANDY ZU SCHREIBEN!
    Das habe ich noch nocht ausprobiert weil
    - ich hab noch kein Ersatz Handy bzw. habe noch keine Zeit gefunden meine zahlreichen 51%-Beteiligungen
    in diversen Aktien-Gesellschaften loszuschlagen, um fluide Mittel freizumachen *spinn*
    - RSD-Lite bei mir manchma meint P2K-Services zu deaktivieren zu müssen ...
    D.h.: Hab bisher auch nur in weniger vitalität-bedingende Bereiche geschrieben.
    - Die Software um mit Datenblöcken und ähnlich zu experimentieren nicht auf dem Windows-Rechner
    habe.

    WENN die beschrieben Weise, 36MB am Stück auf /a zu schreiben funktionieren soll, dann geht das nur:
    -wenn man dabei keine Firmware überschreibt, die zum Schreiben in den Speicher notwendig ist.
    Wo steht die also? Im ROM oder RAM? Wenn das FS offenliegt und deren Inhalt vollständig vorliegt,
    dann kann man solche Frage viel leichter beantworten!

    -Sollte RAM der Fall sein, muß man schauen, welche Speicher-Segmente die für das Beschreiben
    notwendige Firmware enthalten, um diese gezielt überspringen zu können also nicht zu überschrieben
    werden.

    Fast Sicher: Wenn man so schnell auslesen kann, kann man auch (fast) genauso schnell
    wieder einschreiben! Hat jemand schon mal gemessen, wie schnell beim regulären Flashen
    die Bits aufs Handy hüpfen und mit eine Transfer-Rate vom P2K-Commander beim
    Kopieren regulärer Files (/a ist kein reguläres File sondern schein eine Geräte-Datei (Block-Device)
    zu sein, denn copy /a C:\tmp liest die Geräte-Datei direkt aus! Das ist am File-System vorbei und
    SEHR DIREKT!)
    Warum macht der blöde P2K-Commander nicht einfach so einen FS-Dump als temp und bedient
    darüber und erst zum Schluße schreibt er die veränderten Daten wieder zurück? Warum dauert
    es überhaupt solange, bis das Handy auf P2K-File-Transfers so träge reagiert? Man vergleiche wie
    schnell die 36MB rüberrutschen und schaue, wie lange man auf die Verzeichnis-Tabelle (FAT) wartet...
    Hüstel ...

    Also warum ist das E770v am P2K-Commander so langsam?
    Weil das FileSystem so einen Overhead verursacht? Wäre schön wen man genauere Specs über
    den Processor hat. So kann man nur spekulieren, wie schnell er wirklich ist und womit er seine
    übrige Zeit vertrödelt!

    Wenn es möglich ist, beim Schreiben beliebige Segmente zu addressieren, dann
    wäre ohne spezielle Programme der einfachste Weg um Hinweise zu kriegen, ob der
    P2K- und der USB-Treiber im Flash enthalten sind:

    - schauen ob das P2K-Interface eine Methode version() kennt (Rückgabewert?)
    - einen FS-Dump vom Jungfräulichen Handy zu machen
    - Umzuflaschen
    - zweiten FS-Dump zu machen
    - schauen ob P2K eine andere Versionsnummer mit version() zurückgibt (gleiche Versionsnummer?)
    - mittels eines binär-tauglichen diff-Program die veränderten Bereiche ausfindig machen
    - hoffen das der Arbeitsspeicher nicht enthalten ist!!!
    Wenn der CPU ein veralteter Arbeitsspeicher untergeschoben wird:
    Untere Seite von Vorgestern - Obere Seite von ebend gerade noch
    Dann ist das Absturz-Verhalten sehr schwer vorherzusagen aber sicher daß Handy abstürzt!
    - hoffen das die System-Teile. die notwendig sind, um direkt über P2K in den Speicher zu schreiben,
    nicht überschrieben werden

    Schön wäre es, wenn der System-Teil, der vom USB-Interface bis zum Speicher reicht, als
    Fallback-Variante fest eincodiert ist, das man so IMMER den Speicher beschreiben kann.
    Gibt es Erfahrungen mit System-Teilen, die man bisher NICHT durch flashen verändern konnte
    oder nach mißlungenen flashen nicht wieder herstellen konnte?
    Gab es schon Versuche ein Handy totzuflaschen? Ich habe in Erinnerung, daß wenn garnichts
    mehr geht, geht noch der boot-loader und dann kann man auch flashen!
    Wenn man den gezielt teil-modifiziert soll heißen kaputt-flascht und dann die normalen
    Wiederbelebungsversuche durchführt, lässt es sich dann wieder neu beflaschen?

    Wer hat schon ein Handy der E-Serie oder V-Serie durch flaschen unwiderbringlich kaputtet?
    Würde mich sogar mit Geld (5€) beteiligen, um zu erfahren daß ein Handy der E- oder V-Serie
    (nicht) kaputtzuflaschen ist!

    Ich will nur wissen, ob und wie weit ein System-Fall-Back-Absicherung das Handy schützt.
    Wenn ich wüsste, daß ich durch Flaschen garnicht unumkehrbar das Handy unbrauchbar
    machen kann, weil es nur wieder richtig geflascht werden muß, dann wäre ich mit
    "copy E770v /a" viel mutiger. Aber wenn flaschen ein echtes Risiko darstellt bin ich seeehr
    vorsichtig!



    - Nur die Bereiche umzupatchen, die mit diff aufgefunden wurden
    Hab auf meiner Distribution kein bdiff bzw. binär-tauglichen diff-Programm gefunden.
    Bilde ich mir das nur ein oder wurde das Tool nicht mal beigelegt? Muß wohl mal im Archiv
    graben.

    Als elementare Software wie Treiber kenne ich bisher den Boot_Loader
    (bekannt ist von Flash-Namen seine Versions-Nummer, z.B. Version 0.6.7.1)
    und die "SW_Version" z.B. 85.92.701P
    BTW: Ich rate mal daß das "P" am Ende für Production steht und sagt, daß dies diese
    SW_Version als "Für den Verkauf geeignet" kennzeichnet und TATSÄCHLICH in die
    Produktion gegangen ist. Aber ist ebend nur geraten. Alpha oder Beta soll es wohl nicht heißen!

    Naja .. ich beende mal dieses kurze Statement .. mfg!
     
    #9 gorgoyle, 10. Okt. 2006
    Zuletzt bearbeitet: 10. Okt. 2006
  10. Meiner Einer

    Meiner Einer Vertrauensmitglied

    Registriert seit:
    21. Aug. 2006
    Beiträge:
    5.795
    Zustimmungen:
    15
    Ich merke schon, Du willst das Rad neu erfinden....
    Der Flashchip vom E770v ist 64 MB groß. Er ist aufgeteilt in 2 Partitionen: /a/ und /e/ - nein, das ist KEIN Schreibfehler!

    Es gibt schon Programme, die das Handy über Speicher-Direktadressierung auslesen (können) - Flashbackup
    Du solltest aber NIEMALS versuchen, ein anderes Backup aufs Handy zu spielen. Es gibt Bereiche innerhalb des Chips, die sich zwar auslesen, aber nicht beschreiben lassen auf diese Art - Simlock, IMEI usw.

    Der P2K-Commander kann zwar auf 3G (UMTS) Geräte wie das E770v zugreifen, aber er produziert nach einer gewissen Zeit Lese/Schreibfehler. Nennt sich dann "USB-Timout". Er zeigt es zwar an, aber er beendet seine Arbeit nicht. Das heißt, er kopiert fleißig "irgendwas" weiter - Nämlich Datenmüll. Das geht dann auch recht schnell, weil er im Prinzip nur noch die Dateieinträge schreibt und die Größenangabe, das File selber aber "korrupt", "leer" oder sonstwie fehlerhaft ist. Das würde Dein schnelles Kopieren erklären. Prüfe mal die Dateien!

    Ebenso kann der Commander nur innerhalb des sog. "Flex-Bereiches" zugreifen. Also der Teil des Handyspeichers, der ein Filesystem enthält. Der weitaus größere Teil des Speicher arbeit ohne Filesystem - das heißt, die Handysoft arbeit intern mit direkter Speicheradressierung.

    Ich habe einen Hex-Editor, der Daten vergleichen kann. macht aber nur Sinn, wenn man weiß, wonach man sucht. Manche Werte ändern sich auch, weil es temp. Daten sind - also unwichtig zum Vergleich

    Bei den Versionsnummern müßtest Du Psycomorpher fragen, er kann diese Bedeutung bestimmt besser erklären als ich.
     
  11. gorgoyle

    gorgoyle VIP Mitglied

    Registriert seit:
    23. Sep. 2006
    Beiträge:
    298
    Zustimmungen:
    2
    Welches der Räder meinst du genau?

    Laufwerk /e/ wird mir von meinem Handy verheimlicht ..
    Und das mit dem Crash-Kurs hat jaleider bisher noch nicht geklappt :(
     
  12. smypls

    smypls VIP Mitglied

    Registriert seit:
    22. Aug. 2006
    Beiträge:
    833
    Zustimmungen:
    9
    Ich habe das auch gerade mal ausprobiert beim V3x.
    Mit dem P2K Commander a/ aus dem handy auf c:\ kopiert. Erhalten habe ich eine Datei der Größe 34,5 mb. Die Datei enthält allerdings nichts außer "000..".
     
  13. gorgoyle

    gorgoyle VIP Mitglied

    Registriert seit:
    23. Sep. 2006
    Beiträge:
    298
    Zustimmungen:
    2
    NUR NULLEN?!? Wenn du sagen würdest: SCHLIESSLICH nur Nullen, dann:>

    gucke weiter unten bzw. drücke hier:
    http://www.faq4mobiles.de/forum/showpost.php?p=13517&postcount=10

    Wenn aber NUR NULLEN, dann muß ich sagen: Bei mir war das aber anders!
    Es enthielt "Daten vom Handy"! Ob es File-Inhalt, Arbeitsspeicher, temp oder
    was auch immer war weiß ich nicht. Ich habe nicht bemerkt, daß es schließlich
    nur noch Nullen enthalten habe.

    Kurzgefaßt: Es würde gehen, wenn das USB-Timeout zufriedenstellend eingestellt
    wäre und daß es sich einstellen lässt beweißt mein Handy indem es aus unbekannten
    Gründen schon nach ca. 80 ms den USB dicht macht :(

    Liegt am Handy den mit einen anderen Baugleiches funzt es!
    Nachtrag: habe P2KCommander skriptgesteuert ein Skin aufspielen lassen und es
    klappte .. Mögen sich mein Handy und der Commander nicht so?

    Kann man den Stream an beliebiger Stelle wieder aufnehmen? Dann könnte man das
    ganze zusammenstellen? Immer wieder nur solange Stücke kopieren, wie vll. per
    Messung ermittelt es dauert, bis der USB-Port dicht macht. Wenn man nur von Null
    anfangen kann ist das natürlich blöde ...

    Blöde Frage aber .. weiß jemand wie ich das meinen Handy wieder abgewöhnen kann?
    So ist nix zu machen!
     
    #13 gorgoyle, 17. Okt. 2006
    Zuletzt bearbeitet: 17. Okt. 2006
  14. gorgoyle

    gorgoyle VIP Mitglied

    Registriert seit:
    23. Sep. 2006
    Beiträge:
    298
    Zustimmungen:
    2
    Wenn einer auf Linux das FS vom Handy mounten kann, der melde sich!
    Gebe dann ein Skript um am USB-Timeout vorbeizukommen und den
    RAM am Stück auszulesen :)
     
  15. BlackyP

    BlackyP VIP Mitglied

    Registriert seit:
    21. Aug. 2006
    Beiträge:
    2.379
    Zustimmungen:
    12
    @gorgoyle
    Den Edit-Button ignorierst du in der letzten Zeit ziemlich oft, kann das sein ;)
     
  16. gorgoyle

    gorgoyle VIP Mitglied

    Registriert seit:
    23. Sep. 2006
    Beiträge:
    298
    Zustimmungen:
    2
    hmm .. ignorieren ist es nicht .. an welcher Stelle wäre denn ein Edit angebracht?
     
  17. Moondog

    Moondog VIP Mitglied

    Registriert seit:
    12. Sep. 2006
    Beiträge:
    248
    Zustimmungen:
    2
    Gorgoyle, du bist echt ne harte Nuss.
    mach ruhig weiter und gib und damit die Möglichkeit die kleinen "PC's" genannt Handy so effizient als möglich zu nutzen.
    Alles was bisher machbar ist, - vielleicht bald "war" - macht natürlich neugierig auf mehr und wenn dann jemand wie Du sich dransetzt um ...... Welten zu entdecken....


    @Logo ..... ist das vielleicht wirklich eine eigene Rubrik wert...?
     
  18. D3f3kt

    D3f3kt VIP Mitglied

    Registriert seit:
    4. Sep. 2006
    Beiträge:
    919
    Zustimmungen:
    2
    Aber du bedenkst eines nicht. Beim Auslesen muss er nur die anordnung der Speicherränge abfragen, das geht in Sekundenbruchteilen. Beim Schreiben muss er sie völlig neu ausrichten, das dauert ein vielfaches mehr. Les doch mal eine HDD aus, und dann beschreiben sie mal komplett. Dann siehst du was ich meine.

    Man kann nie, und wird nie so schnell schreiben wie lesen können. Das ist physikalisch Bedingt.

    Mfg D3f3kt
     
  19. gorgoyle

    gorgoyle VIP Mitglied

    Registriert seit:
    23. Sep. 2006
    Beiträge:
    298
    Zustimmungen:
    2
    Ich (hoffe ich) habe nie gesagt genauso schnell sondern ähnlich schnell!
    Bei den meisten Speichtertypen korrelieren diese Zahlen, nur beim EPROM-brennen
    und andere statische/persisten speicher-typen sind mir starke abweichungen
    aufgefallen!

    Bei der HDD fallen noch head-moves an, die beim direkten schreiben auf das device
    dadurch reduziert sind, daß die platte (hoffentlich) die sektoren so wie sie auf der
    platte angeordnet hat auch für LBA durchnummeriert hat!
    Ich kenn die addressier-methoden nicht so, aber über den Daumen gepeilt kann von
    der logistic her nicht mehr anfallen als doppelte Zeit für addressierung und wenn dies
    so möglich, dann wäre das usb-timeout ja kein problem!


    Wenn das Speicher-System eine Burst-Methode kennt, dann ist der Adressier-Teil
    nicht so groß!
    Wenn am FileSystem vorbei direkt auf das Gerät, hier ein Speicher, geschrieben werden
    kann, wartet man nicht darauf, das Handy-OS auf das FS im Speicher zugreift, dem FS
    entsprechend leere Sektoren ausfindig macht, dann diese als nicht mehr "Frei" abmeldet,
    dann die Daten einschreibt, dann ggf. ein gleichnamige File löscht (ähnliche Prozedur)
    und dann diese als belegt einträgt. Sondern (so sollte es sein) bis zum fertigschreiben
    die FS-Structur korropierend überschreibt und am Ende ein valides FS hinterlässt.
    Nix gucken wo frei und verwaltungskram sondern blind darüber weg!
    Wenn man in Sachen FS bisher zu einem wesentlichen Teil auf das OS/FS warten muß,
    dann nur noch auf den Flaschenhals vom USB-Bus über den ohci heißt er wohl zum
    speicher-subsystem in den Speicher! Das FS und das OS machen da überhaupt nicht mehr mit!


    Fragen:
    Welche Methode benutzt das Flaschen daß kein USB-Timeout-Problem auftritt?
    Wie groß ist der sicher am Stück zu übertragene Block?
    Wie hoch sind die Transferraten dabei?
     
    #19 gorgoyle, 19. Okt. 2006
    Zuletzt bearbeitet: 19. Okt. 2006
  20. gorgoyle

    gorgoyle VIP Mitglied

    Registriert seit:
    23. Sep. 2006
    Beiträge:
    298
    Zustimmungen:
    2
    Was meinst du mit "neu ausrichten"?

    Wenn du linux hast und so (als root) direkten Zugriff auf die Geräte,
    dann mache dir doch am besten eine 700mb-partition frei und probiere das mal aus:

    WARNUNG! DATEN IN ZIELPARTITION AUF FESTPLATTE WERDEN VOLLSTÄNDIG ÜBERSCHRIEBEN!
    hd_xy muß deine Festplatte sein! x ist ein Buchstabe und WICHTIG y ist für die Partition!!!
    wenn du auf hdX mehrere Partitionen hast (hdx1,hdx2,..) und du schreibs auf hdx (arrgh!),
    dann überschreibst du ALLE PARTITIONEN!! Also vooorsicht!

    #/> time dd bs=M </dev/cdrom >/dev/hd_xy (hd mußt du selber aussuchen wenn du verstanden hast was du machst!)

    und vergleich mit normalen kopieren:
    #> time cp -ab /mnt/cdrom/* /tmp

    Der Inhalt lässt sich leicht wieder anzeigen:
    #> mount -t iso9660 /dev/hd_xy /mnt/iso-image

    Fazit: Das Ein- und Ausschreiben nähert sich stark dem praktisch maxima möglichen! (oder IST das praktisch maximal mögliche!)
     
    #20 gorgoyle, 19. Okt. 2006
    Zuletzt bearbeitet: 19. Okt. 2006
Die Seite wird geladen...