Van egy X96MaxPlus médiaboxom, amin CoreElec fut egy SD kártyáról.
Hetek óta halott a Youtube plugin, így gondoltam frissítek. Felfrissítettem a 21.1-es legújabb változatra, de a Youtube plugin továbbra sem működik. Más videókat rendben lejátszik azóta is. Gondoltam, egy másik SD kártyára telepítek egy szűz CoreELEC példányt, és tesztelem ott is a Youtube plugin-t, működik-e. És innentől jön a furcsaság.
Az új telepítés nem boot-ol SD krátyáról. Pontosabban akkor nem boot-ol, ha az SD kártyát az SD kártya slotba dugom. Ha egy USB-SD átalakítóval dugom be a boxba, akkor rendben boot-ol és települ. De ha telepítés után közvetlenül az SD csatlakozóba teszem vissza a kártyát, akkor ismét nem indul el - vagyis a belső android indul ilyenkor. Újra az USB átalakítóval bedugva ismét indul a rendszer.
Az régi, eredeti SD kártyát visszatéve az SD csatlakozóba, a rendszer továbbra is indul SD kártyáról.
Mi a trükkje az ARM booot-olásnak? Át tudom valahogy klónozni a működő kártyám indulási képességét az új kártyára? Tudtok erről valami részletesebb infót?
Hozzászólások
30+ év x86 után én még nem bírtam felfogni az ARM boot folyamatát, pedig pár hete elkezdtem a témában YT anyagot keresni. Eddig csak BS-et találtam, és azt h. nincs univerzális BIOS az ARM-on, minden gyártó egyéni hekkelésekkel dolgozik. De nekem már az is elég lenne, ha azt meg tudnám érteni h. melyik lépés az amit hekkelnie kell minden ARM gyártónak, és step-by-step összehasonlítanák az x86-on működő BIOS módszerrel.
Szólj majd, ha találtál bármi tényleg használható okosítást :)
Én is csak annyit tudok, hogy a konkrét termékhez kell keresni a saját 0. lépést, de utána pl. UEFI már használható.
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?
A lényeg nem az, hogy nem boot-ol, hanem hogy ugyanezen termék ugyanezen szoftver előző verziójáról frissítve boot-ol, új telepítésnél meg nem.
Amikor annakidején először megpróbáltam feltelepíteni, akkor sem indult. Hagytam, majd pár hónap múlva egy újabb verzióval újrapróbáltam, és az örömömre, rendesen indult. Azóta is azt a telepítést frissítem.
Tehát valami egyedi beállítás vagy trükk, vagy valami arm valami.
Ha tudnám, hogy hogyan boot-ol az arm, az lehet, segítene.
Mindkét SD-n megvan a boot flag a partíción, tehát a két boot partícó tartalma között kellene lennie a különbségnek. Szerintem.
könnyen meglehet, hogy újabb kernel újabb boot megoldás.
Az armos kínai média boxok libreelec futtatáshoz eleve sokszor a firmware update folyamatot térítik el, hogy átirányítsák a kártyán lévő rendszerre a boot folyamatot.
A régi s905-ös boxomon már nem is tud bootolni a friss libre/coreelec, nem támogatott. Az egyel újabb s905x boxom is is csak félig meddig.
Van kifejezetten amlogic boxos ph topic is, ott lehet van már tapasztalat vele
https://prohardver.hu/tema/amlogic_s905_s912_processzoros_keszulekek/ke…
De ha minden igaz, akkor a kártyára írás után dtb fájl odamásolás, átnevezés is kell, ki kell választani, hogy melyik kell ahhoz a konkrét fajta dobozhoz.
Ez így van. Az egységes BIOS hiánya miatt semmiféle szabványos boot folyamat nem létezik ARM-on, gyártónként más-más. Még csak az sem biztos, az ARM processzor bootol.
Raspberry Pi-ről tudok mesélni, az Broadcom SoC-os, amiben a fő processzor a GPU, az ARM csak egy segédprocesszor.
Itt bekapcsolás után a VC GPU fut, ez
- ROM-ból futtat egy kis proggit, ami betölti a bootcode.bin fájlt a PWM-ben tárolt sorszámú partícióról
- a bootcode.bin fájl VC natív utasításokat tartalmazó bináris, lényegében egy ELF parser, ami betölti a start.elf-et ugyanarról a partícióról
- a start.elf szintén VC natív kódot tartalmaz, ez értelmezi a konfigurációs fájlt (config.txt), tölti be az ARM binárist (kernel8.img), inicializálja a Mailbox interfészt (amit aztán az ARM bináris használhat)
- ezután a start.elf a memória elejére másolja az ARM indító kódját (ennek forrása itt olvasható), majd ráránt az ARM reset vonalára
- az ARM processzor ezután elkezdi a memória elejéről futtatni az utasításokat, amiket a VC rakott oda, ez alaphelyzetbe rakja a megszakításokat, spinloop-ba rakja az AP-kat, a BSP-n meg az ARM bináris (kernel8.img) első bájtjára ugrik
Az ARM bináris betöltési címe 0x80000, és egy MZ futtatható, iszonyat gányolással. Az MZ fejléc ugyanis egy értelmetlen ARM utasítás, így az azt követő ugrás utasítás adja át a vezérlést a tényleges UEFI-mentes belépési pontra (UEFI esetén az MZ fejlécben szereplő címen lévő PE fejlécbeli UEFI-kompatíbilis belépési pont használatos). Legalábbis Linux kernel esetén ez van az ARM binárisban. Egyébként bármilyen ARM kódot rakhatsz a kernel8.img-be, nem kötelező az MZ fejléc.
Köszi ez érdekes volt, nem tudtam hogy az RPi így bootol, azt hittem egyszerűbb a dolog.
Annyit tennék hozzá, hogy bár nincs egységes BIOS, és az adott hardvert (PCIe, USB, clocksourceok, CPU-k, stb.) device tree írja le, de ha bármilyen u-boot bootloader van az eszközön, abból betölteni egy kernelt vagy egy újabb u-bootot már nem reménytelen. Amennyire tapasztaltam az lehet nehézség, ha a board ARM Trusted Firmware enegdélyezett, vagyis be van égetve hogy melyik eMMC-ről vagy NAND-ról és milyen aláírással tölthet be bootloadert, de ha ez megvan, abból a bootloaderből egy másik, újabb és szebb bootloadert/kernelt chainloadolni már lehetséges. Persze ehhez is emészthető módon tovább kell passzolni a device tree binárist, hogy tudja milyen hardveren fut, de lehetséges.
Sebtiben ezt találtam ami érdekes lehet:
https://www.armbian.com/soc/s905x3/
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?
Nem tudom, hogy a CoreELEC mennyire armbian. De azért köszi, nézem még, hátha segít.
https://github.com/anxdpanic/plugin.video.youtube/releases
Az unofficialt kell feltenni zip-ből és kikapcsolni a a frissítést egy ideig ennél a csomagnál.
Szerintem nem érintkezik rendesen az a microsd, vagy 4gb alatti valami régi és a hardver nem szereti.
Nincs trükkje, a win32diskimager rávágja, az első szektort keresi és behúzza.
Szerintem a kontak hiba nem játszik, mivel mindig az új telepítés nem boot-ol, de az eredeti ige.
Formátum hibának sem gondolnám, mert USB-be dugott SD átalakítóval mindig boot-ol, anélkül meg nem.
Szerintem valami viccesebb trükkje van.
megnéztem https://wiki.coreelec.org/coreelec:ce_dev_cycle#development_status hogy 20-as és 21-es verziót is támogatja ennél a procinál NG-s kernellel
Igen, elvileg csontra mennie kellene. Ezért kéne jobban ismernem a boot folyamatot, hogy megtalálhassam, hol akad el mégis.
Végiggondolva a kontakt-hiba ötletedet, rájöttem, hogy ez mégiscsak lehet probléma, ha maga az SD kártya hibás, és bedugva nem érintkezik jól a foglalatba, de az USB átalakító foglalatába pedig már jól érintkezik. Ezért elindítottam SD nélkül, és miután bejött az android, bedugtam a hibás SD-t. De sajnos felismerte, tudta kezelni, látta a fájlokat, tehát ez az is SD jól érintkezik a foglalatba. :(
Pedig jó gondolat volt.
Nem tudom, hogy milyen bootloader van a boardodon, de pl. nekem van egy TS7800-as boardom (2008 ota megvan, ARMv5), ott az MBR-ben van specialis ATAG ertek az SD kartyan. Ha ez nem stimmel, akkor arrol az SD-rol nem bootol. https://docs.embeddedts.com/TS-7800#ATAGS lehet, hogy itt is valami hasonlo dolog van?
Jól gyanítom, hogyha ilyen ATAG probléma lenne, akkor USB átalakítóba bedugva az SD kártyát, sem lenne szabad elindulnia?
Ez attol fugg, hogy mi van a bootloadered kodjaban :D pl. probakent en atvinnem az MBR bootblokcjat a jo SD-rol, a rossz SD-re.
Hogy tudom egy SD kártya MBR rekordját olvasni írni? Hol van az egyáltalán rajta?
A 0. sector, tehat az elso 512 byte az MBR. Ebben van a particios tabla is, ertelemszeruen, azt hagyd ki a masolasnal. Illetve, erdekes lehet, az elso sector es az elso particio adatterulete kozotti "lyuk" is, mert ott is lehet akar elbujt program. En baltaval (dd) ugy csinalnam, hogy kimentenem a mukodo particios tablat (64 byte), majd felulcsapnam az egesz MBR-t, illetve a particio elotti "ures" helyet a mukodovel, vegul vissza dd-znem a kimentett particios tablat az MBR-be.
Sajnos ez sem segített. A két MBR között 0x01b0 cím után volt csak eltérés, így a jó MBR tartalmával felülírtam a nem induló SD kártyát.
Továbbra sem indult.
Visszatettem az USB átalakítóba, elindult, telepítette is magát, újra is indult onnan rendben, visszatéve az SD foglalatba, ismét nem indul.
Az még bőven a partíciós tábla előtt van, tipikusan ide szokás pakolni a konfigurációt. Szerintem ezt is másold át 0x1be-ig.
Egyébként a Linux kernel már iszonyat rég nem használ ATAG-eket ARM-on, évek óta átálltak már FDT-re. Nem ismerem ezt a CoreELEC-et, de gyanítom, nem ARMv5-ös, sokkal inkább ARMv7-es vagy ARMv8-as lesz. Csak tipp.
Az ARM-es gépek esetetén az, hogy az ARM kernel betöltődik, már a nagyon sokadik lépés. Simán lehet, hogy firmware fájlok hiányoznak a nem működő SD-ről (amikre csak akkor van szükség, ha onnan bootolnál, ha USB-ről, akkor már nem is keresi ezeket). Első lépésként azonosítani kéne a bootloadert, valamilyen UBoot vagy teljesen custom?
Az új telepítésnél szerintem nincs a kártyára "flash"-elve a bootloader ezért az alap androidos bootloader indul, ami usb-rol el tudja indítani az új telepítést, vagy ha az nincs akkor magát az androidot. SD kártya slotot meg nem nézi. Csak tippelgetek.
Nem teljesen ugyanaz, de kiindulásnak talán jó. Azt kellene megnézni mit csinál az sd_fusing.sh, csinalt-e olyasmit a te OS-ed telepitője
Már ott tartok, hogy a boot partíció teljes tartalmát átmásoltam a működő kártyáról a nem induló kártyára. Maguk a partíciók is azonosak, bár az induló rendszernél van a legvégén egy pici maradék üres partíció.
Az érdekessége, hogy a boot partíció előtt is van mindegyik kártyán egy 4MiB méretű lefoglalatlan terület. Lehet, hogy ebben van valami eltérés? Ez mi lehet?
A bootloader fájlokat nem a particiora kell másolni, hanem a kártyára közvetlen. Nem /dev/sda1, hanem /dev/sda. A telepítő nem ajánlott fel ilyesmit? Szerintem kellett volna neki, de utólag is helyre lehet rázni, csak tudni kell miket kell oda másolni.
Ez hátha hasznos és nem volt még meg.
A telepítéshez egy disk image-et kapok, amit magára az eszközre kell írni, ebből lesznek aztán a partíciók, meg az a kezdő üres 4MiB is. Ha van bootloader a partíciókon kívül, akkor gondolom, az van abban az első 4Mib üres részben. De ahhoz nem tudom, milyen eszközzel férnék hozzá.
Szerintem is. Hogyan írtad a kártyára az img-t? Elvileg annak mindent kellene tartalmaznia. A Wiki oldalon lévő dtb masolast- atnevezest is csinaltad, vagy az már rendben volt az img-ben?
A dtb másolás megvolt, de az már a boot partíción van. És ugye USB átalakítóval indul is, tehát a tartalma elvileg jó.
Az image-et a balenaEtcher-rel írtam ki, de ezzel írtam a működőt is anno.
Nem ismerem a CoreELEC-et, wiki írja a boot method-ot, ezeket probáltad? Menu Button tűnik érdekesnek, korábban kellett ezzel szórakozni, vagy csak simán boot-olt az sd kártyáról?
Köszönöm, próbálgattam, nem segítettek. Egyébként emlékeim szerint a működő változat feltelepítésénél semmi csoda nem volt. Amikor megvettem a boxot, akkor nem ment, aztán amikor újra próbáltam pár hónappal később, már ment, és el is könyveltem magamban, hogy biztos javítottak valami bug-ot. Azóta meg csak frissítek.
Összességében még mindig azt nem látom, mi lehet a különbség a futó és a nem futó SD között, főleg, ha fájlrendszer szinten azonos már a kettő.
Ebben egészen biztos vagy? Tuti nincs valami plusz fájl a működő SD-n (akár bootloader, akár firmware)? De ha már, lehet egy speciális partíció is a különbség, vagy bootloader esetén partíción kívül is lehet adat (mondjuk az MBR utáni szektor és az első partíció közötti területen)...
szia, nem tudom, ez segít-e valamennyire debuggolni a problémát, de van ez a kis tool, a neve fw_printenv, ami kiírja az U-Boot bootloader környezeti változóit. Talán abból jobban ki lehet következtetni, hogyan történik a boot. Illetve itt belemélyülhetsz az U-Boot-ba. Remélem segít.
Itt pedig arhitektúra-specifikus dokumentációt találsz az U-Boot-ról: https://docs.u-boot.org/en/latest/arch/arm64.html
Ez pedig board specifikus dokumentáció, ha jól látom, az általad említett box-ban Amlogic S905X van, tehát az Amlogic féle flow vonatkozik rá: https://docs.u-boot.org/en/latest/board/amlogic/boot-flow.html
Itt találsz még tutorialokat: https://docs.u-boot.org/en/latest/learn/talks.html - a beginner intro kezdésnek jónak tűnik.
Nálam egy Ugoos AM6B Plus (Amlogic S922X-J) box esetén pl. van különbség, ha SD-ről vagy ha USB-ről bootol: