S
switchgott
Dauergast
- 107
Hi Perpe,
mach den Threat mal bitte zu.
Gruß
mach den Threat mal bitte zu.
Gruß
Zuletzt bearbeitet:
P
perpe
Gast
STOP!!!!
Du kannst nicht einfach so eine Recovery für ein anderes Gerät flashen. Hast du dich auch nur ansatzweise ernsthaft mit Android, dem Memo Pad FHD und/oder dem Galaxy Tab 3 10.1 auseinandergesetzt?
Ein Flashen der Recovery vom Tab 3 auf das Memo Pad FHD würde höchstwahrscheinlich zu einem Brick und schlimmeres führen.
Das beide Geräte eine x86 Architektur haben heißt nicht das sie identisch sind!
Samsung nutzt auf dem Tab 3 den ihren eigenen Bootloader mit Standard Android Recovery- und Bootpartition, sie haben also das Format wie die meisten anderen Android Geräte.
Unser Memo Pad nutzt jedoch eigen Entwicklungen von Intel, das fängt damit an dass der interne Speicher in gpt Partitioniert ist, der Intel Droidboot zum Einsatz kommt. Die Recovery-, Boot- und Droidboot IMG Formate weichen erheblich von den für andere Androiden ab. Bestehend aus einer Signatur, bzImage, Ramdisk und weiteren Informationen. Gespeichert werden sie nicht wie gewöhnlich auf separaten Partitionen sondern auf einer "Superpartition" (=EFI) als Datastreams plus ein Eintrag ins Bootmenu.
Eine Custom Recovery erzwingen zu wollen, bringt dir absolut rein gar nichts. Du solltest dich schon mit der elementaren Funktionsweise und Aufbau des Systems auseinandersetzen bevor du auf den Gedanken kommst irgendetwas zu flashen, das so tief ins System eingreift.
Wenn du die Entwicklung von anderen Geräten beobachten willst, dann schau die das Lenovo K900 an oder die anderen Asus x86 Android Geräte.
Du kannst nicht einfach so eine Recovery für ein anderes Gerät flashen. Hast du dich auch nur ansatzweise ernsthaft mit Android, dem Memo Pad FHD und/oder dem Galaxy Tab 3 10.1 auseinandergesetzt?
Ein Flashen der Recovery vom Tab 3 auf das Memo Pad FHD würde höchstwahrscheinlich zu einem Brick und schlimmeres führen.
Das beide Geräte eine x86 Architektur haben heißt nicht das sie identisch sind!
Samsung nutzt auf dem Tab 3 den ihren eigenen Bootloader mit Standard Android Recovery- und Bootpartition, sie haben also das Format wie die meisten anderen Android Geräte.
Unser Memo Pad nutzt jedoch eigen Entwicklungen von Intel, das fängt damit an dass der interne Speicher in gpt Partitioniert ist, der Intel Droidboot zum Einsatz kommt. Die Recovery-, Boot- und Droidboot IMG Formate weichen erheblich von den für andere Androiden ab. Bestehend aus einer Signatur, bzImage, Ramdisk und weiteren Informationen. Gespeichert werden sie nicht wie gewöhnlich auf separaten Partitionen sondern auf einer "Superpartition" (=EFI) als Datastreams plus ein Eintrag ins Bootmenu.
Eine Custom Recovery erzwingen zu wollen, bringt dir absolut rein gar nichts. Du solltest dich schon mit der elementaren Funktionsweise und Aufbau des Systems auseinandersetzen bevor du auf den Gedanken kommst irgendetwas zu flashen, das so tief ins System eingreift.
Wenn du die Entwicklung von anderen Geräten beobachten willst, dann schau die das Lenovo K900 an oder die anderen Asus x86 Android Geräte.
Zuletzt bearbeitet von einem Moderator:
S
smerz
Neues Mitglied
- 0
Ich weiss zwar nicht worum es ging, aber so wirkliches vertrauen bekommt man da nicht in die How To Root Anleitung.
P
perpe
Gast
Das hat weder was mit dem Root noch der Anleitung dazu zu tun. Die ist soweit schon richtig, das hat switchgott auch ganz gut gemacht.
Er stellt hier auch nichts bereit, was er nicht selbst ausgiebig getestet hat. Das er versucht eine Recovery zum Laufen zu bekommen und sich darin bemüht ist auch nicht als gering zu betrachten. Nur ist manchmal eine "drastischere Wortwahl" nötig um einen vor größeren Fehlern zu bewahren. Den Schaden davon hätte er gehabt und nicht ihr. Ich gehe mal davon aus, dass er genauso viel für sein Tablet geblecht hat wie wir.
@switchgott
Schade, dass du den Inhalt gelöscht hast. Eine ernsthafte Diskussion, wie es mit der Entwicklung für das Tablet ausschaut hätte keinem geschadet.
Wenn du den Thread geschlossen haben möchtest, dann nutze bitte die Melden Funktion oder wende dich an den Moderator. Ich bin keiner mehr
Er stellt hier auch nichts bereit, was er nicht selbst ausgiebig getestet hat. Das er versucht eine Recovery zum Laufen zu bekommen und sich darin bemüht ist auch nicht als gering zu betrachten. Nur ist manchmal eine "drastischere Wortwahl" nötig um einen vor größeren Fehlern zu bewahren. Den Schaden davon hätte er gehabt und nicht ihr. Ich gehe mal davon aus, dass er genauso viel für sein Tablet geblecht hat wie wir.
@switchgott
Schade, dass du den Inhalt gelöscht hast. Eine ernsthafte Diskussion, wie es mit der Entwicklung für das Tablet ausschaut hätte keinem geschadet.
Wenn du den Thread geschlossen haben möchtest, dann nutze bitte die Melden Funktion oder wende dich an den Moderator. Ich bin keiner mehr
S
smerz
Neues Mitglied
- 0
Das er sein Tablet "riskiert" ist ja schön, und das er seine Erfahrungen weitergibt ist ihm ebenso gut zu halten.
Nur sehe ich zumindest meine persönliche Meinung hier bestätigt, wie bei einem Post zu Anfang des Themas MeMo Pad FHD 10. Da wird alles durchprobiert was möglich ist (auch für gänzlich andere devices: nicht zum Lücke finden, sondern weil sie ANDERE erstellt haben), und an allen ecken und Foren herumgefragt, ob es schon was gibt. Und wenn dann tatsächlich mal was klappt, ggf. sogar aus anderen Quellen übernommen, dann werden sie vielleicht auch für die "eigenen" ausgegeben.
Und da sehe ich schon gefahr für User wenn es irgendwie mit gefummel dann doch klappt, und andere das ihm nachtun.
Ich selbst arbeite in der IT, und wenn ich mich mit etwas komplizierterem, umfangreicherem auseinandersetze, wie z.B. mit einer Unternehmenszertifizierungsstelle, dann kann ich natürlich solange rumfummeln und an Einstellungen und Berechtigungen herumstellen bis das funktioniert, was funktionieren soll - ob ich dabei aber die ganze Konfiguration so offen wie ein Scheunentor verhunzt habe, kann ich nicht sagen, wenn ich nicht weiss was ich tu.
Und so seh ich das Grundsätzlich auch hier;
Anleitungen werden Hauptsächlich von Leuten gelesen, die wenig Hintergrundwissen haben, und nur zum Endergebnis kommen wollen.
Von Ihnen werden aber keine geschrieben.
Ich möchte hier nicht rumstänkern, und die Arbeit in allen Ehren. Aber man sollte - aller "auf eigene Gefahr"-Warnungen zum Trotz, sich schon darauf verlassen, das ein User weiss was er tut, wenn er erklärt wie andere es tun sollen.
Ich hab 0 Ahnung von Android. Mein Defy hat nen Custom Rom, auch weil die Anleitungen dazu so detailliert und verständlich sind. Mein MeMo werd ich bis auf weiteres aber nicht einmal rooten, weil ich da kein Vertrauen zu habe.
Nur sehe ich zumindest meine persönliche Meinung hier bestätigt, wie bei einem Post zu Anfang des Themas MeMo Pad FHD 10. Da wird alles durchprobiert was möglich ist (auch für gänzlich andere devices: nicht zum Lücke finden, sondern weil sie ANDERE erstellt haben), und an allen ecken und Foren herumgefragt, ob es schon was gibt. Und wenn dann tatsächlich mal was klappt, ggf. sogar aus anderen Quellen übernommen, dann werden sie vielleicht auch für die "eigenen" ausgegeben.
Und da sehe ich schon gefahr für User wenn es irgendwie mit gefummel dann doch klappt, und andere das ihm nachtun.
Ich selbst arbeite in der IT, und wenn ich mich mit etwas komplizierterem, umfangreicherem auseinandersetze, wie z.B. mit einer Unternehmenszertifizierungsstelle, dann kann ich natürlich solange rumfummeln und an Einstellungen und Berechtigungen herumstellen bis das funktioniert, was funktionieren soll - ob ich dabei aber die ganze Konfiguration so offen wie ein Scheunentor verhunzt habe, kann ich nicht sagen, wenn ich nicht weiss was ich tu.
Und so seh ich das Grundsätzlich auch hier;
Anleitungen werden Hauptsächlich von Leuten gelesen, die wenig Hintergrundwissen haben, und nur zum Endergebnis kommen wollen.
Von Ihnen werden aber keine geschrieben.
Ich möchte hier nicht rumstänkern, und die Arbeit in allen Ehren. Aber man sollte - aller "auf eigene Gefahr"-Warnungen zum Trotz, sich schon darauf verlassen, das ein User weiss was er tut, wenn er erklärt wie andere es tun sollen.
Ich hab 0 Ahnung von Android. Mein Defy hat nen Custom Rom, auch weil die Anleitungen dazu so detailliert und verständlich sind. Mein MeMo werd ich bis auf weiteres aber nicht einmal rooten, weil ich da kein Vertrauen zu habe.
P
perpe
Gast
Hier wird aber auch keiner alleine gelassen. Es sind einige erfahrene User anwesend, die dann auch eingreifen, wenn was nicht stimmt bzw. in Ordnung ist und auch gegenprüfen.
Wenn jemand ohne Ahnung meint, etwas sofort flashen zu müssen, dann darf man sich auch an die eigene Nase fassen.
Ohne das wer etwas liefert und andere es testen, geht es nun mal auch nicht voran. Wer unerfahren ist, muss dann eben die Geduld aufbringen zu warten und es von anderen ein Ok gibt. So viel Eigenverantwortung muss man schon haben.
Mit der deinen Haltung gäbe es nun mal auch keine Entwicklung.
Ohne Trial and Error auch keine Entwicklung.
Und manchmal, wenn man etwas unbedingt will, ist man da auch zu stürmisch, zu fixiert und sitzt dann auch mal fest. Aber weißt du was, auch das gehört dazu, vor allem wenn man versucht sich ein neues Gebiet zu erschließen. Deswegen halte ich mich auch im Hintergrund und mische mich in seine Art das Hinzubekommen auch nicht ein. Er hat das Interesse und Engagement, ist mir jedoch bisher zu fixiert. Wenn er soweit ist, noch mal bei 0 anzufangen und die Energie konstruktiv zu nutzen, könnte ich ihm einiges erzählen, was ihn und auch andere deutlich weiter bringen könnte (ja, auch andere setzen sich mit dem Gerät und der Entwicklung auseinander)
Wenn jemand ohne Ahnung meint, etwas sofort flashen zu müssen, dann darf man sich auch an die eigene Nase fassen.
Ohne das wer etwas liefert und andere es testen, geht es nun mal auch nicht voran. Wer unerfahren ist, muss dann eben die Geduld aufbringen zu warten und es von anderen ein Ok gibt. So viel Eigenverantwortung muss man schon haben.
Mit der deinen Haltung gäbe es nun mal auch keine Entwicklung.
Ohne Trial and Error auch keine Entwicklung.
Und manchmal, wenn man etwas unbedingt will, ist man da auch zu stürmisch, zu fixiert und sitzt dann auch mal fest. Aber weißt du was, auch das gehört dazu, vor allem wenn man versucht sich ein neues Gebiet zu erschließen. Deswegen halte ich mich auch im Hintergrund und mische mich in seine Art das Hinzubekommen auch nicht ein. Er hat das Interesse und Engagement, ist mir jedoch bisher zu fixiert. Wenn er soweit ist, noch mal bei 0 anzufangen und die Energie konstruktiv zu nutzen, könnte ich ihm einiges erzählen, was ihn und auch andere deutlich weiter bringen könnte (ja, auch andere setzen sich mit dem Gerät und der Entwicklung auseinander
)
S
switchgott
Dauergast
- 107
- Themenstarter
- #7
Hi zusammen,
so nun melde ich mich auch mal zu Wort.
Ja, auch ich bin nicht allwissend :-(
Was die Partition von Intel und Samsung angeht habe ich einen Fehler gemacht!
Ich habe meinen Beitrag extra gelöscht, damit hier keiner auf dumme Gedanken kommt.
Werde mich nun genauer informieren.
Was das rooten des Tabs angeht, braucht man keine Bedenken zu haben,
wenn man die Anleitung befolgt!
Da aber immer etwas passieren kann, auch beim Flashen, muss jeder selbst wissen, ob er das Risiko eingehen möchte!
LG
so nun melde ich mich auch mal zu Wort.
Ja, auch ich bin nicht allwissend :-(
Was die Partition von Intel und Samsung angeht habe ich einen Fehler gemacht!
Ich habe meinen Beitrag extra gelöscht, damit hier keiner auf dumme Gedanken kommt.
Werde mich nun genauer informieren.
Was das rooten des Tabs angeht, braucht man keine Bedenken zu haben,
wenn man die Anleitung befolgt!
Da aber immer etwas passieren kann, auch beim Flashen, muss jeder selbst wissen, ob er das Risiko eingehen möchte!
LG
S
smerz
Neues Mitglied
- 0
@perpe: Doch doch, ohne trial and error komme auch ich nicht weiter.
Nur gebe ich mich nicht beim erstbesten, geglückten Versuch zufrieden.
Nur gebe ich mich nicht beim erstbesten, geglückten Versuch zufrieden.
P
perpe
Gast
@switchgott
Es geht nicht um unwissend. Du hast sicher schon viele Threads bei XDA und co. gelesen. Wissen über Android bringt dich am Anfang nicht viel weiter. Wie du gesehen hast, beißen sich an den x86 Geräten auch die Profis die Zähne aus, da sie an vielen Stellen anders funktionieren. Die gewohnten Methoden und Weg sind dann halt nicht wirklich zielführend.
Man muss dann eben erst etwas Abstand nehmen.
Erste Frage, die man für sich beantworten sollte ist: Wie funktioniert das Gerät, wie ist die Speicherverwaltung? Mit DD den internen Speicher auf SD spiegeln und es dann mal analysieren und Erkenntnisse daraus ziehen ist ein Muss.
Danach sollte man versuchen das original Boot.img zu entpacken, da das Recovery Image das selbe Format hat. Hier helfen einem die Entwicklung bei Razr I und ZTE Grand X weiter, gibt jedoch erhebliche Unterschiede. Razr I ist die 1. Version ohne Sicherheitsfeatures -> ZTE Grand X Weiterentwicklung jedoch noch ohne GPT und mit geringen Sicherheitsfeature -> und das vom Memo Pad FHD baut darauf auf, also Fortentwicklung mit GPT und Signierungen. Ein Hex Editor ist dabei dein bester Freund.
Entpacken kann ich inzwischen, beim Verpacken fehlen mir paar Bytes so das ein Flashen noch nicht geht.
Wenn man das kann, geht es darum die original recovery.img zu erhalten. Dazu sollte man vorher die 1. Partition und das boot.img untersucht haben, aus dem was man aus dem boot.img gelernt hat, kann man mit einem Hex Editor die Bytes in der 1. Partition finden, die den beginn eines neuen .img darstellen. So kann man die unterschiedlichen Images, also boot, droidboot, recovery extrahieren und auch entpacken. Damit gelangt man an die fstab der recovery.
Bringt einen jedoch nicht viel weiter, da die einzelnen Teile dort ohne Header sind. recovery.img kann man jedoch auf dem Gerät erzeugen. boot.img und recovery-from-boot.p auf Gerät kopieren, mit den Angaben aus install-recovery.sh applypatch ausführen(wie man das benutzt spuckt es im Terminal aus), dann hat man die original Recovery im img Format. Kannst gefahlos flashen.
Mit all dem was man daraus hat, kann man auch schon die CWM kompilieren, jedoch ist es nicht flashbar. Kompilieren von CWM läuft nicht durch, da nicht für x86 angepasst. Im Gerrit von CM findet man jedoch die nötigen Patches. Dann lässt es sich auch kompilieren.
Problem ist also im Moment bei mir das Erstellen den recovery.img da mit dort paar Bytes fehlen bzw. ich sie für das neue Image nicht neu erstellen kann.
So viel mal zum Erstellen einer Recovery. Als Kernel sollte man immer den orginal Kernel nehmen. Wenn man boot.img und co. extrahiert, erhält man ihn.
Nun geht es dir auch um einen Custom Kernel. Das der Kernel signiert ist, weißt du inzwischen.
Ein Custom Kernel würde uns auf dem Memo Pad FHD kaum was bringen. Natürlich, wäre ein nice to have, jedoch kennt sich kaum einer mit der ATOM SoC Plattform aus. Einfach mal Kernel Patches von anderen zum Über-/Untertakten wäre damit nicht möglich und alles andere als zu empfehlen. Gerade vom Untertakten mit einem Custom Kernel ist abzuraten, da Intel mit den SoC neue Sleepstates eingeführt hat. Da sollte man ganz genau wissen was man macht und sich sehr gut mit der Kernelentwicklung auskennen.
Was bleibt sind Kernel Module, auch wenn der Kernel signiert ist kann man unsignierte laden (tainted). Die defconfs im Kernel Source sind zwar unvollständig, mit etwas versuchen bekommt man jedoch sie soweit hin, dass kompilierte Module auch vom Kernel geladen werden.
Wenn wir schon beim Kernel sind, dann sollte man sich auch mal die Zeit nehmen sich mit Kexec auseinander zu setzen (ich hatte noch nicht die Zeit), da der Kernel Kexec fähig ist.
Mit Kexec kann man einen Kernel und Ramdisk laden ohne sie geflasht zu haben. Bei Sourceforge kann man auch die Kexec Tools für den Razr I finden (razr-i | Free Communications software downloads at SourceForge.net) sind also schon auf ATOM SoC angepasst. Wenn man also einen Stock Kernel extrahiert hat und die Ramdisk für eine Custom Recovery könnte es möglich sein so von Android aus in eine temporäre Recovery (also ohne sie installiert zu haben) zu booten. Von mir noch nicht getesten, gut möglich das da auch ein Sicherheitsfeature greift und den boote verhindert. Wenn es jedoch klappen sollte, hat man wenigstens eine "halbe" Recovery. Um das zu Testen muss man CWM nicht kompilieren, hier ist die Galaxy Tab 3 Recovery nützlich. Ihre Ramdisk entpacken, fstabs vom Memo Pad FHD nehmen, verpacken. Für einen Testlauf genügt es.
Ich denke, das sind jetzt ganz viele Informationen und Anhaltspunkte. Nutze sie um dich in die Richtung einzulesen.
@smerz
Switchgott doch auch nicht, ansonsten würde er wohl kaum Monatelang dahinter sein
Es geht nicht um unwissend. Du hast sicher schon viele Threads bei XDA und co. gelesen. Wissen über Android bringt dich am Anfang nicht viel weiter. Wie du gesehen hast, beißen sich an den x86 Geräten auch die Profis die Zähne aus, da sie an vielen Stellen anders funktionieren. Die gewohnten Methoden und Weg sind dann halt nicht wirklich zielführend.
Man muss dann eben erst etwas Abstand nehmen.
Erste Frage, die man für sich beantworten sollte ist: Wie funktioniert das Gerät, wie ist die Speicherverwaltung? Mit DD den internen Speicher auf SD spiegeln und es dann mal analysieren und Erkenntnisse daraus ziehen ist ein Muss.
Danach sollte man versuchen das original Boot.img zu entpacken, da das Recovery Image das selbe Format hat. Hier helfen einem die Entwicklung bei Razr I und ZTE Grand X weiter, gibt jedoch erhebliche Unterschiede. Razr I ist die 1. Version ohne Sicherheitsfeatures -> ZTE Grand X Weiterentwicklung jedoch noch ohne GPT und mit geringen Sicherheitsfeature -> und das vom Memo Pad FHD baut darauf auf, also Fortentwicklung mit GPT und Signierungen. Ein Hex Editor ist dabei dein bester Freund.
Entpacken kann ich inzwischen, beim Verpacken fehlen mir paar Bytes so das ein Flashen noch nicht geht.
Wenn man das kann, geht es darum die original recovery.img zu erhalten. Dazu sollte man vorher die 1. Partition und das boot.img untersucht haben, aus dem was man aus dem boot.img gelernt hat, kann man mit einem Hex Editor die Bytes in der 1. Partition finden, die den beginn eines neuen .img darstellen. So kann man die unterschiedlichen Images, also boot, droidboot, recovery extrahieren und auch entpacken. Damit gelangt man an die fstab der recovery.
Bringt einen jedoch nicht viel weiter, da die einzelnen Teile dort ohne Header sind. recovery.img kann man jedoch auf dem Gerät erzeugen. boot.img und recovery-from-boot.p auf Gerät kopieren, mit den Angaben aus install-recovery.sh applypatch ausführen(wie man das benutzt spuckt es im Terminal aus), dann hat man die original Recovery im img Format. Kannst gefahlos flashen.
Mit all dem was man daraus hat, kann man auch schon die CWM kompilieren, jedoch ist es nicht flashbar. Kompilieren von CWM läuft nicht durch, da nicht für x86 angepasst. Im Gerrit von CM findet man jedoch die nötigen Patches. Dann lässt es sich auch kompilieren.
Problem ist also im Moment bei mir das Erstellen den recovery.img da mit dort paar Bytes fehlen bzw. ich sie für das neue Image nicht neu erstellen kann.
So viel mal zum Erstellen einer Recovery. Als Kernel sollte man immer den orginal Kernel nehmen. Wenn man boot.img und co. extrahiert, erhält man ihn.
Nun geht es dir auch um einen Custom Kernel. Das der Kernel signiert ist, weißt du inzwischen.
Ein Custom Kernel würde uns auf dem Memo Pad FHD kaum was bringen. Natürlich, wäre ein nice to have, jedoch kennt sich kaum einer mit der ATOM SoC Plattform aus. Einfach mal Kernel Patches von anderen zum Über-/Untertakten wäre damit nicht möglich und alles andere als zu empfehlen. Gerade vom Untertakten mit einem Custom Kernel ist abzuraten, da Intel mit den SoC neue Sleepstates eingeführt hat. Da sollte man ganz genau wissen was man macht und sich sehr gut mit der Kernelentwicklung auskennen.
Was bleibt sind Kernel Module, auch wenn der Kernel signiert ist kann man unsignierte laden (tainted). Die defconfs im Kernel Source sind zwar unvollständig, mit etwas versuchen bekommt man jedoch sie soweit hin, dass kompilierte Module auch vom Kernel geladen werden.
Wenn wir schon beim Kernel sind, dann sollte man sich auch mal die Zeit nehmen sich mit Kexec auseinander zu setzen (ich hatte noch nicht die Zeit), da der Kernel Kexec fähig ist.
Mit Kexec kann man einen Kernel und Ramdisk laden ohne sie geflasht zu haben. Bei Sourceforge kann man auch die Kexec Tools für den Razr I finden (razr-i | Free Communications software downloads at SourceForge.net) sind also schon auf ATOM SoC angepasst. Wenn man also einen Stock Kernel extrahiert hat und die Ramdisk für eine Custom Recovery könnte es möglich sein so von Android aus in eine temporäre Recovery (also ohne sie installiert zu haben) zu booten. Von mir noch nicht getesten, gut möglich das da auch ein Sicherheitsfeature greift und den boote verhindert. Wenn es jedoch klappen sollte, hat man wenigstens eine "halbe" Recovery. Um das zu Testen muss man CWM nicht kompilieren, hier ist die Galaxy Tab 3 Recovery nützlich. Ihre Ramdisk entpacken, fstabs vom Memo Pad FHD nehmen, verpacken. Für einen Testlauf genügt es.
Ich denke, das sind jetzt ganz viele Informationen und Anhaltspunkte. Nutze sie um dich in die Richtung einzulesen.
@smerz
Switchgott doch auch nicht, ansonsten würde er wohl kaum Monatelang dahinter sein
S
switchgott
Dauergast
- 107
- Themenstarter
- #10
@perpe
RESPEKT!!
Sorry für die Frage in PN.
PN war vor deinem Beitrag
Sagen wir mal, ich habe 80% verstanden
Du bist zu mindest mir einen riesen Schritt voraus.
Ich frage mich die ganze Zeit, woher du dieses geballte Wissen hast?
Finden tut man das nicht so direkt in Tante Google und auch nicht bei den XDA
Kexec kenne ich.
Ein eigener Custome Kernel wäre zwar cool, aber nicht zwigent nötig.
Was mich mehr nervt ist, das man keine Kernel Module laden kann.
Siehe z.b. um /proc/config.gz.
Was die Module angeht, habe ich alles probiert.
Z.b. vom Asix 9XXX (usb gigabit) kann man ohne Probleme laden.
Der ikpconf ko nicht :-(
Dort schlägt dann die Signatur direkt zu.
Was das Thema entpacken angeht, boot.img konnte ich in die einzelne Teile entpacken.
Ramdisk kenne ich schon.
Nur habe ich es nicht geschafft, sie wieder zu verpacken!
Und das Problem wird sein, das die Signatur nicht mehr stimmen wird.
Vielleicht sehe ich das aber auch falsch.
Schau dir mal die patch.c an
[Q] Root for Asus Fonepad - Page 116 - xda-developers
Gruß
RESPEKT!!
Sorry für die Frage in PN.
PN war vor deinem Beitrag
Sagen wir mal, ich habe 80% verstanden
Du bist zu mindest mir einen riesen Schritt voraus.
Ich frage mich die ganze Zeit, woher du dieses geballte Wissen hast?
Finden tut man das nicht so direkt in Tante Google und auch nicht bei den XDA
Kexec kenne ich.
Ein eigener Custome Kernel wäre zwar cool, aber nicht zwigent nötig.
Was mich mehr nervt ist, das man keine Kernel Module laden kann.
Siehe z.b. um /proc/config.gz.
Was die Module angeht, habe ich alles probiert.
Z.b. vom Asix 9XXX (usb gigabit) kann man ohne Probleme laden.
Der ikpconf ko nicht :-(
Dort schlägt dann die Signatur direkt zu.
Was das Thema entpacken angeht, boot.img konnte ich in die einzelne Teile entpacken.
Ramdisk kenne ich schon.
Nur habe ich es nicht geschafft, sie wieder zu verpacken!
Und das Problem wird sein, das die Signatur nicht mehr stimmen wird.
Vielleicht sehe ich das aber auch falsch.
Schau dir mal die patch.c an
[Q] Root for Asus Fonepad - Page 116 - xda-developers
Gruß
P
perpe
Gast
Alles selber zusammen gesucht und probiert.
Allgemeine Informationen über die Plattform findest du wenn du nach ATOM SoC für Windows suchst. Die allgemeine Funktionsweisen der SoCs inkl. der Sleepstates ist dort erklärt. Das trifft auch alles auf die unsere Linux Version des SoCs zu.
Der Rest ist Analyse, Google und testen, testen, testen.
In den Sourceforge Repos zum Razr I findest du einiges, zwar noch alles nicht in unserer Version aber dafür noch sehr nah an Androidvorgaben. Man sieht quasi was verändert wurde, womit Intel angefangen hat und kann das dann zu unserem Gerät weiter denken. OSIP und OSII sind wichtige Stichworte, bezeichnen unsere Boot Partition, Aufbau und Handhabung. Also den Bootprozess. Es gibt im Netz auch ein paar technische PDFs von Intel der den Prozess beschreibt.
Schau auch mal im Gerät ins Verzeichnis /d/osip dort sind die Einträge den internen Boot Menüs. Kopiere die Datei decode und öffne sie mit einem Texteditor
Als defconfig für deine Module versuch es mal mit der angehängte Config, ich habe sie jedoch nicht mit dem aktuellen Kernel getestet. Die Zeile "CONFIG_LOCALVERSION" muss du anpassen, nimm die Werte die hinter der Kernelversion vom aktuellen Kernel stehen. (hoffe habe die richtige config erwischt)
Die patch.c bringt uns erst mal nicht arg weiter, da sie für eine andere Signierung ist und nicht für boot/recovery image.
Allgemeine Informationen über die Plattform findest du wenn du nach ATOM SoC für Windows suchst. Die allgemeine Funktionsweisen der SoCs inkl. der Sleepstates ist dort erklärt. Das trifft auch alles auf die unsere Linux Version des SoCs zu.
Der Rest ist Analyse, Google und testen, testen, testen.
In den Sourceforge Repos zum Razr I findest du einiges, zwar noch alles nicht in unserer Version aber dafür noch sehr nah an Androidvorgaben. Man sieht quasi was verändert wurde, womit Intel angefangen hat und kann das dann zu unserem Gerät weiter denken. OSIP und OSII sind wichtige Stichworte, bezeichnen unsere Boot Partition, Aufbau und Handhabung. Also den Bootprozess. Es gibt im Netz auch ein paar technische PDFs von Intel der den Prozess beschreibt.
Schau auch mal im Gerät ins Verzeichnis /d/osip dort sind die Einträge den internen Boot Menüs. Kopiere die Datei decode und öffne sie mit einem Texteditor
Als defconfig für deine Module versuch es mal mit der angehängte Config, ich habe sie jedoch nicht mit dem aktuellen Kernel getestet. Die Zeile "CONFIG_LOCALVERSION" muss du anpassen, nimm die Werte die hinter der Kernelversion vom aktuellen Kernel stehen. (hoffe habe die richtige config erwischt
)Die patch.c bringt uns erst mal nicht arg weiter, da sie für eine andere Signierung ist und nicht für boot/recovery image.
S
switchgott
Dauergast
- 107
- Themenstarter
- #12
Ah, du meinst Magic Version String?
Ok, den kann man ändern!
Aber danach kannst du immer noch kein Kernel eigenes (M) Modul laden.
Muss die Zeile noch mal kopieren.
Der schreibt halt ins Log, das die Signatur nicht stimmt!
Modul wird daher nicht geladen.
Danke für die Info vom Sock.
Das Osip schau ich mir mal genau an.
danke dir
Ok, den kann man ändern!
Aber danach kannst du immer noch kein Kernel eigenes (M) Modul laden.
Muss die Zeile noch mal kopieren.
Der schreibt halt ins Log, das die Signatur nicht stimmt!
Modul wird daher nicht geladen.
Danke für die Info vom Sock.
Das Osip schau ich mir mal genau an.
danke dir
P
perpe
Gast
Ruf mal lsmod aus, er meckert zwar, hat jedoch bei mir bisher trotzdem jedes Modul als tainted geladen, da der Kernel eh schon als tainted läuft (wegen dem exFAT Modul).
Wenns mit der config nicht geht, kann es auch an was anderem liegen, wie gesagt, habe es mit dem aktuellen Kernel nicht versucht. War die 4.6.2.
Überprüfe auch mal deine Busybox. Es ist zwar eine von ASUS vorinstalliert, die ist jedoch nicht komplett. Wenn du eine aus dem Play Store hast, dann schau mal unter /system/xbin mal mit ls -l nach, ob die applets gegen Busybox oder gegen houdini gelinkt sind. Wenn sie zur houdini führen, dann hast du eine ARM Busybox drauf, damit können einige Fehler auftreten, brauchst eine x86 Busybox.
Wenns mit der config nicht geht, kann es auch an was anderem liegen, wie gesagt, habe es mit dem aktuellen Kernel nicht versucht. War die 4.6.2.
Überprüfe auch mal deine Busybox. Es ist zwar eine von ASUS vorinstalliert, die ist jedoch nicht komplett. Wenn du eine aus dem Play Store hast, dann schau mal unter /system/xbin mal mit ls -l nach, ob die applets gegen Busybox oder gegen houdini gelinkt sind. Wenn sie zur houdini führen, dann hast du eine ARM Busybox drauf, damit können einige Fehler auftreten, brauchst eine x86 Busybox.
S
switchgott
Dauergast
- 107
- Themenstarter
- #14
Teste es naher mal!
Wenn ich mich noch erinnern kann, lief es ohne Probleme mit 4.6.2.
Mit 4.7.1 haben sie die Signatur für die Module eingeführt.
Wenn ich mich noch erinnern kann, lief es ohne Probleme mit 4.6.2.
Mit 4.7.1 haben sie die Signatur für die Module eingeführt.
P
perpe
Gast
Die gab es schon bei 4.6.2
Überdenke auch deine Logik, wenn es bei dir ein Modul lädt und ein anderes nicht, dann kann es nicht an der Signatur liegen, da es dann gar keins laden würde.
Gerade getestet, geht bei mir auch mit dem aktuellen Kernel.
Überdenke auch deine Logik, wenn es bei dir ein Modul lädt und ein anderes nicht, dann kann es nicht an der Signatur liegen, da es dann gar keins laden würde.
Gerade getestet, geht bei mir auch mit dem aktuellen Kernel.
S
switchgott
Dauergast
- 107
- Themenstarter
- #16
Sag mal Perpe hast du das kexec schon erfolgreich fur x86 android kompelieren können?
Mit den Kernel Modulen war mein Fehler
Habe nun auch die config.gz von 4.7.3.
Kernel auch erfolgreich gebaut.
Mit den Kernel Modulen war mein Fehler
Habe nun auch die config.gz von 4.7.3.
Kernel auch erfolgreich gebaut.
S
switchgott
Dauergast
- 107
- Themenstarter
- #17
@perpe
Have a look at this
partition_table=gpt
create -z /dev/block/mmcblk0
create /dev/block/mmcblk0
boot -p /dev/block/mmcblk0
reload /dev/block/mmcblk0
add -b 34 -s 524288 -t efi -u 80868086-8086-8086-8086-000000000000 -l reserved -T 0 -P 0 /dev/block/mmcblk0
add -b 524322 -s 65536 -t efi -u 80868086-8086-8086-8086-000000000001 -l panic -T 0 -P 0 /dev/block/mmcblk0
add -b 589858 -s 65536 -t data -u 80868086-8086-8086-8086-000000000002 -l factory -T 0 -P 0 /dev/block/mmcblk0
add -b 655394 -s 32768 -t data -u 80868086-8086-8086-8086-000000000003 -l spare -T 0 -P 0 /dev/block/mmcblk0
add -b 688162 -s 65536 -t data -u 80868086-8086-8086-8086-000000000004 -l config -T 0 -P 0 /dev/block/mmcblk0
add -b 753698 -s 1835008 -t data -u 80868086-8086-8086-8086-000000000005 -l cache -T 0 -P 0 /dev/block/mmcblk0
add -b 2588706 -s 524288 -t data -u 80868086-8086-8086-8086-000000000006 -l logs -T 0 -P 0 /dev/block/mmcblk0
add -b 3112994 -s 2752512 -t data -u 80868086-8086-8086-8086-000000000007 -l system -T 0 -P 0 /dev/block/mmcblk0
add -b 5865506 -s $calc($lba_end-16384) -t data -u 80868086-8086-8086-8086-000000000008 -l data -T 0 -P 0 /dev/block/mmcblk0
reload /dev/block/mmcblk0
Ok. Mit dem Recovery.img habe ich auch erstellen können.
Dachte allerdings das man damit per fastboot boot booten könnte.
Leider geht das nicht.
boot command stubbed on this platform.
Signatur sage ich nur dazu.
Eigendlich müssten wir nur droidboot das cc_verify wegnehmen!
Dann kann es keine Signatur mehr überprüfen.
Möchte das fastboot aber ungerne wieder zusammen bauen und flashen!
Danach ist das TAB, wenns dumm läuft nicht mehr zu gebrauchen!
Oder hast du eine Idee, ob es noch ein Recovery gibt?
Bei Samsung kann man das noch per PIT und Flash Tool beheben.
Bei ASUS?
Gibts da so etwas?
Gruß
Have a look at this
partition_table=gpt
create -z /dev/block/mmcblk0
create /dev/block/mmcblk0
boot -p /dev/block/mmcblk0
reload /dev/block/mmcblk0
add -b 34 -s 524288 -t efi -u 80868086-8086-8086-8086-000000000000 -l reserved -T 0 -P 0 /dev/block/mmcblk0
add -b 524322 -s 65536 -t efi -u 80868086-8086-8086-8086-000000000001 -l panic -T 0 -P 0 /dev/block/mmcblk0
add -b 589858 -s 65536 -t data -u 80868086-8086-8086-8086-000000000002 -l factory -T 0 -P 0 /dev/block/mmcblk0
add -b 655394 -s 32768 -t data -u 80868086-8086-8086-8086-000000000003 -l spare -T 0 -P 0 /dev/block/mmcblk0
add -b 688162 -s 65536 -t data -u 80868086-8086-8086-8086-000000000004 -l config -T 0 -P 0 /dev/block/mmcblk0
add -b 753698 -s 1835008 -t data -u 80868086-8086-8086-8086-000000000005 -l cache -T 0 -P 0 /dev/block/mmcblk0
add -b 2588706 -s 524288 -t data -u 80868086-8086-8086-8086-000000000006 -l logs -T 0 -P 0 /dev/block/mmcblk0
add -b 3112994 -s 2752512 -t data -u 80868086-8086-8086-8086-000000000007 -l system -T 0 -P 0 /dev/block/mmcblk0
add -b 5865506 -s $calc($lba_end-16384) -t data -u 80868086-8086-8086-8086-000000000008 -l data -T 0 -P 0 /dev/block/mmcblk0
reload /dev/block/mmcblk0
Ok. Mit dem Recovery.img habe ich auch erstellen können.
Dachte allerdings das man damit per fastboot boot booten könnte.
Leider geht das nicht.
boot command stubbed on this platform.
Signatur sage ich nur dazu.
Eigendlich müssten wir nur droidboot das cc_verify wegnehmen!
Dann kann es keine Signatur mehr überprüfen.
Möchte das fastboot aber ungerne wieder zusammen bauen und flashen!
Danach ist das TAB, wenns dumm läuft nicht mehr zu gebrauchen!
Oder hast du eine Idee, ob es noch ein Recovery gibt?
Bei Samsung kann man das noch per PIT und Flash Tool beheben.
Bei ASUS?
Gibts da so etwas?
Gruß
Zuletzt bearbeitet:
S
switchgott
Dauergast
- 107
- Themenstarter
- #18
Hi perpe,
was ist los?
Keine Lust mehr?
Brauche mal ne Info von dir bitte.
Vielleicht weißt du es ja.
Habe zum Thema Droidboot nicht viel finden können, auch nicht bei Intel-
Kommt vor droidboot noch etwas?
Spricht, was passiert, wenn wir droidboot modifizieren,
flashen und es läuft nicht mehr?
Gibt es vor droidboot noch einen Bootloader?
Oder können wir dann das Tab wegschmeißen?
Wie könnten wir denn droidboot neu flashen, wenn etwas schief gegangen ist?
Gibts von Asus nen Flash Tool?
Geht es durch das Recovery?
Danke dir
Gruß
was ist los?
Keine Lust mehr?
Brauche mal ne Info von dir bitte.
Vielleicht weißt du es ja.
Habe zum Thema Droidboot nicht viel finden können, auch nicht bei Intel-
Kommt vor droidboot noch etwas?
Spricht, was passiert, wenn wir droidboot modifizieren,
flashen und es läuft nicht mehr?
Gibt es vor droidboot noch einen Bootloader?
Oder können wir dann das Tab wegschmeißen?
Wie könnten wir denn droidboot neu flashen, wenn etwas schief gegangen ist?
Gibts von Asus nen Flash Tool?
Geht es durch das Recovery?
Danke dir
Gruß
P
perpe
Gast
Mit keine Lust hat das nichts zu tun. Ich schrieb dir doch schon, dass ich aktuell keine Zeit und deswegen auch den Mod Posten aufgegeben habe. Ich schreibe das doch nicht zum Spaß.
Vor Droidboot müsste noch was kommen, jedoch haben wir darauf keinen Zugriff.
Wenn du Droidboot modifizierst, hast du kein Zugang mehr auf fastboot, könnte aber auch sein, dass das Tab gar nicht mehr booten mag. Sprich im schlimmsten Fall hast du einen Brick. Falls es noch bootet, könnte man es noch retten, da die Updates auch ein Droidboot Image beinhalten.
Flashtool von ASUS gibt es nicht.
Durch die Recovery evtl. möglich, wenn das Tab noch bootet und Root vorhanden ist. Müsste man halt eine Update zip von ASUS nehmen.
Weiß jetzt nur nicht, was du damit willst. Bzw. cc_verify rausnehmen würde dir gar nichts bringen. cc_verify ist für eine andere Signierung (kommt z.B. beim Fonepad zu tragen, da werden die Update Pakete anders ausgeliefert)
Unsere Signierung (das hat das Fonepad zusätzlich) wird an einer ganz anderen Stelle überprüft (dem eigentlichen Bootloader beim Booten und beim Flashen auch). Das es mit cc_verify nichts zu tun hat, siehst du an der Tatsache, dass cc_verify im Recovery Image fehlt. Wenn es was damit zu tun hätte, würde das Flashen der offiziellen Updates immer scheitern, da cc_verify eben in der Recovery nicht enthalten ist.
Auch wenn du die Signierungsprüfung schaffen würdest zu entfernen, würde es dir nichts bringen. Dann könntest du vielleicht zwar ein unsigniertes boot/recovery image flashen, nur würde es nicht booten, da der Bootmanager ein Signiertes erwartet (kannst mit EFI Secure Boot vergleichen)
Vor Droidboot müsste noch was kommen, jedoch haben wir darauf keinen Zugriff.
Wenn du Droidboot modifizierst, hast du kein Zugang mehr auf fastboot, könnte aber auch sein, dass das Tab gar nicht mehr booten mag. Sprich im schlimmsten Fall hast du einen Brick. Falls es noch bootet, könnte man es noch retten, da die Updates auch ein Droidboot Image beinhalten.
Flashtool von ASUS gibt es nicht.
Durch die Recovery evtl. möglich, wenn das Tab noch bootet und Root vorhanden ist. Müsste man halt eine Update zip von ASUS nehmen.
Weiß jetzt nur nicht, was du damit willst. Bzw. cc_verify rausnehmen würde dir gar nichts bringen. cc_verify ist für eine andere Signierung (kommt z.B. beim Fonepad zu tragen, da werden die Update Pakete anders ausgeliefert)
Unsere Signierung (das hat das Fonepad zusätzlich) wird an einer ganz anderen Stelle überprüft (dem eigentlichen Bootloader beim Booten und beim Flashen auch). Das es mit cc_verify nichts zu tun hat, siehst du an der Tatsache, dass cc_verify im Recovery Image fehlt. Wenn es was damit zu tun hätte, würde das Flashen der offiziellen Updates immer scheitern, da cc_verify eben in der Recovery nicht enthalten ist.
Auch wenn du die Signierungsprüfung schaffen würdest zu entfernen, würde es dir nichts bringen. Dann könntest du vielleicht zwar ein unsigniertes boot/recovery image flashen, nur würde es nicht booten, da der Bootmanager ein Signiertes erwartet (kannst mit EFI Secure Boot vergleichen)
S
switchgott
Dauergast
- 107
- Themenstarter
- #20
Wusa!
Sorry nochmal, das mit deiner Zeit muss ich irgendwie überlesen haben.
Das ist echt sehr schade.
Vielleicht würden wir zwei mehr erreichen.
Aber ich kenne das mit der Zeit.
Was für eine Chance haben wir?
So wie ich das sehe fast keine.
Den eigentliche Bootloader, so wie ich es verstanden habe, besitzen wir ja noch nicht einmal in IMG Form.
Von daher bringt es uns, wie du schon geschrieben, fast gar nichts, den Droidboot zu modifizieren.
Aber was würde uns dann das Recovery Image bringen?
Was wir nur tun könnten wäre ein Backup des bestehenden Roms zu erstellen und geg. das Backup wieder ein spielen.
Würde sagen, da hast ASUS richtig gute Arbeit geleistet.
Ich versuche gerade zwei Sachen:
Recovery Image zu bauen.
Und das zweite ist, vollen Ethernet Support für das Tab.
Und das ist wirklich verdammt hart!
Hast du vielleicht eine Idee, warum USB Ethernet nur zum Teil geht?
Habe schon Smali Code verändert etc.
Keine Chance.
Bekomme Ethernet nicht richtig zum laufen.
Selbst Android Sync Adapter wollen nicht laufen.
Dein Stock Recovery läuft auch oder konntest du es nur flashen?
Bin bisher noch nicht dazu gekommen.
Gruß
Sorry nochmal, das mit deiner Zeit muss ich irgendwie überlesen haben.
Das ist echt sehr schade.
Vielleicht würden wir zwei mehr erreichen.
Aber ich kenne das mit der Zeit.
Was für eine Chance haben wir?
So wie ich das sehe fast keine.
Den eigentliche Bootloader, so wie ich es verstanden habe, besitzen wir ja noch nicht einmal in IMG Form.
Von daher bringt es uns, wie du schon geschrieben, fast gar nichts, den Droidboot zu modifizieren.
Aber was würde uns dann das Recovery Image bringen?
Was wir nur tun könnten wäre ein Backup des bestehenden Roms zu erstellen und geg. das Backup wieder ein spielen.
Würde sagen, da hast ASUS richtig gute Arbeit geleistet.
Ich versuche gerade zwei Sachen:
Recovery Image zu bauen.
Und das zweite ist, vollen Ethernet Support für das Tab.
Und das ist wirklich verdammt hart!
Hast du vielleicht eine Idee, warum USB Ethernet nur zum Teil geht?
Habe schon Smali Code verändert etc.
Keine Chance.
Bekomme Ethernet nicht richtig zum laufen.
Selbst Android Sync Adapter wollen nicht laufen.
Dein Stock Recovery läuft auch oder konntest du es nur flashen?
Bin bisher noch nicht dazu gekommen.
Gruß
Ähnliche Themen
Italiano60
Italiano60
- Buggiwuggi99
Buggiwuggi99