- OLED TV topic
- Kormányok / autós szimulátorok topicja
- Gaming notebook topik
- Vezetékes FEJhallgatók
- Multimédiás / PC-s hangfalszettek (2.0, 2.1, 5.1)
- Milyen asztali (teljes vagy fél-) gépet vegyek?
- HiFi műszaki szemmel - sztereó hangrendszerek
- eGPU tapasztalatok
- Fejhallgató erősítő és DAC topik
- Milyen egeret válasszak?
Hirdetés
-
Stellar Blade - Befutottak az első tesztek
gp A beszámolók alapján talán elmondható, hogy a stílus kedvelőinek érdeme lehet beszerezni a teljes kiadást.
-
Világító alma helyett világító tok és szíj az almákra
ma Megjelent a Glow 2.0, a Nomad fluoreszkáló iPhone védőtokjának és Apple Watch szíjának második generációja.
-
Lopják az LG akkutitkait
it Inkább licenceli ezentúl az akkumulátoros szabadalmait az LG Energy Solution, mert túl sok a jogsértés. Az LGES mellett az UMC is az autóipar egyre lassuló keresletére figyelmeztet.
-
PROHARDVER!
Ezt a fórumot azért hoztuk létre,hogy ne zavarjuk azon felhasználókat, akik még csak most ismerkednek a tablettel, vagy akár az Android rendszerrel.
Új hozzászólás Aktív témák
-
-
Orionhilles
senior tag
Hmm... A fastboot tethered recovery launcher fejlesztőjével (social-design-concepts) felvettem a kapcsolatot, meglátjuk.
Köszönök minden segítséget, Google fordítóval, be vallom őszintén, nem merek belevágni, sajnálom,– Yet, thou serves with thine eyes clouded in chaos. Thou, bound in the cage of madness. I am he who commands those chains – Fate/Zero Berserker Mad Enchantment
-
Orionhilles
senior tag
Nem, dehogy!
I warn in advance that the image is signed and can not permanently replace the stock using CWM recovery, even not visible (they are hidden in the reserved section of memory and link to them in the MBR)."Ez nekem sántít.. Cwm nem lehet aláírva, így nem is értem... Ha flashelem recovery partícióra akkor :
Nyitott bl esetén ott marad.
Zárt bl esetén a gyári felülírja (önjavító metódus) vagy tégla lesz belőle
De recovery partícióra flashelte droidboot alól??? Vagy csak ideiglenes cwm-mel próbálkozott?[ Szerkesztve ]
– Yet, thou serves with thine eyes clouded in chaos. Thou, bound in the cage of madness. I am he who commands those chains – Fate/Zero Berserker Mad Enchantment
-
Orionhilles
senior tag
you can use this to dump the boot recovery fastboot and any other images in the osip dump_images
És ezt kaptam... Rá fogok kérdezni– Yet, thou serves with thine eyes clouded in chaos. Thou, bound in the cage of madness. I am he who commands those chains – Fate/Zero Berserker Mad Enchantment
-
Orionhilles
senior tag
"... És az MBR tölti be"
Ez az említett önjavító metódus, ezek szerint valószínűleg zárt bl, de holnap du megnézem, remélem nem, mert akkor felesleges az eddig bele ölt munka.....
Azon filózok, hogy valamelyik frissítés patcheli a bootloadert, lehet hogy az is zárja le az addig nyitottat?[ Szerkesztve ]
– Yet, thou serves with thine eyes clouded in chaos. Thou, bound in the cage of madness. I am he who commands those chains – Fate/Zero Berserker Mad Enchantment
-
Orionhilles
senior tag
Rákérdeztem, és azt írta, hogy ő nem ismer ilyen módszert...
Azt meg kellene valakinek próbálni, hogy a cwm launcherben lévő cwm.zip-et (ha jól dereng) fel kellene próbálni flashelni gyári recovery alól. Mi történik?
(lehet, hogy nem bírok magammal és én leszek az az egyén... )– Yet, thou serves with thine eyes clouded in chaos. Thou, bound in the cage of madness. I am he who commands those chains – Fate/Zero Berserker Mad Enchantment
-
_Soma77_
tag
válasz R0GERIUS #139 üzenetére
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?
-
R0GERIUS
tag
válasz R0GERIUS #143 üzenetére
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...).
-
R0GERIUS
tag
válasz R0GERIUS #144 üzenetére
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 ]
-
_Soma77_
tag
válasz R0GERIUS #144 üzenetére
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
[ Szerkesztve ]
-
_Soma77_
tag
válasz R0GERIUS #143 üzenetére
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 ]
-
_Soma77_
tag
válasz R0GERIUS #164 üzenetére
itt a header formátum [link]
és ahogy írják, struktúraként kezelni a headert a szám reprezetáció miatt (endian) nem lesz ugyan az ARM-on és x86-on... így nem mindegy, milyen platformon írják a ki-/becsomagoló tool-t... ahogy a mellékelt ábra is mutatja [link][ Szerkesztve ]
-
_Soma77_
tag
válasz R0GERIUS #164 üzenetére
csak nem hagy nyugodni ez a header história...
írtam egy kis progit (Eclipse alatt, mingw alatt fordul) amely a leírt [struktúrába] kibontja a header tartalmát.
ráengedve egy hagyományos (ANDORID! magic-es) image-re, szépen hozza az adatokat.
viszont a "nem standard" image-ekre (amilyen a miénk is) nem sok adatot hoz...pl. boot.img
ami aggaszt, hogy az egész struktúra mérete összesen 608 byte (feltételezve, hogy az "unsigned" típus 4 byte-os "unsigned int"-et takar), holott a header 2048 byte (0x0000-0x800-ig terjedő terület az image-ben)...
hol a hiányzó 1440 byte (=180 unsigned int?)
[ Szerkesztve ]
-
R0GERIUS
tag
válasz R0GERIUS #177 üzenetére
UPDATE 2: korai volt a lelkesedés.
Valahogy a két dolgot össze kellene házasítani.
Itt jó a a repack és ott az unpack.
Amúgy a hiba amit dob a ramdiskhez: túl korai archívumvég. Azaz nem jól kezeli a végét a ramdisk-nek és az elejét zImage-nek...
Ha viszont a tool-al oda vissza csinálom akkor 100% ugyanolyan image-t ad, de ha a másik által kibányászott ramdisk-et és kernel képet használom, akkor elég sok eltérés van benne.Ezzel a tool-al kicsomagolt ramdisk 0-38C000-ig tart, míg a rendes ramdisk-nek 38C020-ig, tehát valóban a mérettel van a gond. Valahogy azt kellene korrigálni, és valószínűleg megvan.
[ Szerkesztve ]
-
R0GERIUS
tag
válasz R0GERIUS #178 üzenetére
UPDATE 3: Sajna nem nyersen a méret a hiba.
Átirtam a kódot, így megfelene a méret, de nem stimmel, továbbra sem nyitható meg.
Lehet, hogy maga a blokkok pozíciója más?
Az sok mindent megmagyarázna...UPDATE 4: El van számolva.
Az eredeti szkript, ami értelmes fájlokat nyert ki, az onnan kezdi leválasztani, ahol a fájlban megtalálja ezt: 1F 8B (magic number)
Itt is megvan ez a szám, csak 1000-el elcsúszva...
Át kell paraméterezni a program által kiolvasott blokkokat.[ Szerkesztve ]
-
Új hozzászólás Aktív témák
- Battlefield 2042 - A hetedik szezonnal véget ér a tartalmi támogatás
- PlayStation 5
- No Rest for the Wicked
- Ukrajnai háború
- Xbox Series X|S
- EA Sports WRC '23
- GoodSpeed: SAMSUNG Galaxy Buds FE (SM-R400NZAAEUE) a 9 éves SONY SBH20 utódja (nálam)
- OLED TV topic
- Autós topik
- Kerti grill és bográcsozó házilag (BBQ, tervek, ötletek, receptek)
- További aktív témák...