OldComp.cz

Venoval jsem chvili casu disassemblingu Boot PROMky, a je to zajimave. Je tam pomerne dlouha cast hned po startu, ktera inicializuje zakladni periferie, testuje "data path" (zda obvody na desce alespon nejak odpovidaji, testuje se napr. zapisem do vice registru nejakeho obvodu a pak zpetnym ctenim), nebo inicializuje a zjistuje velikost RAMky. Zadny z tohohle kodu (ktery je opravdu kilometrovy) nepotrebuje ke sve fci nic krome registru procesoru, hodnoty ktere se nevchazely si ten POST uklada do floating point registru. Tohle jsem jeste nikde nevidel, zatim kazda bootrom vyzadovala alespon funkcni kousek nejake RAMky.

Dalsi zajimavost je, ze DMA controller v memory controlleru se pouziva na clear pameti. Pro emulaci tohle musi byt peklo, protoze oni dokonce nejprve testuji, zda se DMA rozebehlo:



(emulace v MAME spousti DMA na timer, coz mi prijde jako strelit se do nohy ...)

Nez se rozjede grafika, je tam nejaky seriovy port, na ktery to sype vzdy textove kde co selhalo. Pouzivaji tam na seriak Zilog 85230, ktery je zrejme jako IP blok nekolikrat pouzit v jejich IOC2. Cele tohle bezi bez jedineho bajtu potrebne RAM.


PS: Uplne si nejsem jist jestli takovehle veci tady nekoho zajimaji. A to obecne, i treba s tou mapou CSSR pocitacu a operacnich systemu (nemusim tady spamovat, mam na mailu par vytrvalych pomocniku).

Za mne - rád si přečtu, ne vždy je čas reagovat (a známe to - kdo nezareaguje hned a nechá to na později, nemisí se k tomu už vrátit…).
Je to toiž opravdu zajímavé.
Tichá většina to hádám má stejně.

No jenom abyste nebyli ta "ticha vetsina" nakonec dva .

Par dalsich zajimavosti:

- V ARCS firmware (ta boot ROM, https://en.wikipedia.org/wiki/ARCS_(computing) ) vidim znamky moznosti prepnuti z BIG endian na Little endian. AFAIK nebyl zadny obecny system krome Windows NT, ktery by mipsel pouzival, takze mozna byl nejaky plan tam mit moznost behat WinNT ? Jen spekuluji. Muze jit taky o nejaky historicky relikt spoluprace RISC vendori & MS.

- Zajimavosti taky je, ze ARCS firmware se nejak propsal do x86 NTLOADERu (non-UEFI), napr. tam jsou podobne cesty - v SGI Indy ARCS se najdou retezce jako "scsi(%d)disk(%d)part(%d)". Mozna tohle Microsoft z nejakeho duvodu chtel pouzit i na PC, nakonec tu mame UEFI

- ARCS z 90. let exposuje sluzby pro kernel podobne jako UEFI - na nejake adrese je struktura, ze ktere se daji vytahnout pointery na fce typu print, open, atd. Akorat to neni "extensible".

- Prestoze SGI Indy BootROM je 32bitova, procesor R4600 je 64bitovy. Doplneni 64bit instrukci do 32bit ISA je tak jen o pridani par dalsich opkodu, na load/store 64bit hodnot a pak vypocty nad 64bit (SPARC tohle ma jestli se nepletu bez rozdilu, je jedno kolikabitove cislo scitam). Tohle mi napr. proti x86 prijde nadherne ciste reseni.

- MIPS mi prijde tez zajimavy primitivnim memory managementem (TLB), kde je jen par radek TLB, kdyz dojde k "miss"-u, je vyvolana exception, ktera musi TLB naplnit spravnou radkou. Tohle mely i nejake PowerPC. A MIPS ma take branch delay, tzn. kdyz dam instrukci skoku (call,jmp), tak se provede jeste nasledujici instrukce aby se neplytvalo pipeline (to jsou ty nopy za skoky v kodu v mem predchozim postu). Oboji je samozrejme slepa ulicka, ale zajimavy zpusob jak s minimem gates vytriskat maximum vykonu.