Intel: il BIOS è morto, lunga vita a UEFI Class 3. Fine supporto nel 2020

[Insert coin]

Ho visto che si è parlato di obsolescenza programmata, ma sono l'unico al quale la scheda madre del Pc funziona ancora egregiamente dopo quasi 10 anni di onorato servizio? Pensate che ha resistito ad urti, cadute del case etc...

[zappy]

Originariamente inviato da Insert coin

Ho visto che si è parlato di obsolescenza programmata, ma sono l'unico al quale la scheda madre del Pc funziona ancora egregiamente dopo quasi 10 anni di onorato servizio? Pensate che ha resistito ad urti, cadute del case etc...

spesso l'obsolescenza è sw...
nel senso che non aggiornano/correggono bachi.
x gli smartphone x es è praticamente solo a livello sw che viene implementata l'obsolescenza.
UEFI mi pare un buon modo x portarla anche su PC, vista la maggior complessità e quindi la maggior probabilità che vi si riscontrino bachi (che basta non correggere x rendere obsoleto un oggetto che "elettricamente" funziona ancora benissimo.

[cdimauro]

Casomai è l'esatto contrario. Chi realizza firmware sono pochissime aziende, e i loro prodotti te li ritrovi poi in centinaia e centinaia di milioni di pezzi. Per cui si tratta di roba di gran lunga più testata e matura rispetto ai vari boot loader et similia.

Un firmware è uno dei codici più mission-critical (al pari di scheduler e filesystem), e dunque molto più oggetto di attenzioni e test rispetto ad altre tipologie di codice.

[fano]

Originariamente inviato da cdimauro

Cesare!

Ops!

Originariamente inviato da cdimauro

GOP non l'ho ancora approfondito, ma devo ancora finire di leggere il malloppo che (manco a farlo apposta ) sto macinando in questo periodo ("Beyond BIOS. Developing with the Unified Extensible Firmare Interface")

Se ricordo bene è la stessa cosa funziona solo prima di chiamare ExitBootServices() e quindi non puoi usarlo nel tuo OS.

Originariamente inviato da cdimauro

Dipende tutto da come decidi di implementare il tuo s.o..

Com'è riportato nel libro in questione (pag. 80-81, sezione "Transitioning to an OS Kernel"), se chiami ExitBootServices vuol dire che hai deciso di prendere il pieno controllo del sistema, e quindi ti rimangono a disposizione soltanto gli UEFI Runtime Services (descritti nel capitolo 5, pag. 83-101), che sono veramente poca roba (ci sono una manciata di API. Utili, per carità, ma è pochissimo).

La furbata, IMO, sta nel fatto di NON chiamare ExitBootServices, e quindi continuare a usare tutte le (numerose!) API a disposizione in questo stadio, che ti permettono perfino di leggere e scrivere file coi filesystem supportati da UEFI (FAT12/16/32, ed El Torito -> supporti ottici).

Tutto ciò è comodissimo perché ti consente di evitare di implementare tutta questa roba, visto che ce l'hai già, e dedicarti esclusivamente alla progettazione & implementazione della struttura del s.o. (API & annesse strutture dati).

Si potrà fare un "misto" cioè far continuare a "girare" UEFI per avere accesso alla Console e GOP, ma per dire scriversi il tuo "driver" per leggere / scrivere dischi NTFS? O mi bloccherebbe totalmente l'accesso all'hardware sottostante?

Originariamente inviato da cdimauro

Accedendo direttamente al framebuffer della GPU.

Mi chiedo appunto se sia possibile farlo con UEFI che ha il pieno controllo dell'hardware.

Originariamente inviato da cdimauro

A parte gli scherzi, è uno scenario plausibile che venga rimosso il vecchio BIOS, e devo ancora vedere quale rimpiazzo offre UEFI (tra l'altro sono fermo alla 2.3 e mi devo aggiornare con le nuove funzionalità della 3.0), visto che ti permette di avere console testuali e grafiche, per cui un modo per lavorare con la scheda video ce l'ha già integrato.

Non riesco a trovare un documento della versione 3.0 sarebbe bello se dessero a disposizione più servizi a run-time così da fare il lavoro che il BIOS aveva promesso 30 anni fa: astrarre totalmente l'hardware!
Anche il fatto di avere i driver in UEFI sembrava una f*cata poi credo proprio perché è stato implementato male non sono mai stati usati...

[cdimauro]

Originariamente inviato da fano

Se ricordo bene è la stessa cosa funziona solo prima di chiamare ExitBootServices() e quindi non puoi usarlo nel tuo OS.

Non è un problema: non avrei intenzione di fare a meno dei boot services. Sono troppo comodi.

Si potrà fare un "misto" cioè far continuare a "girare" UEFI per avere accesso alla Console e GOP, ma per dire scriversi il tuo "driver" per leggere / scrivere dischi NTFS? O mi bloccherebbe totalmente l'accesso all'hardware sottostante?

Sì, è possibile. Era uno degli obiettivi di UEFI, quello di mettere a disposizione dei driver per tutti i s.o..

Mi chiedo appunto se sia possibile farlo con UEFI che ha il pieno controllo dell'hardware.

L'UEFI rimane pur sempre al servizio dell'applicazione UEFI, per cui dovrebbe essere possibile.

Il mio problema è che al momento non ho avuto modo di sperimentare, e quindi sporcarmi e toccare con mano come funziona concretamente il tutto, anche se il desiderio è enorme.

Non riesco a trovare un documento della versione 3.0 sarebbe bello se dessero a disposizione più servizi a run-time così da fare il lavoro che il BIOS aveva promesso 30 anni fa: astrarre totalmente l'hardware!

Esattamente.

Anche il fatto di avere i driver in UEFI sembrava una f*cata poi credo proprio perché è stato implementato male non sono mai stati usati...

Come dicevo prima, non ho ancora sperimentato per capire quali sarebbero le problematiche che sono scaturite coi driver UEFI.

[fano]

Io purtroppo ho capito così: se UEFI controlla l'hardware tu non puoi scrivere un driver nella maniera "classica" cioè accedendo alle I/O port ecc... forse è possibile farlo alla UEFI, ma se hai realizzato ormai un OS da più di 10 anni (il caso di Cosmos) con la vecchia filosofia e vuoi comunque mantenere la compatibilità con hardware no UEFI non puoi / vuoi farlo.

Riguardo la Console sembra sia possibile accederci anche anche dopo ExitBootServices() usando le "Global Variables" ce ne sono 3 che sono i classici stdin, stderr e stdout quindi quello si dovrebbe poter fare non so se puoi fare cose "fiche" con quegli handle come cambiare il colore di sfondo, "giocare" con il cursore, ecc... cose che la classe Console di C# mi richiederebbe in ogni caso
Purtroppo non dicono molto su come vanno usati questi path quindi boh?

Anche per GOP sembra sia possibile avere almeno l'accesso al LFB, ma anche in questo caso non ho capito come...

Ma perché GOP lo hanno limitato ai BootServices? Io non la capisco sta limitazione i complottisti dicono che l'hanno fatto apposta per favorire Windows (che ha i driver nativi), ma io a sta cosa meschina non ci credo...
Cosa ne pensi?

[cdimauro]

Originariamente inviato da fano

Io purtroppo ho capito così: se UEFI controlla l'hardware tu non puoi scrivere un driver nella maniera "classica" cioè accedendo alle I/O port ecc... forse è possibile farlo alla UEFI, ma se hai realizzato ormai un OS da più di 10 anni (il caso di Cosmos) con la vecchia filosofia e vuoi comunque mantenere la compatibilità con hardware no UEFI non puoi / vuoi farlo.

Su questo devo approfondire, ma comunque, se ci pensi bene, un eventuale limite del genera avrebbe senso, visto che lo scopo di UEFI è fare le veci del vecchio BIOS, provvedendo però a mettere sul piatto parecchi comodi strumenti per inizializzare l'ambiente e caricare il kernel (o il boot loader; che però IMO non serve più con l'UEFI: al massimo lo installa una sola volta come applicazione UEFI).

Riguardo la Console sembra sia possibile accederci anche anche dopo ExitBootServices() usando le "Global Variables" ce ne sono 3 che sono i classici stdin, stderr e stdout quindi quello si dovrebbe poter fare non so se puoi fare cose "fiche" con quegli handle come cambiare il colore di sfondo, "giocare" con il cursore, ecc... cose che la classe Console di C# mi richiederebbe in ogni caso
Purtroppo non dicono molto su come vanno usati questi path quindi boh?

No, i servizi console non sono disponibili dopo ExitBootServices(): non sono elencati nei runtime services.

Anche per GOP sembra sia possibile avere almeno l'accesso al LFB, ma anche in questo caso non ho capito come...

Sì, mi sono documentato e confermo che è possibile accedere al LFB.

Ma perché GOP lo hanno limitato ai BootServices? Io non la capisco sta limitazione i complottisti dicono che l'hanno fatto apposta per favorire Windows (che ha i driver nativi), ma io a sta cosa meschina non ci credo...
Cosa ne pensi?

No, assolutamente. Il motivo è semplice: GOP è l'equivalente dei servizi VGA/VESA, ed è nato per sostituirli. Ma questo esclusivamente in funzione di lanciare il s.o..

UEFI non nasce per scrivere s.o., ma per facilitarne l'inizializzazione e l'avvio. Purtroppo. Anche se a me piacerebbe che lo arricchissero, visto che alla fine tanti s.o. devono reinventarsi sempre la ruota per fare esattamente le stesse cose.