32 Antworten in diesem Thema

[Diggen]

Moin Moin,

ich weiß ich bin neu aber zu mir gibt es auch nicht viel zusagen. Achtet nicht umbedingt auf die Rechtschreibung :-P

Letzte/Vorletzte Woche hab ich mir bei Real eins der "Restbestands"-Smartpads von 1&1 geholt. Hab gedacht kann ja ganz lustig sein so ein Ding, auch wenn es veraltete Hardware ist. Außerdem hab ich mir gedacht da gibt es bestimmt den ein oder anderen lustigen Hack für ;-) Leider ist dem nicht so also hab ich mich kurzer Hand selbst auf die Suche gemacht in den Smartpad Eingeweiden und dabei meine eingerosteten Kenntnisse nen bisschen aufgefrischt ;-)

Ich möchte jetzt hier nicht anfangen mit - Was geht, Was geht nicht, Was könnte - davon gibt es genug Threads.
Also fang ich einfach mal beim NAND-Layout an und geh dann zum Boot, etc. Ich hoffe man versteht was ich schreibe.


ACHTUNG:
Leider muss ich das sagen...
Ich habe hier alles unbeschadet überstanden bzw. das Smartpad. Sollten die Infos hier aber aus irgenwelchen Gründen euer Smartpad, eure Kaffeemaschine oder sonstwas kaputt machen, Sorry. Ich habe alles nach besten Gewissen geschrieben und distanziere mich von Defekten.

Unter anderen möchte ich hier Kjeldor für seinen Thread (und unzähligen anderen) danken ohne Root währe meine Arbeit schwerer gewesen.

Inhalt
1 NAND-Layout
2.1 Das U-Boot - der Start
2.2 Der Kernel und Init
3.1 Der 1&1/KWest Update Process
4 Fazit

[Diggen]

NAND-Layout

# dmesg
...
<5>Creating 11 MTD partitions on "mp200_nand":
<5>0x000000000000-0x000000100000 : "boot_loaders"
<5>0x000000100000-0x000000200000 : "u-boot_env"
<5>0x000000200000-0x000000a00000 : "kernel_1"
<5>0x000000a00000-0x000001200000 : "kernel_2"
<5>0x000001200000-0x000019200000 : "rootfs_1"
<5>0x000019200000-0x000031200000 : "rootfs_2"
<5>0x000031200000-0x00003f000000 : "userfs"
<5>0x00003f000000-0x00003f400000 : "InfoLog_1"
<5>0x00003f400000-0x00003f800000 : "InfoLog_2"
<5>0x00003f800000-0x00003fc00000 : "FactoryParameter"
<5>0x00003fc00000-0x000040000000 : "BadBlockTable"
...

Wie man sieht ist eigentlich alles Wichtige doppelt vorhand (kernel, rootfs). "userfs" ist nur einmal vorhanden und bis auf die vorletzten drei (InfoLog_1,InfoLog_2,FactoryParameter) eigentlich alles ohne Erklärung verständlich.

boot_loaders - Ist der "Das U-Boot" Bootloader in einer modifizierten Variante, später mehr. Leider überhaupt nicht mit dem im NEC SDK zu vergleichen

u-boot_env - Sind einfach die Bootloader Parameter - Google->"U-Boot"

kernel_1 und kernel_2 - Ist ein uImage des Kernels passend zum Bootloader

rootfs_1, rootfs_2 und userfs - Ist jeweils ein UBIFS - Google->"UBIFS MTD" - ein andere Art mit MTD-Devices umzugehen und oben drauf ein Filesystem. Ähnlich yaffs2, cramfs und doch wieder anders da es nicht direkt auf die MTD-Devices zugreift sondern UBI als zwischen Layer hat. !!! MERKE UBI != UBFS !!! MTD <-> UBI <-> UBIFS !!!

FactoryParameter - Hier kommen wir zum ersten intressanten Teil. Dies ist auch RAW-Partition mit ein paar Werten.
Seriennummer,Wlan-MAC, etc. Sie kann mit /system/bin/ProductionDataTool ausgelesen werden.

