Max var ipk für die 8000

    • Max var ipk für die 8000

      Moin hier mal ein max var ipk für die DM8000 erstellt von gutemine für oe1.6.Die Installation dauert einen Moment.

      Hier die Readme:

      Geht aber wirklich nur auf einer 8000er mit OE 1.6 Image (obwohl OE 1.5 support auch kein Problem wäre, aber jetzt testet erstmals so)

      ipk auf /tmp FTPen

      Dann installieren:

      ipkg install /tmp/enigma2-plugin-extensions-maxroot*.ipk

      Und rebooten und wenn Ihr vorher und nach dem reboot df -h macht sollte sich was ändern :

      root@dm8000:~# df -h
      Filesystem Size Used Available Use% Mounted on
      /dev/root 120.0M 48.1M 71.9M 40% /


      Manchmal sind es halt die einfachen Dinge die Freude machen. Schließlich haben wir für die Flashbausteine auch bezahlt, also warum Sie nicht auch benutzen ?

      PS: mit ipkg remove enigma2-plugin-extensions-maxroot wird man es wieder los, und nach reboot ist das alte image im 64 MB Flash Baustein wieder aktiv.

      PPS: Falls es nicht klappt probiert mal im Bios die Console Zeile zu disabeln (das Plugin macht eh das selbe in die /boot/autoexec.bat)
      Dateien

      • Maxroot8000.rar

        (2,2 kB, 657 mal heruntergeladen, zuletzt: )
      mfg harry

      Dreambox 8000SS

    • RE: Max var ipk für die 8000

      Original von harry
      Manchmal sind es halt die einfachen Dinge die Freude machen. Schließlich haben wir für die Flashbausteine auch bezahlt, also warum Sie nicht auch benutzen ?


      kann schon sein nur ist jffs2 kagge dafür und es kann bei so grossen flash zu problemen kommen, ich
      hoffe ja immer noch auf einen kernel > 2.6.27 mit neuem datei system so das man die 256 mb auch
      gescheit nutzen kann.

      linux-mtd.infradead.org/doc/ubifs.html
      » time to say goodbye «

      Konfuzius sagt:
      Erst wenn eine Mücke auf deinen Hoden landet wirst du lernen Probleme ohne Gewalt zu lösen.

    • RE: Max var ipk für die 8000

      @nixkoenner
      kann schon sein nur ist jffs2 kagge dafür und es kann bei so grossen flash zu problemen kommen, ich
      hoffe ja immer noch auf einen kernel > 2.6.27 mit neuem datei system so das man die 256 mb auch
      gescheit nutzen kann.

      linux-mtd.infradead.org/doc/ubifs.html[/quote]


      Hier mal kurz eine Anmerkung zum Thema:
      UBI ist eine Softwareschicht für Flashspeicher, die sich um Wear Leveling und Badblocks kümmert. Auf einem von UBI verwalteten Device,lassen sich Partitionen anlegen auf denen Flash-Dateisysteme wie JFFS2 oder UBIFS reingelegt werden können.
      JFFS2 ist weit verbreitet und läuft auch ohne UBI, hat aber ein paar Geschwindigkeitsprobleme (vor allem beim Mounten). UBI mit UBIFS soll diese angeblich nicht haben. Ob der Schreib- und Lesedurchsatz besser ist weiß ich allerdings noch nicht. UBIFS ist ein Dateisystem das extra dafür entwickelt wurde mit UBI zusammen zu arbeiten. Seit 2.6.27 ist UBI (und evtl. UBIFS) im Main Linux Kernel

      Klassische Dateisysteme wie FAT oder EXT2 können nicht direkt auf Flashspeicher oder UBI laufen. Der Grund dafür ist, daß Flashspeicher ein paar unangenehme Eigenschaften hat:

      Bits können nur gelöscht werden (aus einer 1 kann man eine 0 machen, aber nicht anderherum)
      Pro Block (ca. 16kb gross) können nur ca. 1-5 Bits nachträglich geändert werden
      Bevor ein Block geschrieben werden kann muss er erst komplett gelöscht werden (alle Bytes werden auf 0xff gesetzt)
      Beim Lesen oder Schreiben können Bits flippen, daher braucht es Checksummen (ECC) und Badblockverwaltung

    • RE: Max var ipk für die 8000

      quelle


      UBIFS (Unsorted Block Image File System)
      UBIFS arbeitet auf der Basis von UBI-Inhalten. UBI ist ein „Volume-Management“-System,
      dass mehrere logische Volumes auf einem physikalischen Flash-Speicher verwalten kann.
      Leider kann UBIFS nicht, so wie LOGFS, auf MTD-Devices verwendet werden. Seit 2007
      entwickelt und verbessert die Universität von Szeged in Ungarn mit Unterstützung der Fir-
      ma NOKIA das Dateisystem UBIFS. Seit dem Kernel 2.6.27 ist UBIFS in Linux integriert.
      UBIFS ist ein Nachfolger von JFFS2 und somit ein Konkurrent von LOGFS.
      Während JFFS2 kein Indexing auf dem Flash-Speicher selbst durchführt reiht UBIFS die
      Indezes in einen B+ Baum ein, der mit einem Wandering-Algorithmus durchlaufen werden
      kann.
      Während JFFS2 eine verkettete Liste der Indexes immer im Speicher hat arbeitet UBIFS
      mit der TNC-Methode (Tree Node Cache). JFFS2 verwendet zudem das „write through“-
      Verfahren, also schreibt die Daten immer sofort, während UBIFS das „write back“-Verfah-
      ren benutzt, also die Daten beim Schreiben puffert.



      LOGFS
      LOGFS ist ein weiteres log-strukturiertes skalierbares Dateisystem, dass darauf abzielt
      JFFS2 in den meisten Fällen abzulösen. Der Fokus von LOGFS liegt jedoch bei größeren
      Flash-Speichern (> 64MB – 512MB). LOGFS wird alleine von Jörn Engel entwickelt, hat es
      bisher jedoch leider nicht in den offiziellen Linux-Kernel geschafft. Herr Engel wird von
      CELF (Consumer Electronics Linux Forum) unterstützt. Dies ist eine gemeinnützige Orga-
      nisation, die daran arbeitet beziehungsweise Menschen unterstützt um Linux als Open
      Source Plattform für „Consumer Electronics“ zu verbessern.
      Ein großer Vorteil von LOGFS ist, dass es im Gegensatz zu seinen Konkurrenten JFFS2,
      UBIFS und YAFFS die Möglichkeit bietet Bl



      JFFS2 (Journalling Flash File System version 2)
      JFFS wurde von Axis Communications für NOR-Flash-Speicher entwickelt. Aufgrund ho-
      her Nachfrage unter anderem für die Nutzung auf NAND-Flash-Speichern wurde JFFS von
      RedHat komplett neu geschrieben und es entstand JFFS2. Seit der Kernel-Version 2.4.10
      ist JFFS2 fest in Linux integriert. JFFS2 befindet sich auch in Bootloadern wie zum Bei-
      spiel „Uboot“ oder „RedBoot“.
      JFFS2 ist ein Log-strukturiertes Dateisystem. Diese Art von Dateisysteme sind besonders
      für einen hohen Schreibdatenfluss geeignet. Alle Änderungen der Daten beziehungsweise
      Metadaten werden sequentiell an einen durchgängigen „Stream“ geschrieben, den soge-
      nannten LOG.
      2.5.1 Verbesserungen im Vergleich zu JFFS
      - NAND-Flash-Speicher Unterstützung
      - Hard Links Unterstützung
      - 3 Kompressionsmöglichkeit (zlib, rubin und rtime)
      - Bessere Performance
      2.5.2 Nachteile
      - Beim einhängen (mounten) müssen alle „Nodes“ gescannt werden. Das wird bei
      den immer weiter wachsenden Flash-Speichern allmählich zum Problem.
      - Beim Schreiben vieler kleiner Datenblöcke kann es zu ein negativen Kompression
      kommen.
      - Die Garbage-Collection verursacht ab und zu „Dead-Locks“.

      » time to say goodbye «

      Konfuzius sagt:
      Erst wenn eine Mücke auf deinen Hoden landet wirst du lernen Probleme ohne Gewalt zu lösen.