az a helyzet, hogy a re-pack szkript nem ugyan olyan fejlécű image-et rak össze, mint az eredeti volt.

Örülnék, ha valaki rá tudna nézni egy kicsit közelebbről...

felraktam ide a teljes motyót, minden köztes állománnyal és szkript-tel. [link]

van két pearl szkript (unpack-bootimg.pl és unpack-bootimg2.pl), amelyek gyakorlatilag csak parancssoros hívásban térnek el egymástól...

1) system ("mkbootimg --cmdline 'no_console_suspend=1 console=null' --kernel $ARGV[0] --ramdisk ramdisk-repack.cpio.gz -o $ARGV[2]");
2) system ("mkbootimg --base 0x00200000 --pagesize 2048 --kernel $ARGV[0] --ramdisk ramdisk-repack.cpio.gz -o $ARGV[2]");

...viszont mindkettő a csomagban lévő mkbootimg-t hívja.

A kimeneti image-ek (new_boot.img és new_boot2.img) csak a parancssorban különböznek (header részben), többi ugyan az...miért is lenne más?

Viszont az eredeti img és az újra-pakolt img több ponton is különbözik, főleg a fejlécben, mivel nem "ANDROID!"-dal kezdődik, hanem "$OS$"-al.

Szerintem kellene találni egy olyan "mkbootimg"-et, ami az eredetivel megegyező image-et gyárt.

Az újrapakolt image-ek elvileg(!) Android kompatibilisek, kérdés, hogy az Op3n Dott megeszi-e???

Ötlet?

Üdv!

Úszni nem tudok, de most vettem egy ilyen tabot. Még nem frissítettem. Kell az eredeti rom?

Ha kapok egy rövid leírást, hogy hogyan kell leszedem szívesen holnap este.

4.4.2
F9.EE
3.10.20-as kernel 2014.09.10 13:41:13
1.00_20140910-es build.

Találtam egy ilyet; esetleg segíthet: [link]
Elméletileg eszerint eljárva keletkezik egy olyan output.txt, amely megírja, hogy az újratömörítéshez hogyan paraméterezd megfelelően az mkbootimg-t.
Sajnos személyesen nem tudok ránézni, mert a héten 2 vizsgám is van.

Na jó; nem bírtam megálni.
A header-rel jelenleg én sem tudok mit kezdeni.
A recovery és a boot meg iszonyatosan nagy hasonlóságot mutat, ami különös...
Talán az egyik a másik backupja?
A fájlokat elnézve nem tartom lehetetlennek.

A másik érdekesség az, hogy a header-nek van egy olvasható részlete:
"init=/init pci=noearly earlyprintk=nologger loglevel=0 kmemleak=off androidboot.bootmedia=sdcard androidboot.hardware=redhookbay watchdog.watchdog_thresh=60 androidboot.spid=xxxx:xxxx:xxxx:xxxx:xxxx:xxxx androidboot.serialno=01234567890123456789012345678901 ip=50.0.0.2:50.0.0.1::255.255.255.0::usb0n vmalloc=172M ehci_hcd.use_sph=1"

Az újracsomagoltból ez hiányzik.
Ezen kívül külön érdekes ez a két rész:
"androidboot.hardware=redhookbay"
A configban van pár ilyen kiterjesztésű fájl.
"androidboot.bootmedia=sdcard"
Micsoda?!?! (Vad feltételezés: USB módban innen várja a boot helyreállító fájlját?)

A harmadik: a klasszikus módszertól eltérően nem készül a kibontáskor zImage, hanem helyette xxx.img-kernel.gz (meg sem említem, hogy mind a recovery, mind a boot kibontása dob egy ilyen fájlt...).

Nos ezen értelmes részek még egy érdekes helyre vittek, és sikerült felfedezni valamit, de a befejezést rátok hagyom.
Alapvetően minden hiba/kellemetlenség a képfájlok kibontásában és újracsomagolásában az X86 miatt van.
Úgy néz ki, hogy ezen architektúrára épülő készülékek boot-ja és recovery-je eltér a szokványostól (ARM).
Így a keresési irány: Android x86 képfájlok kezelése.

Véletlen bele is futottam XDA-n egy olyan Motorolába aminél hasonló gondoktól szenvedtek a képfájloknál (pontosan az Intel x86 miatt):
[link]
(Lehet, hogy érdemes végignézni, mert sok a hasonlóság: egyedi header, egyes részek (amit kiemeltem az előzőben) ugyanúgy szerepeltek benne...)

Nem olvastam végig, de említenek egy hexa szerkesztőn alapuló megoldást:
[link]

Idő hiányában nem tudok most ennél jobban belemélyedni; ezt rátok bízom.