Hier mal ein Hexdump: (Daten sind Beispiele)

# dd if=/dev/mtd/mtd9ro | busybox hexdump -C
00000000  SS SS SS SS SS SS SS SS  SS SS SS SS SS SS SS SS  |KW15412345678901|
00000010  SS MM MM MM MM MM MM MM  MM MM MM MM MM MM MM MM  |200:00:00:00:00:|
00000020  MM MM 31 31 31 31 31 31  31 31 31 31 31 31 00 b0  |00111111111111..|
00000030  IL IL IL IL ff ff ff ff  ff ff ff ff ff ff ff ff  |...U............|
00000040  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*
8192+0 records in
8192+0 records out
4194304 bytes transferred in 5.657 secs (741436 bytes/sec)
00400000

0x00-0x10 SS - Hier steht die Seriennr in ASCII, wie hinten auf dem Gerät
0x11-0x21 MM - Hier die Wlan-MAC. Sie wird wieso auch immer nach /mnt/system/etc/firmware/unifi-sdio-0/mac.txt exportiert bei einem Update.
0x22-0x2D 31 - Testdaten werden auch vom ProductionDataTool ausgelesen - Keine Ahnung aber auch nicht wirklich intressant.
0x2E-0x2F 00 b0 - Keine Ahnung
0x30-0x33 IL - Eine Kombination die anscheinend auch im InfoLog auftaucht, später mehr. Es währe Intressant ob es bei mir reiner Zufall ist. Unwahrscheinlich oder auch bei euch dort mit dem InfoLog identisch ist.


InfoLog_1 und InfoLog_2 - Sind beides auch wieder RAW. Doch Sie sind entscheidend für den Bootloader! Je nachdem welche Werte hier hinterlegt sind, wird entweder kernel_1 und rootfs_1 oder kernel_2 und rootfs_2 geladen.

InfoLog_1
# dd if=/dev/mtd/mtd7ro | busybox hexdump -C
00000000  NR 00 00 00 IL IL IL IL  00 00 00 00 IL IL IL IL  |.......U.......U|
00000010  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*
8192+0 records in
8192+0 records out
4194304 bytes transferred in 4.298 secs (975873 bytes/sec)
00400000
 
InfoLog_2
# dd if=/dev/mtd/mtd8ro | busybox hexdump -C
00000000  NR 00 00 00 IL IL IL IL  ff ff ff ff ff ff ff ff  |.......U.......U|
00000010  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*
8192+0 records in
8192+0 records out
4194304 bytes transferred in 4.384 secs (956729 bytes/sec)
00400000

0x00 NR - Ist anscheinend ein Counter. Er wird vom 1&1-Updater nach bzw. bei dem Update um 1 erhöht. 0x01,0x02,0x2,...
0x04-0x08 IL - Scheinen die 4 Byte aus der FactoryParameter zu sein.

0x09-0x0F - Beim ersten Start eines Roms ist dieser Bereich mit ff gefüllt. Nach dem ersten (erfolgreichen) Start
steht dort 00 00 00 00 IL IL IL IL . Dies wird anscheinend vom FirstBootVerifierDemon erledigt

[EDIT]
IL IL IL IL ist anscheinend bei allen AA CD AB 55 . Ein ändern der Werte führt zumindest dazu das der Bootloader die Partion als kaputt erkennt.
Danke an HOKE

[Diggen]

Das U-Boot - der Start

Leider ist der Bootloader von 1&1/KWest (stark) modifiziert worden im Gegensatz zum NEC SDK (und sie rücken "illegaler"-Weiße den Quellcode nicht heraus...)
Auch das der RAM wurde im gegensatz zum HDK/SDK erhöht und der NAND-Chip ist auch ein anderer. Dies kann man aber über dmesg und die u-boot_env leicht identifizieren.

