1. Nimm jetzt an unserem Uhans - 3. ADVENT - Gewinnspiel teil - Alle Informationen findest Du hier!

parameter

Dieses Thema im Forum "Odys Allgemein" wurde erstellt von fluxflux, 31.12.2011.

  1. fluxflux, 31.12.2011 #1
    fluxflux

    fluxflux Threadstarter Android-Experte

    Beiträge:
    845
    Erhaltene Danke:
    265
    Registriert seit:
    30.11.2011
    Diese Datei wird beim Erstellen des update.img oder beim direkten Flashen des Loox benötigt, damit das System den Speicher korrekt zuweist.

    Ich habe jetzt eine system.img, die ext3-gepackt ist, eine veränderte boot.img, die /system als ext3 mountet, das System bootet auch ein bisschen, dann geht es aer nicht weiter, da ich parameters nicht angepasst habe.

    Wie muss parameter

    Code:
    FIRMWARE_VER:0.2.3
    MACHINE_MODEL:rk29sdk
    MACHINE_ID:007
    MANUFACTURER:RK29SDK
    MAGIC: 0x5041524B
    ATAG: 0x60000800
    MACHINE: 2929
    CHECK_MASK: 0x80
    KERNEL_IMG: 0x60408000
    COMBINATION_KEY: F,0,1
    CMDLINE: console=ttyS1,115200n8n androidboot.console=ttyS1 init=/init initrd=0x62000000,0x500000 mtdparts=rk29xxnand:0x00002000@0x00002000(misc),0x00004000@0x00004000(kernel),0x00002000@0x00008000(boot),0x00004000@0x0000A000(recovery),0x00040000@0x0000E000(system),0x00042000@0x0004E000(backup),0x0003a000@0x00090000(cache),0x00240000@0x000ca000(userdata),0x00002000@0x0030a000(kpanic),-@0x0030c000(user)
    
    verändert werden, wenn meine neue system.img 256 MB groß ist. Denn diese Variante passt offensichtlich nicht, obwohl sie von mkupdate erstellt wurde.

    Ich denke, dass dann ein gerootetes, schreibbares Loox möglich ist ...

    Danke für jede Hilfe,

    Thomas.
     
    Zuletzt bearbeitet: 01.01.2012
  2. Oma7144, 01.01.2012 #2
    Oma7144

    Oma7144 Android-Guru

    Beiträge:
    2,914
    Erhaltene Danke:
    1,082
    Registriert seit:
    18.12.2011
  3. fluxflux, 01.01.2012 #3
    fluxflux

    fluxflux Threadstarter Android-Experte

    Beiträge:
    845
    Erhaltene Danke:
    265
    Registriert seit:
    30.11.2011
    Ich habe es gefixt, die Partition für /system war nur zu klein.

    Thomas.
     
  4. Käsebrot, 01.01.2012 #4
    Käsebrot

    Käsebrot Android-Hilfe.de Mitglied

    Beiträge:
    83
    Erhaltene Danke:
    13
    Registriert seit:
    17.11.2011
    Ich habe das gleiche Problem: system ist ext3 und das Teil fährt nicht ganz hoch. Was hast Du wo angepasst. Evtl läuft dann auch ICS.
    Danke im voraus.
    KB
     
  5. fluxflux, 01.01.2012 #5
    fluxflux

    fluxflux Threadstarter Android-Experte

    Beiträge:
    845
    Erhaltene Danke:
    265
    Registriert seit:
    30.11.2011
    Die Datei "parameter" muss lediglich hinsichtlich der Speichergröße des system.img angepasst werden.

    Ich habe 256 MB, daher habe ich den Eintrag

    0x00040000@0x0000E000(system)

    geändert in

    0x00100000@0x0000E000(system)

    und damit dann das Update-Image erstellt.

    Oder mit dem Flashtool einfach die neue system.img und parameters aufs Loox flashen

    Thomas.
     
    Zuletzt bearbeitet: 01.01.2012
  6. Oma7144, 01.01.2012 #6
    Oma7144

    Oma7144 Android-Guru

    Beiträge:
    2,914
    Erhaltene Danke:
    1,082
    Registriert seit:
    18.12.2011
    Drei Verständnisfragen:

    1) Der Boot-Prozess wird ja aus einem code angestoßen, der in der CPU hinterlegt ist. Inwieweit sind dort feste
    jumps hinterlegt, wo dann später der Anfang einzelner Partitionen zu finden ist? Ist das nur ein jump, um den
    Bootloader zu finden, der dann wiederum die anderen jumps setzt?

    2) Wenn dann der Bootloader in den RAM geladen ist und läuft, initiiert er ja die Hardwareumgebung (Memory,
    Filesystem, Netzwerk o.ä.). Wird hier schon die Sicherheitssequenz, die zu S-ON führt, mit initiiert, oder
    kommt die erst später im kernel?

    3) Warum eigentlich cramsf? Gibt es Phasen, wo es keine Möglichkeit gibt, code auszupacken um ihn auszuführen?


    :thumbup:
     
  7. wusel, 01.01.2012 #7
    wusel

    wusel Android-Experte

    Beiträge:
    656
    Erhaltene Danke:
    231
    Registriert seit:
    27.12.2011
    ich vermute mal aus 2 Gründen:
    1. Platz sparen durch Kompression
    2. es ist allgemein üblich auf Embedded Sytems das OS von einer R/O Partition zu starten und dann im RAM laufen zu lassen um die Flash-Speicher zu schonen; die Dinger haben eine begrenzte Lebensdauer die durch Schreiben stark verkürzt wird ...
     
  8. fluxflux, 01.01.2012 #8
    fluxflux

    fluxflux Threadstarter Android-Experte

    Beiträge:
    845
    Erhaltene Danke:
    265
    Registriert seit:
    30.11.2011
    Du meinst jetzt aber nicht mich!? :scared:

    Wenn ich das beantworten könnte, dann würde ich mit "Sowas" mein Geld verdienen ...

    Thomas.
     
  9. fluxflux, 01.01.2012 #9
    fluxflux

    fluxflux Threadstarter Android-Experte

    Beiträge:
    845
    Erhaltene Danke:
    265
    Registriert seit:
    30.11.2011
    Wo wird denn der Platz gespart oder bei ext3 verschwendet? Auf dem Flashspeicher = NAND?

    Nur zum Verständnis, dass ich mir auch ein Bild machen kann ...

    Danke,

    Thomas.
     
  10. Oma7144, 01.01.2012 #10
    Oma7144

    Oma7144 Android-Guru

    Beiträge:
    2,914
    Erhaltene Danke:
    1,082
    Registriert seit:
    18.12.2011
    Sorry, auch hierzu 'ne Nachfrage: auf dem gleichen NAND legt er doch das Filesystem an, um dann wie der Teufel zu schreiben ...


    :thumbup:
     
  11. fluxflux, 01.01.2012 #11
    fluxflux

    fluxflux Threadstarter Android-Experte

    Beiträge:
    845
    Erhaltene Danke:
    265
    Registriert seit:
    30.11.2011
    Ich habe wie auch auf anderen Flash-Speichern, auf denen ein Linux läuft, die /system mit noatime,nodiratime gemountet, was die Schreibzugriffe reduziert.

    Im übrigen denke ich nicht, dass der Flash-Speicher durch ein r/w-System kaputt geschrieben werden kann.

    Die Diskussion gab es ja bereits, als die ersten eeePCs mit Flash-Speicher aufkamen, da habe ich dann erklärt bekommen, dass der Flash-Speicher selbst bei täglichem Dauergebrauch das Leben des eeePCs um ein Vielfaches überdauern dürfte.

    Thomas.
     
  12. fluxflux, 01.01.2012 #12
    fluxflux

    fluxflux Threadstarter Android-Experte

    Beiträge:
    845
    Erhaltene Danke:
    265
    Registriert seit:
    30.11.2011
    Ich denke, dass ich die parameter-Datei jetzt verstanden habe.

    Die Zahl vor dem @ gibt die Speichergröße an, die danach den Offset. Ändere ich jetzt die system.img auf 256 MB, dann verschieben sich alle folgenden Offsets entsprechend. Das habe ich jetzt berücksichtigt und eine neue parameter erstellt, die so aussieht:

    Code:
    FIRMWARE_VER:0.2.3
    MACHINE_MODEL:Odys-Loox
    MACHINE_ID:007
    MANUFACTURER:RK29SDK
    MAGIC: 0x5041524B
    ATAG: 0x60000800
    MACHINE: 2929
    CHECK_MASK: 0x80
    KERNEL_IMG: 0x60408000
    COMBINATION_KEY: F,0,1
    CMDLINE: console=ttyS1,115200n8n androidboot.console=ttyS1 init=/init initrd=0x62000000,0x500000 mtdparts=rk29xxnand:0x00002000@0x00002000(misc),0x00004000@0x00004000(kernel),0x00002000@0x00008000(boot),0x00004000@0x0000A000(recovery),0x00100000@0x0000E000(system),0x00100000@0x0010E000(backup),0x0003a000@0x0020e000(cache),0x00100000@0x00248000(userdata),0x00002000@0x00348000(kpanic),-@0x0034a000(user)
    
    Wer kann mir den korrekten Hex-Code bestätigen?

    Danke,

    Thomas.
     
  13. Käsebrot, 01.01.2012 #13
    Käsebrot

    Käsebrot Android-Hilfe.de Mitglied

    Beiträge:
    83
    Erhaltene Danke:
    13
    Registriert seit:
    17.11.2011
    so wie ich das verstanden habe werden die Größen in 512 Byte Blöcken angegeben. Demnach wären 256 MB = 0x8000 (1024 * 1024 * 256 /512), so habe ich das zumindest verstanden. 0x100000 wären demnach 512 MB. Sollte sich aber leicht mit "df" im Zielsystem nachprüfen lassen.
     
  14. fluxflux, 01.01.2012 #14
    fluxflux

    fluxflux Threadstarter Android-Experte

    Beiträge:
    845
    Erhaltene Danke:
    265
    Registriert seit:
    30.11.2011
    df zeigt schon 256 MB an, das sollte also passen, allerdings bootet das Loox mit der parameter nicht!

    Ich verwende weiterhin die erste hier gepostete.

    Thomas.
     
  15. fluxflux, 03.01.2012 #15
    fluxflux

    fluxflux Threadstarter Android-Experte

    Beiträge:
    845
    Erhaltene Danke:
    265
    Registriert seit:
    30.11.2011
    Aktuell verwende ich die folgende parameter, die ich auch zum Flashen bzw. Erstellen des update.img hernehme:

    Code:
    FIRMWARE_VER:0.2.3
    MACHINE_MODEL:Odys-Loox
    MACHINE_ID:007
    MANUFACTURER:RK29SDK
    MAGIC: 0x5041524B
    ATAG: 0x60000800
    MACHINE: 2929
    CHECK_MASK: 0x80
    KERNEL_IMG: 0x60408000
    #COMBINATION_KEY: F,0,1
    CMDLINE: console=ttyS1,115200n8n androidboot.console=ttyS1 init=/init initrd=0x62000000,0x500000 mtdparts=rk29xxnand:0x00002000@0x00002000(misc),0x00004000@0x00004000(kernel),0x00008000@0x00008000(boot),0x00008000@0x00010000(recovery),0x00080000@0x00018000(backup),0x0003a000@0x00098000(cache),0x00100000@0x000d2000(userdata),0x00002000@0x001d2000(kpanic),0x00080000@0x001d4000(system),-@0x00254000(user)
    Läuft bisher problemlos mit der system.img auf ext3 rw gemountet.

    Thomas.
     
  16. Astralix, 04.01.2012 #16
    Astralix

    Astralix Android-Experte

    Beiträge:
    679
    Erhaltene Danke:
    411
    Registriert seit:
    25.12.2011
    Phone:
    bq Aquaris 5, bq Aquaris E5, bq Aquaris M5
    Tablet:
    Odys Iron, RK3288EVK, Sony Experia Z
    Ja, das ist richtig:
    1st Stage Bootloader ist fest in der CPU und lädt einen kleinen 2nd-Stage Bootloader aus anderen Speichern, die man per Jumper an der CPU konfigurieren kann, ins interne RAM der CPU.
    Der 2nd Stage Bootloader initialisiert das RAM und ggf. einen weiteren Speicher aus dem der nächste Code in RAM geladen wird.
    Warum? Der Chiphersteller kann ja nicht wissen, was für FLASH (parallel / seriell, Waitstattes, Bitbreite (8/16/32) und was für RAM (SRAM/DRAM DDR2 oder DDR3, Timing, welche Banks, wie viele Chips) sein Kunde verbaut.
    Also schiebt der Kunde seinen 2nd-Stage Bootloader nach, der RAM und Speicher initialisiert und den Code dahin kopiert, wo der Kunde ihn braucht. Damit bestimmt der Kunde auch den Bootvector.

    Dieser 2nd-Stage Bootloader lädt nun wiederum den 3rd-Stage Bootloader nach, der dann schon auf das funktionierende RAM und den Quell-Speicher zugreifen kann, aber nun nocht weitere Dinge tun kann, wie zum besipiel einen komprimierten Kernel ins RAM entpacken, einen Kernel von einer SD lesen uns ins Flash schreiben....

    Dann geht der 3rd-Stage Bootloader hin und entpackt den Kernel, prüft und startet ihn und wird dann irgendwann einfach von Anwendungen oder so überschrieben.

    Ich schreibe extra mal Quell-Speicher, weil man diese CPUs wirklich von verschiedenen Medien aus mit Code versorgen kann. Parallele oder serielle FLASH (MMC/SD oder eMMC) werden unterstützt aber der interne Bootloader akzeptiert auch das Download via Serielle oder USB.

    Nein, der 3rd-Stage Bootloader ist nach meinem Dafürhalten auf den Tablets schon das, was im Bootloader Image versteckt ist und es kann eigentlich nur den Kernel Starten, oder ein kleines Menü zur Verfügung stellen, um einen Rescue Kernel ala CWM zu starten. Aber es kann auch auf eine SD zugreifen und dort nach Images suchen und diese verifizieren und flashen.
    Der 3rd-Stage ist also das, was unter den Linux basierten Routern oder Navis oder Industrie-Steuerungen der UBoot oder das RedBoot machen.
    Ein stück Software um ein System zu initiieren, pflegen, flashen, sichern und auch zu starten.

    Nein, das cramfs wird vom Kernel dem Userspace transparent zur Verfügung gestellt. Sobald es gemounted ist, kann jede System/User Applikation darauf zugreifen, aber nur lesend. Die Kompression ist unsichtbar, allein der Kernel weiss davon.

    Wenn ich das aber richtig sehe, ist für das System doch 256 MB im MTD reserviert. Wen kratzt es denn, ob diese 256MB nun zu 60% (cramfs) oder zu 90% (ext3) ausgenutzt wird. Weg ist sie doch eh.

    Ich würde eher schauen, ob man nicht an anderer Stelle etwas mehr Speicher abknapsen kann. Ich habe übrigens noch garnicht mit gezählt, wie viele MB das Image in Summe auf die MTDs verteilt. In meinem Tablet ist ein 4GB Speicher Chip verlötet, ein hynix H27UBK-T2A und gleich neben ihm ist noch einmal Platz für einen davon. Und nein, ich meine 4GByte, denn der Chip ist ein 32GBit Typ. Sind die 4GB echt alle weg?

    So, ich hoffe, ich konnte etwas Klarheit in die Bootloader-Sequenz geben.
    Für mehr Details, bitte fragen, das ist schließlich ein Heimspiel ;)

    Gruß, Astralix
     
    Oma7144 bedankt sich.
  17. Oma7144, 04.01.2012 #17
    Oma7144

    Oma7144 Android-Guru

    Beiträge:
    2,914
    Erhaltene Danke:
    1,082
    Registriert seit:
    18.12.2011
    Many thanks. Und Danke für das Angebot!

    Hier hatte ich am 29.12. noch eine Frage: "Mich würde darüber hinaus noch das Thema Partitionen (wieviele und wofür) interssieren.
    Beispielsweise liegen die mitgelieferte Apps auf /system; hier "gewinnt" man keinen zusätzlichen Speicher durch Löschen von Apps,
    denn die Partition wird dadurch ja nicht kleiner."

    fluxflux hat am 03.01. die Frage nach der Belegung des 4 GB NAND aufgeworfen, die aber eher in die Richtung ging: wie
    setzt Linux unter / dev seine logischen Strukturen von Partitionen und Ressourcen? Ich würde die Frage erst mal so stellen:
    ist die Belegung dynamisch adressierbar oder muß man sich an die vom Hersteller "designte" Struktur (Größe, Anfangssektor) halten?

    Da wir hier unter parameters diskutieren und der bootloader (3rd) die Datei vor dem kernel lädt, kann man dann doch die Partitionen
    auf dem NAND so anlegen, wie man lustig ist?

    Und wenn man dann so eine Lösung wie die von Wendal hat (stock-system untouched auf /system, user-system und user-data auf
    /data, somit einfrierbar und jederzeit rückflashbar), dann kann man sich doch auch von / recovery verabschieden, denn da würde ja
    auch ggf. nur ein bootloader mit einem mini-kernel der ein UI zur Verfügung stellt, liegen, mit dem man dann saubermachen und rückflashen?

    Bin ich da ganz falsch?


    :thumbup:
     
    Zuletzt bearbeitet: 04.01.2012
  18. Käsebrot, 04.01.2012 #18
    Käsebrot

    Käsebrot Android-Hilfe.de Mitglied

    Beiträge:
    83
    Erhaltene Danke:
    13
    Registriert seit:
    17.11.2011
    @Astralix: auf das Angebot komme ich gerne zu:

    Folgende Situation: wenn ich das Xpress über USB anschließe sagt RKAndroidTool (RKAT) unter Windows immer "Found RKAndroid rock usb" auch wenn ich nur einen Reset mache (also ohne Menü-Taste -> entspricht glaube ich der Vol+ beim Loox). Ich kann das Xpress also Flashen aber es startet nicht mehr.

    Wenn beim RKAT den Loader anhakt und noch einen weiteren Punkt wird zuerst IDB gelöscht und neu geflash, dann startet das Tablet anscheinend neu und landet wieder automatisch (also ohne Zutun von aussen -> Menü-Taste) im "Flashmode" und der Rest wird geflasht.

    Es muß also intern ein Flag oder ähnliches geben, so dass der Loader nicht den "Rest" startet sondern in den "Flashmode" geht, oder der Loader erkennt, dass kein gültiges System vorhanden ist und geht deshalb in den Flash modus.

    Noch eines ist mir aufgefallen:

    Der Bereich mit dem Offset 0x610000 und höher lassen sich nicht beschreiben (ca. 3 GB). In welchen Bereich wird denn der Loader geschrieben ? Die Angabe vom Offset ist hier ja offen. Auch beim auslesen dieses Bereichs (rkflashtool unter linux) kommt ein sich anscheinend ständig wiederholender Bereich mit dem Text "USB" raus.

    Hat jemand dieses Phänomen (RKAT zeigt ständig "found" an und das Teil fährt nicht hoch) schon mal beobachtet ?

    KB
     
  19. Oma7144, 04.01.2012 #19
    Oma7144

    Oma7144 Android-Guru

    Beiträge:
    2,914
    Erhaltene Danke:
    1,082
    Registriert seit:
    18.12.2011
    Negativ. Auf den Loox kann ich flashen was ich will, der kommt immer wieder hoch.

    Wenn denn die Phasen 1 und 2 des bootens im SRAM des RK2918 ablaufen und die 2. Phase den externen RAM
    vorbereitet und dann den Code (also unsere boot.image) in den externen RAM schiebt, dann kann doch
    eigentlich diese flag nur im 2. bootlader sein? Wenn ich mal davon ausgehe (da EMI), daß der code für beide
    loader im Boot-ROM des RK2918 hinterlegt ist , dann darf es doch gar keinen "Brick" geben (es sei denn, der NAND
    ist korrupt)?


    :thumbup:
     
    Zuletzt bearbeitet: 04.01.2012
  20. Astralix, 04.01.2012 #20
    Astralix

    Astralix Android-Experte

    Beiträge:
    679
    Erhaltene Danke:
    411
    Registriert seit:
    25.12.2011
    Phone:
    bq Aquaris 5, bq Aquaris E5, bq Aquaris M5
    Tablet:
    Odys Iron, RK3288EVK, Sony Experia Z
    So, jetzt gerät der Thread etwas durcheinander :)

    Es gibt verschiedene Infos dazu bei den verschiedenen Foren. Aber das Loox/Express hat keine wirklich passende Verzeichnis Struktur zu den Beispielen. Es kann halt doch jeder irgendwie immer ein bisschen anders machen.
    Zu den Partitionen: Die MTD Angaben werden dem Kernel vom Bootloader (3rd-Stage) aus der Parameter Datei übergeben. Damit kann man diese beliebig verschieben, verglössern oder verkleinern.

    Nur der Bootloader muss an der richtigen Stelle wiedergefunden werden, und zwar alle Bootloader. Wobei der 1st-Stage ja in der CPU drinn ist und der 2nd Stage sich vermutlich am Anfang des FLASHes versteckt.
    Alle anderen MTD Partitionen können dann verändert werden.

    Ich bin mir nicht sicher, ob die Recovery nicht ein Bestandteil von Android ist. Das CWM residiert zum Beispiel dort und macht sich dort auch ganz praktisch. Es ist schließlich eine Sache, sein Tablet mit einem Custom oder Stock Flash zu beleben, oder mit einem kompletten Backup, welches man zurückspielt und damit auch gleich alle Apps.

    Es ist aber die Frage, ob das CWM wirklich volle 256MB braucht und nicht mit sehr viel weniger zurande kommt.

    Teile der Weisheit du bereits erlangt hast :)
     
    Oma7144 bedankt sich.

Diese Seite empfehlen