Üvd! Hogyan lehet komplett ROMot kidolgozni?

Hát mondjuk oprendszer írásához szerintem a Java-nál egy csöppet alacsonyabb szinten kell tudni programozni. Az Operációs rendszerek c. könyv elolvasása nem lenne haszontalan.

> Én szeretném minden apró részletét kidolgozni

Ezekbe remélem a memóriaszervezést, feladatütemezést és egyéb finomságokat is beleértetted. :)

"Írtam már programokat.."

Azokat miben írtad?

#2: Egy Android custom ROM-ról van szó, ami nagyrész Java-t jelent.

Itt nézz körül:

[link]

#2 vagyok

#4: A "nagyrészt" kifejezés és a linkedről elérhető első tutorial is (ami C kódokat mutat) igazolja, amit mondtam. :) De ne felejtsük el, hogy a kérdező "maga szeretne operációsrendszert írni", ami szerintem a nullás számú rajtkockát jelenti, ellentétben a kusztomizációval.

Így lehet írni egy operációs rendszert:

https://www.youtube.com/watch?v=6MJUGVFAXKg

Oprendszert nem hasraütésszerűen írnak, hanem az egy komplet szoftvercsomag.

Oprendszert célrendszerre írnak, nem csak úgy általában véve. (hogy egy párat említsek: x86, x64, armel, armhf...)

Második szintű bootloaderrel indul a rendszered, amit az UEFI/bios/FSBL indít el.

Nos írhatsz külön bootloader indító programot, de ide már beágyazott rendszer programozás kellene, Assembly-C nyelveken, és nagyon erős célprocesszor utasításkészlet/periféria/buszrendszer ismeret.

HA mégse akarsz komplet biost írni, akkor rátérhetsz a második szintű bootloaderekre. (tableteknél ezt a CPU-ba flashelik, alapból ezzel nincs dolgod. Ez inicializálja fel a NAND flasht vagy az SD kártyát, és a 0-ás szektorából betölti a második szintű bootloadert.)

[link]

De gondolom ezt se akarod egyedül kiszenvedni debugginggal (másoknak is több évtizedes melója volt), azt javaslom, hogy fordíts egy már meglévőt. (grub, uboot, redboot...). Ez a bootloader tölti be a kerneledet a memóriába és egy adott belépési ponton elindítja azt.

[link]

A kernel fordítás az egy system architect művészet, nem programozás, de így is agyizzasztó feladat. Ebbe minden olyan perifériád driverjét, hardvertámogatását bele kell fordítanod, amit használni akarsz a későbbiekben, méghozzá gyártóra és típusra helyesen. (tablet esetében: processzor utasításkészlet kiegészítések, kijelző vezérlő, érintőképernyő vezérlő, SD kártya vezérlő, fájlrendszerek, GPIO nyomógomb és ledvezérlő, webkamera támogatás, HDMI támogatás, integrált GPU vezérlő program, nyers audio kodekek az audio perifériához ... pontpontpont ...)

Ha megvagy a kernellel is, és véletlenyjen pöpec módra minden elsőre elindulna (egyedül kb 1-2 hétnyi munkaidős szenvedés, custom, kernel.orgon nem támogatott driver programozás nélkül), akkor sem vagy kész, mert utána buildelned kell egy userspace szintű operációs rendszert (pl android, yocto, debian, ubuntu, Xiaomi, BSD, windowsCE, windows10...). és még ekkor sem biztos, hogy minden perifériádat tudod használni, mert az user level oprendszerek kernel verzió függőek, mert nem mindegyikben van meg ugyanaz az api, amit az oprendszered hívogatna belőle. Ezen inkább a béta tesztelők szokták felkötni magukat, mintsem a system builderek, nekik az integrált disztróépítőben a gyári szoftverkomponensek mind fordulnak. A probléma csak akkor van, ha valaki nagyon egzotikus szolgáltatást vagy appet akarna befordítani, amihez eddig a bolygón még nem írtak receptet, így neked improvizálnod kell.

Ennél a pontnál már nyilván rájöttél, hogy még az open-source android rendszert sem egy fő készíti, hanem sok-sok-sok ember összehangolt munkájának eredményeként jön létre (és annak hiányosságaival). Mindenkinek megvan a maga kis jól behatárolt szerepköre. Ez bootloaderes, ez kerneles, ez driveres, ez kijelzőkalibrálós, ez GPU-s, ez démonos, ez android-frémwörkös, ez app-level, ez meg béta teszter specialista csávó, hogy egypárat említsek.