Durch ein bisschen hin und her geboote kann man jedoch Rückschlüße ziehen wie das ganze Funktioniert. Es ist eigentlich ganz Simple ;-)

u-boot_env - Das relevante

...
bootfile=uImage
..
ext3_root=/dev/mmcblk0p3
...
bootcmd=auto
boot_file_system_1=setenv bootargs root=ubi0:rootfs rootfstype=ubifs ubi.mtd=4,4096 noinitrd init=/init console=ttyS0,115200n8n SELINUX_INIT=no $(cfg_ddr) rw video=qfb: ip=none;bootm 30007fc0
boot_file_system_2=setenv bootargs root=ubi0:rootfs rootfstype=ubifs ubi.mtd=5,4096 noinitrd init=/init console=ttyS0,115200n8n SELINUX_INIT=no $(cfg_ddr) rw video=qfb: ip=none;bootm 30007fc0
boot_android_sd=setenv bootargs root=$(ext3_root) noinitrd init=/init console=ttyS0,115200n8n SELINUX_INIT=no $(cfg_ddr) rw video=qfb: ip=none rootfstype=ext3 rootwait;bootm 30007fc0
cfg_ddr=mem=32M@0x30000000 mem=32M@0x34000000 mem=32M@0x36000000 mem=32M@0x38000000 mem=32M@0x3a000000 mem=32M@0x3c000000 mem=32M@0x3e000000
...

bootcmd=auto - ich gehe davon aus das auto ein irgendwo hinterlegtes U-Boot-Script ist (die U-Boot-Partition sieht komisch aus aber da bin ich nicht erfahren genug für mit U-Boot...)
cfg-ddr=... - Hier sieht man gut das einiges an RAM im gegensatz zum HDK hinzugekommen ist.

boot_file_system_1, boot_file_system_2 - Beim starten wird der Wert an der Stelle 0x00 von InfoLog_1 und InfoLog_2 ausgelesen, s. NR von oben. Sollte InfoLog_2:0x00 höher sein als InfoLog_1:0x00 (wie oben) wird kernel_2 und rootfs_2 geladen bzw. andersherum. Dies passiert, so denk ich im "auto-Script". Man sieht allerdings (ubi.mtd=4,4096 zu ubi.mtd=5,4096) ganz gut das der Kernel in der CMDLINE die jeweilige Root-Partition mitgegeben bekommt.
Wenn man beim Einschalten oder Reset (POWER lange drücken) die VOL-+ Taste gedrückt hält, bis die LED kurz Rot aufleuchtet wird das rootfs welches laut InfoLog den kleineren Wert hat gestartet. Dies erklärt wieso viele Leute glauben Sie könnten so einen Werksreset durchführen. Dies erlaubt uns aber auch gefahrlos Custom-Roms zu testen ;-) TADA!!!

bootm 30007fc0 - eigentlich der Part wo zum Kernel bzw. uImage gesprungen und Linux gestartet wird. Die Adresse liegt, wie man an cfg_ddr sieht am Anfang des RAMs.
Das uImage hat einen 64-Byte Header der CRC32 Checksum, copy-/load-Adresse, etc. beinhaltet. In den beiden Kernel_1 und Kernel_2 steht jeweils 0x30008000. Dort liegt der Kernel-Code nach dem uImage-Header bereits. Ich geh also davon aus, das dass auto-Script das uImage nach 0x30007fc0 ins RAM kopiert (aus NAND Speicher kann man nicht starten) und dann beim Sprung dort hin und nach dem parsen des uImages der Kernel mit sich selbst überschrieben und gestartet wird. Evtl. hat hier aber jemand mehr Ahnung als ich *grins

boot_android_sd - Dieser Part wird wahrscheinlich angesprungn wenn die InfoLog-Bereiche defekt sind. Ich hatte aber noch nicht das Vergnügen es ausprobieren zu müssen. Man sieht jedoch, das dass rootfs dann auf der 3.Partition der SDKarte gesucht wird. Im auto-Script wird dann wahrscheinlich das uImage von Partition 1 (FAT) ins RAM kopiert. Theoretisch kann Das U-Boot so etwas.

