- 3D nyomtatás
- Milyen monitort vegyek?
- Kormányok / autós szimulátorok topicja
- Házimozi belépő szinten
- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
- Milyen alaplapot vegyek?
- Nem indul és mi a baja a gépemnek topik
- AMD Ryzen 9 / 7 / 5 / 3 5***(X) "Zen 3" (AM4)
- Milyen asztali (teljes vagy fél-) gépet vegyek?
- Azonnali processzoros kérdések órája
Hirdetés
-
Megérkezett Magyarországra a Samsung új OLED gaming monitora
ph Az Odyssey OLED G8 32 hüvelyes, sík OLED panellel dolgozik.
-
Lőn világosság: megérkezett új fénymérőnk
ma A márka és a metódus maradt, gyorsan pótoltuk a Honor 200 Pro méréseit.
-
Anime adaptációt kap a Guilty Gear Strive
gp Részleteket egyelőre nem kaptunk, a teljes leleplezsére jövő hónap elején kerül sor.
-
PROHARDVER!
Android szakmai topic
Windows 8/10 gépen a készülék nem csatlakozik többé, mit tehetek?! ---> [link]
Az alábbi témák kitárgyalása kerülendő, mert nem ide tartozik!
Kérdésed a megfelelő topikba tedd fel:"melyik alkalmazás, ami"
"milyen tokot vegyek"
"piros hátlap hol kapható"
"Melyik okostelefont vegyem?"
Új hozzászólás Aktív témák
-
Keeperv85
nagyúr
válasz
#79335424 #12842 üzenetére
Ő TWRP-t írt, te pedig hajtod tovább a CWM-re. NEM ugyan az. Két külön forráskód! A CWM alatt integrálva van a teljes menü nyelv tartalma, nem lehet utólag nyelvet váltani, mert nem olvas külső forrásokat be ehhez a menühöz. Tehát az úgy marad, ahogy elkészült. A TWRP grafikus és NEM karakteres felületet használ és van plugin támogatása, amivel lokalizálható!
-
-
Keeperv85
nagyúr
válasz
#79335424 #12869 üzenetére
Az OS mint olyan nem fut "onnan", az OS mint olyan a ramdiskben megadott szuperblokkból fut, ami az fstab kiosztásában szerepel. A dual boot recovery-kben és általában a recovery alatt is teljes értékű kernel van, amivel semmi egyebet nem csinál, mint hogy átállítja a felette futó ramdisket, így az betöltés közben a másik rendszert fogja betölteni. Mondjuk létezik olyan megoldás, aminél a kernelből csak egy van külön helyen és ehhez van két ramdisk, az egyik a normál rendszer betöltésért felel, a másik a recovery. Ez egész addig ésszerűnek is tűnik, még a recovery ramdisk elég nagy. Mikor nem, akkor a recovery kernelen szoktunk állítani és kidobálni belőle, ami ott nem kell, így lesz elég hely. Na ezeknél ez felesleges, mert hát ugye többé nem fog a rendszer bootolni egyrészt, másrészt a kernel mérete a saját helyével spórol, hiába...
[ Szerkesztve ]
-
Keeperv85
nagyúr
válasz
#79335424 #12893 üzenetére
Nem onnan töltődik be...
Egyszerűsítsünk, mert a bootloadert kár jobban lebontani most. Így bootolounk: bootloader > feltételvizsgálat több felé,melyik módban kell indulni. Normál, download, recovery, bootloaderben maradunk, DFU, stb-stb... HA a recovery kerül kiválasztásra, akkor HA van saját kernele és nem csak egy kernel van, mint a ZTE U889-nek pl, betölti. Ha nincs saját, akkor a főkernelt. Majd inicializálja a ramdisk-et, ami a recovery esetében úgy van beállítva, hogy az init binárissal ne a rendszert indítsa most el, hanem a recovery binárist. Maga a recovery bináris tartalmazza a kezelőfelületet és egy parancsértelmezőt, ami majd futtatni fogja a a bináris telepítőt, természetesen a script függvényében amit írnak hozzá. A dual boot recoveryk alatt van ugye egy menüpont, ami a másik rendszert tölti. Nem csinál mást, mint hogy úgy indítja újra a telefont, hogy a bootloader paraméterezése most átáll egy másik kernelre, ami egy másik ramdisk-et tölt be: mivel a ramdisk tartalmazza az fstab-ot, ami konkretizálja a kernel felé merre vannak a partíciók, így most az a kernel azt "hiszi", hogy a valódi system szuperblokkot kapta meg és szépen betölti a látszólagos system tartalmát. Ilyenkor már a recovery NEM fut, NEM vesz részt a bootoloásban semmi szín alatt ilyenkor sem és normál boot alatt sem.
-
Keeperv85
nagyúr
válasz
#79335424 #12902 üzenetére
Alapvető hibákba ütközöl értelmezés tekintetében, ami a Windowsos előélet hozadéka. A recovery mint olyan nem partíció, sokkal gyakrabban önálló szuperblokk, de van ahol még külön helye sincs, csak a főrendszer system/bin mappájában szerepelteti magát. Maradjunk az alap esetnél, miszerint EGY szuperblokk. Na most ezzel az a nagy gond OS szempontjából, hogy a kernel biztonsági szintjei kizárólagossan szeparatív szuperblokk jelenlétét várják el magától a kerneltől. Tehát nem lehet a recovery szuperblokkban a system és a recovery mountpoint is, mivel ez lehetetlen. Nem tudod tovább osztani a szuperblokkot ilyen módon. Egy MTD egy csatolási pont. Ráadásul a recovery blokk mérete maximum 32MB. Érdemes rajta elgondolkodni, hogy csak a beállítás menü a full HD kijelzők mellett magában 24...
-
Keeperv85
nagyúr
"A szuperblokk fogalmát nem fájlrendszereknél használjuk?"
De, pontosan. Ám itt ugye meg kell különböztetnünk a blokkeszközöket, amik pont az eltérő fájlrendszer miatt szuperblokkok is egyben. Tehát pl. a system csak és kizárólag egy ext4-es, vagy yaffs2-es, vagy ubifs blokkot tartalmazhat, így ő önálló szuperblokká válik, önálló csatolási pontot kap, de partíció felosztás nélkül. Ha partíciós mezőket is elhelyezhetnénk benne, akkor olyan megoldás lenne, mint az Intel-féle OSIP. Az egy db 100MB-os blokkeszköz, amiben 4 db partíciós mező van. bootloader (droidbootnak hívják ott), bootimage, recoveryimage és az NVRAM, ami itt OSII, vagy OSIP header. Ezeknek magában a 100MB-os blokkeszközben van saját partíciójuk, viszont ezeknek nincsen csatolási pontjuk, sem betűjelük. Az OSIP header kezeli őket. Ráadásul fizikailag nem szeparatív a tárhelyük, mert a memória címeik "keresztezik" egymást szekvenciálisan. Tehát pl. az első mezőben szerepel a bootloader header, de fizikailag nem a bootloader követi, hanem a kernel header., ellenben mivel a visszaolvasás is szekvenciálisan történik a belső partíciók egységesnek tűnnek a külső rendszerek számára. Már amennyire ezt külső rendszer kezelni tudja...
" partíciók ugye a fizikai tároló (FLASH, NAND FLASH) teljes tárhelyének felosztása logikai egységekre"
A partíciók a blokkeszközök felosztásai. Persze miután a legtöbb háttértároló egyetlen blokkból áll csupán, így a gyakorlatban azt láthatjuk, hogy többnyire azt az egyetlen blokkot partíciós mezők osztják fel. Na most az Android alatt ezek fájlrendszer szuperblokkok (emmcblk0, mtdblkp1p0 stb), nem a klasszikus értelemben vett partíciós táblák. Mivel a recoverynek történetesen nincsen fájlrendszere, így egy fájlrendszer nélküli adatstruktúra, ha úgy tetszik, ahogy eddig hívtuk: egy fájlrendszer nélküli szuperblokk (raw), amivel kizárjuk a partíció fogalmát. továbbá kizárhatjuk azzal is, ha végig gondolod, hogy a partíciós hierarchiákban egy fő partíciós táblához kötött számú logikai tábla tartozik és egyetlen blokkon nem lehet egyszerre elsődleges partíció, sőt...
Szóval a partíció és particionálás itt már csak a közérthetőség miatt forog fent, mivel megszokhattuk, hogy a Windows vagy Windows közeli fájlrendszerek egyetlen szuperblokkot particionálva osztanak meg.
Persze, mint mindig a tévedés jogát fenntartom, de én így olvastam eddig több helyen...
Egy MTD egy csatolási pont
Használják most is. Ne mélyedjünk bele, hogy az egyik a másikba miként átjárható, pl. mit csinál a fuse kiterjesztés... Úgy értem: az mtd hogyan lesz egy emuláció során emmc...
[ Szerkesztve ]
-
Keeperv85
nagyúr
válasz
#79335424 #12920 üzenetére
"Értem az okfejtést, csak én OS -t írtam, nem Androidot. Ez történetesen egy Tiny Core Linux, amiknél az az alapértelmezett működés, hogy az OS a RAM -ba töltődik be és onnan fut. A Puppy is így működik. Ha betöltődött a rendszer, onnantól nem igényel a működéshez semmilyen meghajtót. PC esetében, akár azt az adathordozót is eltávolíthatod, amiről bebootolt."
Kevés hasonló van, bár a Windows is képes erre. Viszont ennek van egy olyan kellemetlen vonzata, hogy az összes rendszerbeállítást el kell felejteni kikapcsoláskor, mert hát ugye a ram tartalma nem arról híres, hogy rezidens lenne. Hacsak ki nem mented egy háttértárra, amivel visszatértünk a kiindulási állapotként vázolt hibára: a recovery alatt nincsen fájlrendszer, tehát oda nem írhat semmi futás időben...
-
-
Keeperv85
nagyúr
válasz
Szabónagymer #12973 üzenetére
Tehetséges szervizes + hatalmas user error... Nem frissült mindegyik le, mivel nem tudott,mert eltérő AMSS verzióval jöttek ki és a gyártó is összekeveredett végül bele... A user error ott kezdőik, hogy egy szervizből kihozott készüléket nem nézel át teljesen,plusz nincs mentésed...
Mit is csinálta szerviz?
Szétszedték, hogy levegyék az érintőt, közben elszakították véletlen a kamera kábelét. Sebaj... összerakva meg kell nézni minden okés-e... pesze: nem megy a kamera. Semmi gond: kamera csere. Ezúttal az a nyomorék a csatlakozót töri le. Felszereltség magad foka, nincs hőlég, amúgy minden ragasztott szinte, nem lehet nagyon melegíteni. Kicseréljük az egész főpanelt... Nosza, ehhez már a kis szenzort is ki kell szerelni. Na ná: visszadugni még sikerült, csak összeszerelés közben nem ült bele a gumiágyba, ami miatt most folyamatosan le van takarva. Bekapcsolták a telót. Kamera oké, érintő megy. Minden frankó,mehet vissza....
-
Keeperv85
nagyúr
válasz
Szabónagymer #12979 üzenetére
Ne hozzájuk inkább... (Uhh.. most nézem, hogy álmosan nem kéne írni: helyesírási hibáktól hemzseg az előző kommentem....
)
Nem szoktam ilyet javasolni, de lehet jobban jársz, ha te szeded otthon szét és rakod újra össze!A fényérzékelő és a proximity (közelségmérő) többnyire egy tokban helyezkedik el és egy pici gumi tömítés van az érintő panelben elhelyezve felette. Ezt lehet szépen félrenyomni, ha nem körültekintő az szerviz. Szélsőséges esetben le is törte a szenzort egyből. Azt csak csere alkatrésszel lehet megoldani és nem árt némi kézügyesség sem, mert hőléggel kell forrasztani, pákával ezt nem lehet. No meg persze ehhez kell hőlég állomás...
-
Keeperv85
nagyúr
AMSS: Advanced Mobile Subscriber Software.
Ez a rádiófrekvenciás firmware. Az legnagyobb mbn fájl ezeken az eszközökön. Tele van vezérlő rutinnal az eszközt illetően, illetőleg itt van vagy innen generálódik a firmware verziószáma, amit olvas a legtöbb update. Ennek (is) köszönhetően nem megy fel másik csomag, csak az, ami az adott készülékre való.
Természetesen most a Qualcomm fájlrendszerről van szó! HTC, Crane, MTK,Spreadturn,Allwiner, Intel... és még sorolhatnánk hány másik van a gyártóktól és modellektől függően. A legszebb, mikor kereszt licencelt a készülék: Crane rendszerű, de már a fájlrendszer HTC hierarchiába épül pl..
[ Szerkesztve ]
-
Keeperv85
nagyúr
válasz
Szabónagymer #13006 üzenetére
A guminak az előlapban kéne lennie, abba kéne felfeküdni a két kis lencsének. Bár nem tartom kizártnak, hogy gyárilag is spóroltak vele, de illő volna ott lennie...
Egyébként az nem egy mezei plexi, amit cseréltek. Az keret pedig neki van ragasztva az LCD-nek...
-
Keeperv85
nagyúr
"Hasonló dolog ez, mint az MTK-kon pl. az MNL file? Ami a GPS-ért (is ? ) felelős és szintén több verziója van."
Nem kifejezetten. Ez egy önálló blokkeszköz, ami ráadásul nem is olvasható, csupán ő tud bootolás közben beállítani bizonyos dolgokat. Elsősorban a rádió frekvenciás dolgokért felel, mint a mobil adatok és a GSM, de itt vannak a többi hardver vezérlő rutinjai is részben.
-
-
Keeperv85
nagyúr
válasz
seederking #13080 üzenetére
Nem akartam azt írni, hogy kicsi a pénztárcájuk, azért. Mert ha van elég tőke, akkor ha nem fér fel valami, akkor nem vacakol, vesz másik készüléket, aki megteheti.
A második esetet meg arra értem, mikor valaki megvesz egy Galaxy Ace-t pl. és meglepődik miért nem megy a GTA San Andreas....
Egyrészt mert nem fér fel, másrészt hát ugye. Abban egyetértünk, hogy az elég szemét dolog, mikor egy erős vas ott hasal el játék tekintetébe, hogy egyszerűen nem férnek fel rá...
-
Keeperv85
nagyúr
Nem a véletlen műve. Mindkettőt ugyan az a srác írja. A CWM egy külön fejlesztés, amit számos romba integráltak, többek közt az Omni, a CM, a MIUI, a Carbon, a LewaOS és az AOKP kódútban is. Ezekhez készített egy GUI-t is, ez a nem túl jól sikerült RomManager.
[ Szerkesztve ]
-
Keeperv85
nagyúr
A CWM NEM egy csapat! Egyetlen emberről van szó, aki fejleszti, persze vannak contributorok, mint többnyire az open source cuccoknál. Koushik Dutta tervezte és ő programozta le magát a CWM recovery-t és a Rom Managert IS! Emellett amit még ő készít az a Superuser, de NEM a bináris su, csak a konzol.
Tehát olyan nincsen, hogy "CWM csapat". Az pedig, hogy CWM Rom Manager néven is megtalálja a Google a cuccot, nem más sara. Amúgy csak RomManager a neve, nincs benne a CWM...
[ Szerkesztve ]
-
Keeperv85
nagyúr
válasz
LonGleY #13257 üzenetére
Én meg azt nem hívom memóriakezelésnek,mikor egy nyamvadt Facebook 44MB-ot kér, vagy egy ébresztőóra 3-mat. 1GB-rammal komoly PC-s multitasking is fut, köze nincs ahhoz, hogy a droid hogy kezeli a memóriát. 512MB-os kapacitásra van optimalizálva pl. a KitKat és vígan el is lenne annyival, ha nem lenne nyakon öntve mindig valami memóriazabáló hulladékkal. Viszonyításképpen mondom csupán, hogy az Arch Linux pl. egy megfontoltabb kezelőfelület mellett is vígan elvan a maga 80-85MB-ján, szemben ezzel a Touchwiz 300 alatt meg sem áll többnyire... (Elnézést a szakmaiatlanságért: az MotionWiz újabban...
)
-
-
Keeperv85
nagyúr
válasz
Siriusb #13279 üzenetére
A sbin a ramdisk része, tehát ha ott van egy busybox bináris már, akkor benn van alapban a boot lemezképben.
Terminal emuláatorban:
su
cd sbin
ls -l busyboxHa kiírja a jogokkal, akkor van, ha nem, akkor nincs. Amúgy a system/bin alatt szokott lenni, az sbin alatt többnyire csak symlink mutat rá.
-
Keeperv85
nagyúr
válasz
Just_Reboot #13316 üzenetére
Custom kernel? Tehát forrásból fordul. No, hát abba szépen bele lehet kódolni az OC lehetőségét. Csak tudni kell hogy hogyan kell...
-
Keeperv85
nagyúr
Igen. Pontosabban azt jelenti, hogy nincs vagy eltérő a PMT blokk, mint amire készülsz most feltenni. Ha viszont ezt megteszed, bármi módon is, akkor 99%-os valószínűséggel elszáll az nvram a partíciók átrendeződése miatt, szóval NEM ajánlott semmi módon ezt a lehetőséget SEM követni, már ami a Firmware Upgrade-t illeti. Arról már nem is beszélve, hogy mivel ahhoz tényleg minden kell, a preloader is, ha véletlen valami mégis balul sül el, annak ugye tudjuk mi a vége... Egy megoldás van jelenleg, ami nagyon kézenfekvő. PMT hiba > hagyd békén azt a cuccot, mert semmi jót nem jelent ez számunkra.
cappa72 mesterrel közben a háttérben azon dolgozunk, hogy az nv mentésekben ki lehessen cserélni előre az IMEI számot "offline", tehát úgy, hogy nem kell a készülék a folyamat előtt és nem kell semmi külső tool, ami adott esetben rendszer függő. Nekem pl. nincsen Windowsom, így az IMEI sérülése végzetes hiba. Ha viszont megtaláljuk a módját, hogy lehet hexa editorban visszaírni egy működő nv alá, akkor elszakadunk a Windows függéstől, mert azt elég gyorsan meg lehet más rendszerek alatt is oldani.
[ Szerkesztve ]
-
Keeperv85
nagyúr
"Mit értesz működő nv alatt?"
Nyilván egy olyan nv blokk tartalmát, amit nem törölt üresre valaki.
"Működő készüléken nem igazán lehet IMEI-t módositani, maradandóan biztosan semmilyen módon nem lehet."
Mit értesz működő készülék alatt? Mert ha most a bekapcsolt állapotra gondolsz: még akkor is lehet. Nagyon is! Csak gondolj a komplett nv cserére. Elég maradandó!
"Ezenkivül az IMEI utolsó számjegye "generálódik" az előző számjegyekből, nem tudom, ez befolyásolhat-e valamit."
Nem generálódik az a legtöbb esetben sehonnan. Szépen két byteonként rekurzívan be van írva a megfelelő helyre és ennyi. Tehát a legtöbb esetben nem encrypted. Egy egyszerű hexa editorral át lehet írni. Qualcomm esetén még program is van hozzá, ami a telón is, illetve "offline" a PC-n is be tudja írni az újat.
Factory upgrade: a flashtool nem gyártói cucc, hiába használják sokan úgy, mintha az lenne. Egy független fejlesztés. Ennek fényében semmi garancia arra, hogy békén hagyja az nv tartalmát, ha odébb kell tolni pl. az egész blokkot, pont a PMT helye miatt!
-
Keeperv85
nagyúr
"Mert csak az nvram tartalmának piszkálása semmit sem ér, attól nem fog változni az IMEI. Vagy helyreállni."
Én úgy tudom pont az nvram-ban van az IMEI, a BT és wifi MAC címe is. Tehát ha egyik telóról a másikra másolod az nvram.bin-t, akkor létrehozod a telefon klónját azonosítás szempontjából. Amennyiben ez nem így van, akkor viszont az IMEI lehet a kivétel, mert a MAC címek tutira az nvramban vannak. A protect_s, protect_f meghajtók tartalma nem tartozik az nv területhez. Kizárólag az nvram.
"Credits: Smart Phone Flash Tool created by MediaTek Inc..."
Hmm. Érdekes. Lehet átvették a fejlesztést. Ez mindenképp jó hír viszont!
"Egy, a sim2img progival kibontott img fájlt mivel lehet újra "visszacsomagolni"? Tehát ne tárolja le az üres helyeket is."
Kifelé ugye
sim2img system.img system.raw
Visszafelé:
Mountolod először:
mkdir mnt
mount -t ext4 system.raw mntMajd így:
make_ext4fs -s -l 1000M -a system system.img mnt/Nyilván akkora méretet adj meg, amekkora a system blokkod!
[ Szerkesztve ]
-
Keeperv85
nagyúr
"Ez a problema, különben elég egyszerű lenne sima nvram.bin editálással megoldani."
Nem volna, ha encrypted lenne. Sőt... Volt olyan teló, ahol az IMEI számot egy előre megadott számsor SHA1 kulcsából vágta ki a kód. Na most azt állítsd be olyanra, amire szeretnéd. A kimenet adott, de visszafelé ugye a hash nem megy...
"Nincs make_ext4fs parancsom"
Az baj! Tán le kéne fordítani egyet!
Mondjuk ebből... > [link]
-
Keeperv85
nagyúr
Hát ez így nem túl nyerő helyzet... már csak azért sem, mert az SD-t azért preferáljuk, mert hát ugye az külső. Ha elszáll az egész NAND esetleg, akkor is ott lesz. Ha kimosod véletlen a telót, akkor is. No de a belső tárhelyeket bármikor érheti bármi olyan hatás, hogy volt mentés, nincs mentés...
Lehet egyébként portforwarding útján rögtön PC-re is backupolni...
[ Szerkesztve ]
-
Keeperv85
nagyúr
Oh, látom van itt egy MTK szakértő...
BROM ERROR:S_DL_GET_DRAM_SETTING_FAIL(5054)
Erre valami okos ötlet? Hátha felkel a Haier-em és lesz egy 5. telóm is...
-
Keeperv85
nagyúr
válasz
BogyóBP #13537 üzenetére
Ez egy Haier w718+, mégpedig egy elég híres darab, ő ugyanis közszereplő lett egy projecben anno. Nem sérül egyik fájlt sem, lement a teljes format. Driver hiba nem lehet, két gépen is ugyan ezt a hibát dobta, egymástól ~300 km távolságban. Driver hiba kizárva amúgy is. Az aláírásom ha megnézed: mindegyik oda-vissza flashelhető ebben a konfigban. Flashtoolt végig próbáltam szinte mindet, a legújabbat is, beleértve a firmware update lehetőséget is. Ezen nem segít...
-
Keeperv85
nagyúr
válasz
fcrhs30 #13553 üzenetére
Szia! Nem gond, használhatod így. Ha nem baj nem fejteném ki, hogy az miért van ott, hacsak valaki nem kíváncsi rá...
-----------------------Többiek:
A Haier a piros csík után fekszik el így. Onnan sehová sem megy. Elvileg ez a gyári rom, amit próbálok visszatenni, hát gyakorlatilag megeshet olyan csúnyaság, hogy mégsem...
-
Keeperv85
nagyúr
-
Keeperv85
nagyúr
válasz
Orionhilles #13561 üzenetére
Szia!
A ramdisk része, még szép hogy visszaírja a kernel minden indításkor. Viszont ezt magában hiába bántod: patcheni kéne magát a vold binárist is. Feltételezem, ha lenne ilyen megoldás már, akkor rég kész is volna.
-
Keeperv85
nagyúr
válasz
Orionhilles #13563 üzenetére
Elsőre csak annyi. Ha utána nem jó, akkor tovább...
Új hozzászólás Aktív témák
Sok embernek van kérdése az Android rendszerrel kapcsolatban, mely igazán nem köthető gyártóhoz. Ebben a topikban lehet feltenni a szakmai kérdéseket, amelyek telefon/tábla függetlenek.
A Factory Reset Protection (FRP) megkerülésében nem nyújtunk segítséget!
- One plus 12 512/16
- Samsung Galaxy S21+ 5G 128GB, Kártyafüggetlen, 1 Év Garanciával
- !! 1 ÉV GARANCIA !! Független, Számlás, SAMSUNG GALAXY S22 ULTRA ZÖLD 256GB K3587
- !! 1 ÉV GARANCIA !! Független, Számlás,SAMSUNG GALAXY S22 ULTRA ZÖLD 256GB K3586
- !! 1 ÉV GARANCIA !! Független, Számlás, SAMSUNG GALAXY S22 ULTRA BURGUNDY 256GB K3589