CoreELEC arm boot probléma

Miniszámítógépek, SBC-k

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?

( ricsip v | 2024. 12. 12., cs – 09:32 )

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 :)

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.

Eddig csak BS-et találtam, és azt h. nincs univerzális BIOS az ARM-on, minden gyártó egyéni hekkelésekkel dolgozik.

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.

Szólj majd, ha találtál bármi tényleg használható okosítást :)

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.

( wince | 2024. 12. 12., cs – 11:11 )

Szerkesztve: 2024. 12. 12., cs – 11:16

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.
 

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.

( Czo v | 2024. 12. 12., cs – 22:34 )

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? 

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.

A két MBR között 0x01b0 cím után volt csak eltérés

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?

( kikadff v | 2024. 12. 13., p – 07:48 )

Szerkesztve: 2024. 12. 13., p – 07:55

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á.

( plt | 2024. 12. 13., p – 12:17 )

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ő.

Ö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)...

( atlantic | 2024. 12. 13., p – 21:01 )

Szerkesztve: 2024. 12. 13., p – 21:23

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:

...
cfgloadsd=if fatload mmc 0:1 ${loadaddr} cfgload; then setenv device mmc; setenv devnr 0; setenv partnr 1; autoscr ${loadaddr}; fi
cfgloadusb=if fatload usb 0:1 ${loadaddr} cfgload; then setenv device usb; setenv devnr 0; setenv partnr 1; autoscr ${loadaddr}; fi
...
bootfromsd=if mmcinfo; then run cfgloadsd; if fatload mmc 0 ${loadaddr} kernel.img; then run sddtb; setenv bootargs ${bootargs} bootfromsd; bootm; fi; fi
bootfromusb=usb start 0; run cfgloadusb; if fatload usb 0 ${loadaddr} kernel.img; then run usbdtb; setenv bootargs ${bootargs} bootfromusb; bootm; fi