[Diggen]

Der Kernel und Init

Der Kernel läd beim starten keine initrd sondern das rootfs direkt von mtd4 oder mtd5 über UBI und UBIFS. Das rootfs liegt dabei immer auf UBI-Device 0. Es ist egal ob mtd4 oder mtd5 als rootfs eingebunden wird. Im Init wird dann das userfs mtd6 (/data) immer als UBI-Device 6 eingebunden.

[Diggen]

Der 1&1/KWest Update Process

Anscheinend wird sofort beim erkennen eines neuen Updates der nicht gebootete InfoLog-Bereich und entsprechender Kernel gelöscht.
Nach dem runterladen des berühmten android-fs.tar.gz. Wird der das nicht gebootete rootfs (nicht gerade NAND schonend) gelöscht ein neus UBI und UBIFS darauf erstellt und anschließend nach /flash gemountet. Dann wird das uImage von /flash/kernel/uImage geschrieben und /flash/system/etc/post.sh ausgeführt (welche aber, zumindest bei mir nicht das tut was sie soll ;-) ). Zuguter letzt wird der Infolog-Bereich mit " NR 00 00 00 IL IL IL IL ff ff ff ff ff ff ff ff " beschrieben. Wobei NR ein höher ist als der aktuelle. Beim neustart wird der Bootloader nun den neuen höheren InfoLog-Wert finden und das Update starten. Der FirstBootDemon wird dann das InfoLog um "00 00 00 00 IL IL IL IL" erweitern. Dies bestätigt wohl das der erste Bootvorgang erfolgreich abgeschloßen wurde...

Mit der VOL-+ Taste könnte man das alte System starten. Dummerweiße wird jedoch beim starten mit einer Internetverbindung sofort ein Update erkannt und Infolog gelöscht... und das wars mit dem neuen geupdateten System.

Dies kann man umgehen in dem man vor dem Neustart ins neue System, in der init.rc den UpdateProcess auskommentiert:

#service update /system/bin/UpdateProcess
#    socket update stream 0666

und unter /system/app die UpdateService.apk umbennent zb UpdateService.kpa
Ich denke das von 1&1 ehe keine Updates mehr kommen werden und das ganze laufen zu lassen ehe sinnlos wäre...

Nun hat man im Prinzip zwei System die man durch drücken oder nicht drücken der Vol-+ Taste starten kann. Da das Userfs nur einmal vorhanden ist werden natürlich die Daten von dort jedesmal mitgenommen. Was manchmal für Chaos sorgen kann ;-)

[Diggen]

Fazit
Der U-Boot Code ist zu stark modifiziert um ihn selber ändern und kompilieren zu können. Man sollte jedoch auch sehr gut mit dem vorhandenen leben können.

Der Kernel-Code ist auch modifiziert bzw. muss um das Speicherlayout des NAND und das mehr an RAM ans laufen zukriegen. Es sollte aber für jemand mit Erfahrung am Kernel möglich sein die mp200-* speziefischen Dateien anzupassen. So wie es aussieht hat 1&1/KWest den modifizierten Rest als Modul kompiliert. Mir ist es aufjedenfall gelungen ein CIFS Modul zu kompilieren und erfolgreich einzubinden. Dies sollte auch mit weiteren mit dem SDK Kernel klappen.

Android bekomm ich zwar kompiliert aber nicht gestartet. Jedoch ist A. Android Neuland für mich und B. weiß ich nicht ob ich die Patches vom SDK erfolgreich genug an 2.2/Froyo angepasst habe. Zumindest die Apks laufen im 1&1 System größtenteils.

Im Gegensatz zum U-Boot und Kernel Quellcode muss 1&1/KWest Ihre Änderungen dort aber nicht freigeben. Und die Handvoll Ihrer selbst geschriebenen Programme auch nicht. Doch nach dem Restbestand Verkauf an REAL denk ich wird es da ehe nicht mal mehr leere Versprechungen von 1&1/KWest geben. Hat jemand ne gute Rechtsschutz-Versicherung *lach