[ Szerkesztve ]

@Adamus1117: köszi, hogy belenéztél...és köszi a tippeket is...

próbaképpen egy újonnan készített img-et kicsomagoltam majd újra becsomagoltam, és nem lett ugyanaz na erre végképp nem számítottam, lehet, hogy vagy 1. vmit elböktem (bár többször is kipróbáltam) 2. az x86-os "anomália" okozza...

rákeresve a kérdéses olvasható részére a boot.img-nek, eljutottam egy BoardConfig.mk-ig, mintha innen lenne...

BOARD_KERNEL_CMDLINE := init=/init pci=noearly console=logk0 earlyprintk=nologger loglevel=0 kmemleak=off androidboot.bootmedia=sdcard androidboot.hardware=redhookbay $(cmdline_extra) ip=50.0.0.2:50.0.0.1::255.255.255.0::usb0n vmalloc=172M androidboot.wakesrc=05 androidboot.mode=main

[link]
[link]

[ Szerkesztve ]

egy kis olvasnivaló [link]

megnéztem a linken szereplő eljárást is, leszedtem a tool-okat, de a "unmkbootimg" nem ette meg a mi képfáljainkat. az általam korábban használt perl szkriptek egyébként a leírtak alapján dolgoznak (BTW zImage helyett ...-kernel.gz file-okat gyártanak), és az image összerakás (kernel, és cpio-ba becsomagolt ramdisk összefésülése) is teljesen jónak tűnik... kicseréltem a "mkbootimg" toolt is egy frissebbre (ami a linken szerepelt), és átparamétereztem a hívást a leírtak alapján, de ugyan az lett a kimenet, mint korábban...

nekem úgy tűnik az eredeti image fejléce alapján, hogy ez vmi OSX-es tool-lal generált dolog lehet, mert 1. nem a standard magic android header keletkezik 2. BoardConfig.mk-ból származó dolgok vannak benne (kernel szint?!), tehát ez több, mint egy sima "lapátoljunk össze egy image"-et tool mint az "mkbootimg"...

akinek van ötlete, pls jelezze!

[ Szerkesztve ]

Nézz rá a #145-re.
Úgy néz ki, hogy az összes x86-osnál nem standard a header, és nem működnek a szabvány módszerek erre nézve.
Ahogy utaltam is rá: sajnos valószínűleg ezen a vonalon kell elindulni...
A hexeditoros módszer jónak tűnt elsőre, de sajna nincs időm kipróbálni.

[ Szerkesztve ]

Lehet, hogy holnap csinálok egy hack-elt repack-ot, aminek a header része (2048 byte) át lesz emelve az eredeti img-ből... amolyan öszvér...

Amúgy mind a boot-ot mind a recovery-t flashelni kell a próbához, mert lehet, hogy egyik a másik backup-ja.

Hétvégén lehet hogy vállalkozom rá.

Szerintem a fejlécnek nincs köze hozzá, hogy min lett generálva.
A Moto-sok azzal próbálkoztak, hogy a szkriptbe beírták a változó negáltját, de az se egy túl biztos módszer.
A hexá-s nekem biztosabbnak tűnik, hisz mivel egyszer ki tudtuk bontani, így elég könnyen megmodható, hogy meddig tartanak az egyes részek (header, cpio, kernel).
Amúgy ez a '$OS$' jelölés az android helyett az elején inkább indefinit. Sok helyen (szkriptekben) így jelölik, esetlegesen a din. adatot, azaz hogy pl. olvassa ezt az adatot, és nem fix adat.
Bár elég ronda dolog ez egy header-ben.

[ Szerkesztve ]

lehet, hogy vakvágány, de....

valaki írta korábban, hogy ez a gép egy Teclast klón. Nem egy Teclast 89 mini véletlenül?
[speckója] elégge hasonló.

a baj csak annyi, hogy ez a gép is 16GB-os --- ahogy az Op3n Dott eredeti gépe is.

van hozzá root-olt ROM [link] innen [link]

a partíciós tábla (partition.tbl) is elég hasonló felosztást mutat.

talán érdemes ezt a szálat is nyomozni egy kicsit...

ok, köszi, majd rápillantok meg köszi a többi infót is... a legjobb az lenne, ha lenne fogalmunk róla, mi kerül a header-be, és nem csak brute force-olnánk egyet

[ Szerkesztve ]

Teclast P89 mini házával egyezik meg a mi tabletünk háza, viszont a Teclast-nál sincs azonos sepc-cel gép, csak nagyon hasonló.

[ Szerkesztve ]

Különböző SoC sajna...

[ Szerkesztve ]

egy kis olvasnivaló...[link]