Im Prinzip habe ich sogar schon ein Tool/ash-Script geschrieben welches mit den Smartpad umgehen und relativ gefahrlos Custom-Roms, etc. flashen könnte. Durch die ungeklärte Sache mit den IL-Einträgen im Infolog und FactoryParameter würd ich es aber ungern in die freie Wildbahn entlassen.

Es währe also nett wenn mir ein paar von euch den Inhalt Ihrer InfoLog und FactoryParameter Partitionen posten könnten.
Am einfachsten wäre es mit Root und QuickSSHD aufs Smartpad zu gehen und folgendes zu tun:

# ash
# dd if=/dev/mtd/mtd9ro | busybox hexdump -C > /sdcard/mtd9.txt
# dd if=/dev/mtd/mtd8ro | busybox hexdump -C > /sdcard/mtd8.txt
# dd if=/dev/mtd/mtd7ro | busybox hexdump -C > /sdcard/mtd7.txt
# dd if=/dev/mtd/mtd1ro | busybox hexdump -C > /sdcard/mtd1.txt

Dies sollte vier Dateien auf der SDCARD hinterlasen die man hier posten oder mir schicken könnte.
Evtl. solltet Ihr vorher die mtd9.txt um SerienNr und MAC bereinigen, um auf Nr. sicher sicher zu gehen...

Intressiert wäre ich auch noch an einen Kompletten DUMP (ohne UserFS) von jemanden mit einen "alten" Smartpad mit Android 1.6. Einfach melden ich erklär dann wie.

Ich könnte auch noch das ein oder andere Detail vertiefen also fragt ruhig. Ich werd gucken das ich euch Antworte.

[resto]

Ich bin schwer beeindruckt von deinen Erkenntnissen, auch wenn ich rein gar nix davon verstehe.
Hoffentlich ergibt sich - unter Mithilfe anderer Sachkundiger - ein praktischer Nutzen daraus.

resto

[Kjeldor]

Jau das sieht ja mal interessant aus, auch wenn das für mich doch ne kleine nummer zu hoch ist...

Ich pinns mal an... Gute arbeit!

[HOKE]

Kommt man auch ohne QuickSSHD und als dummer GUI-user an die Infos?
Wenn ich /dev/mtd/ mit dem RootExplorer aufrufe ist der Ordner leer.

[Diggen]

Erst mal danke für das Festtackern ;-)

Ich kann es momentan nicht testen da ich auf der Arbeit bin aber es gibt auch für GUI-Benutzer einen Weg.
Einfach die angehängt Datei auf SDCard kopieren und z.b. mit dem Root-Exlorer ausführen (Anklicken, Execute wählen). Ich weiß jedoch nicht ob er das Script mit root Rechten ausführt.
Alternativ im Market den "Script Manager" downloaden. Dort auch das Script anklicken und im erscheinenden Dialog als Root auswählen.

Der Root-Explorer wird unter /dev nur Ordner anzeigen weil dort im Prinzip keine echten Dateien liegen sondern "Devices", verknüpfungen zu "Geräten" des Smartpads.

[EDIT]
Laut HOKE funktioniert es nicht mit dem Root Explorer. Dies kann ich bestätigen.
Mit dem Script Manager funktionierts jedoch super.

dumpmtd2hex2.txt Hochgeladen - Es wird nur noch einr SmartPadInfo.txt auf der SDCard erstellt und es werden noch die aktuelle Kernel cmdline / mtd-Layout und dmesg angehängt.

Angehängte Dateien

•  dumpmtd2hex.txt (271bytes)
  Heruntergeladen: 10
•  dumpmtd2hex2.txt (652bytes)
  Heruntergeladen: 5

[beohna]

Diggen sagte:

Mir ist es aufjedenfall gelungen ein CIFS Modul zu kompilieren und erfolgreich einzubinden. Dies sollte auch mit weiteren mit dem SDK Kernel klappen.

Daran hätte ich und sicher einige andere auch Interesse. Vielleicht kannst du das Modul zur Verfügung stellen. Am besten gleich mit einer Anleitung wie man so was verwendet/installiert.

Für eine sinnvollen Einsatz bräuchte man meines Wissensauch noch eine tun.ko (UTF-8 Unterstützung) - kenne mich aber leider nicht gut genug damit aus.

[Diggen]

beohna sagte am 23 August 2011 - 09:01 :

Daran hätte ich und sicher einige andere auch Interesse. Vielleicht kannst du das Modul zur Verfügung stellen. Am besten gleich mit einer Anleitung wie man so was verwendet/installiert.

Für eine sinnvollen Einsatz bräuchte man meines Wissensauch noch eine tun.ko (UTF-8 Unterstützung) - kenne mich aber leider nicht gut genug damit aus.

Eigentlich wollte ich schon im anderen Thread antworten aber ja die cifs.ko kann ich natürlich zurverfügung stellen, UTF-8 support mit dabei.
Das tun Modul ist dafür jedoch meines wissen nicht nötig. Es wird für VPN benötigt.

[HOKE]

Mit dem Scriptmanager als Root ausführen ging, alles andere bekommt keine Berechtigung.

Angehängte Dateien

•  mtd1.txt (8,27K)
  Heruntergeladen: 3
•  mtd7.txt (169bytes)
  Heruntergeladen: 3
•  mtd8.txt (169bytes)
  Heruntergeladen: 4
•  mtd9.txt (406bytes)
  Heruntergeladen: 3

[Diggen]

HOKE sagte am 23 August 2011 - 16:08 :

Mit dem Scriptmanager als Root ausführen ging, alles andere bekommt keine Berechtigung.

Danke HOKE!
Kann es sein das du gerade ein Update durchführst bzw. durchgeführt hast?
Du hast aber schon mehrer Updates mit dem Smartpad durchgeführt?

Die Daten sind zwar nicht ganz so wie ich gedacht habe aber helfen mir weiter :-)
Wärst du so nett und kannst das ganze noch mal mit dem 2ten Script (oben im Beitrag) durchführen?

Wenn es dir nichts ausmacht
Normal Booten - Script ausführen - SmartPadInfo.txt sichern
Boot mit VOL+ - Script ausführen - SmartPadInfo.txt sichern
Normal Booten Script ausführen - SmartPadInfo.txt sichern
Ganz wichtig Wlan-Router ausmachen oder Internet trennen damit er beim Boot mit VOL+ kein Update macht. Dann sollte eigentlich nix passieren. Es könnte jedoch sein das der 1&1-Updatemanger dein aktuelles System zerschießt und du doch nen Update machen musst.

Es würde mir aber auch Helfen wenn du einmal neustartest und das 2te Script dann nochmal ausführst.
Dank dir nochmal.

[HOKE]

Mindestens 3 Updates ist normal, einmal von 1.6 auf 2.2 und dann noch zwei kleine. Rumgespielt hab ich sowieso reichlich um dies und das ans laufen zu kriegen. Das gerade ein Update ausgeführt wird wüsste ich nicht.
Ich bin mir nicht sicher ob das nun mit dem Vol+ geklappt hat; Ich habs gedrückt gehalten, eingeschaltet und die LED wurde rot, danach passierte nichts bis ich Vol+ wieder losgelassen hab. Dann wurde gebootet und es sah alles normal aus, das würde aber passen wenn dadurch bloß der Stand von vor dem Miniupdate geladen wurde.

Angehängte Dateien

•  1SmartPadInfo.txt (24,89K)
  Heruntergeladen: 6
•  2SmartPadInfo.txt (24,42K)
  Heruntergeladen: 3
•  3SmartPadInfo.txt (24,42K)
  Heruntergeladen: 3

[Diggen]

HOKE sagte am 24 August 2011 - 18:04 :

Mindestens 3 Updates ist normal, einmal von 1.6 auf 2.2 und dann noch zwei kleine. Rumgespielt hab ich sowieso reichlich um dies und das ans laufen zu kriegen. Das gerade ein Update ausgeführt wird wüsste ich nicht.
Ich bin mir nicht sicher ob das nun mit dem Vol+ geklappt hat; Ich habs gedrückt gehalten, eingeschaltet und die LED wurde rot, danach passierte nichts bis ich Vol+ wieder losgelassen hab. Dann wurde gebootet und es sah alles normal aus, das würde aber passen wenn dadurch bloß der Stand von vor dem Miniupdate geladen wurde.

Dank dir, ich hatte mein Pad von Real bereits mit 2.2 bekommen und es hat nur ein Update gemacht. Dein höchster Wert im InfoLog ist 0x05 (der ander 0x04). Folglich müssten sogar vier Updates erfolgt sein

0x01 0xFF Ursprung
0x01 0x02 Nach Update 1
0x03 0x02 Nach Update 2
0x03 0x04 Nach Update 3
0x05 0x04 Nach Update 4 - Dein Stand ;-)

Das passt perfekt zu meinen Vermutungen.

Anscheinend hat das booten mit Plus nicht geklappt...
Er hat beides mal Update 4 gestartet.

Am besten klappt es, wie folgt:

• VOL+ gedrückt halten.
  
• POWER gedrückt halten bis das Pad ausgeht und die LED Rot wird.
  
• POWER los lassen.
  
• VOL+ los lassen

Wenn du das nochmal Testen könntest, bitte :-)



Du kannst kontrollieren ob es funktioniert hat in dem du mit dem Root Explorer einfach mal im Root-Verzeichniss / (dort befindet sich auch die init.rc, etc) einfach eine Datei anlegst. Beim erfolgreichen Boot mit VOL+ sollte sie nicht da sein. Den er hat die andere Partition zum starten genommen.

Danke nochmal für deine Hilfe sie bringt uns einem Custom-Rom näher :-)
Jetzt muss ich nur noch sinnvoll und funktionsfähig Android kompiliert bekommen ;-)

[HOKE]

Klappt alles nicht, die Datei bleibt.

[Diggen]

HOKE sagte am 24 August 2011 - 19:01 :

Klappt alles nicht, die Datei bleibt.

Dank dir. Ich hab es mit deinen Daten auf meinen Pad nachgestellt und kann dir sagen es liegt nicht an dir. Bei mir funktioniert es auch nicht.


1&1/KWest haben sich da einen groben Schnitzer gleistet! Das kann nicht gewollt sein. Man kann nämlich dadurch nur nach einer ungeraden Zahl Updates zurück. Dies würde auch erklären wieso bei manchen Leuten der Tipp mit boote mal mit VOL+ nicht klappt. Ich mein diesen hätte ich sogar im 1&1-Blog/FAQ gelesen.

Anscheinend wird immer der höhere Wert im InfoLog gebootet (bei dir Partition 1, bei mir weil nur 1 Update Partition 2). mit Vol+ kann man nur zurück wenn InfoLog 1 kleiner als InfoLog 2 ist.
Das macht die Sache wieder komplizierter da man nicht immer ohne weiteres zurück kann...

[Diggen]

Sorry irgendwie spinnt mein Browser...
[EDIT]
OK hat schonmal einer daran gedacht mit VOL- zu booten *lach Das mit dem groben Schnitzer nimm ich zurück!

HOKE könntest du nochmal mit VOL-(LED Blau) Booten und gucken ob die Datei noch da ist? ;-)
Bei mir scheint es zu klappen.

[HOKE]

Ah ja, auf die Idee bin ich tatsächlich schon gekommen, nur kam ich noch nicht dazu es zu probieren.

Bitte.

Angehängte Dateien

•  SmartPadInfoVol-.txt (24,42K)
  Heruntergeladen: 4
•  SmartPadInfoNormal.txt (24,42K)
  Heruntergeladen: 4