UEFI: Fechando a série

Na coluna anterior examinamos algumas das vantagens que os sistemas baseados em UEFI oferecem quando comparados ao velho BIOS, citamos alguns sistemas operacionais que já oferecem suporte à especificação UEFI e encerramos a coluna informando que discutiríamos hoje a forma pela qual é feito o gerenciamento das partições nos dispositivos de armazenamento de massa e os serviços que a UEFI pode oferecer mesmo depois que o controle da máquina passa às mãos do sistema operacional. Então vamos adiante.

Colaborando com o SO

Diferentemente dos sistemas baseados em BIOS, que seguem um procedimento praticamente inflexível desde o momento em que a máquina é ligada até saírem completamente de cena quando o sistema operacional é carregado e assume o controle total da máquina, os sistemas baseados em UEFI podem prolongar sua ação mesmo após a carga do sistema operacional. Isto é conseguido subdividindo os “serviços” fornecidos pela UEFI em duas categorias, como mencionado na coluna “UEFI: Como funciona“: “serviços de inicialização” (“boot services”) e “serviços em tempo de execução” (“runtime services“). Vamos ver como isto funciona.

[singlepic id=3348 w=320 h=240 float=]

A Figura 1 (obtida em um artigo técnico da MS) mostra um diagrama simplificado do fluxo de inicialização de um sistema baseado em UEFI ao carregar Windows. As ações se desencadeiam a partir do topo do diagrama e o primeiro passo, representado pelo objeto “UEFI firmware”, é executado pelas rotinas incluídas no “firmware” UEFI, ou seja, nos circuitos de memória não volátil da placa-mãe que contêm as rotinas de inicialização.

As primeiras ações consistem na execução dos serviços de inicialização dos circuitos auxiliares da placa-mãe (“chipset“), seguidas do carregamento na memória dos gerenciadores de dispositivos (“drivers“) fornecidos com o hardware e das rotinas que contêm os serviços utilizados para gerenciar e auxiliar a carga do sistema operacional. Esta é a primeira fase do procedimento de partida e os “serviços” por ela carregados são os “serviços de inicialização” (“boot services“).

Os “serviços de inicialização” se limitam aos gerenciadores genéricos do “console” (teclado e vídeo) e um sistema de arquivos bastante limitado. Estas rotinas visam tornar o hardware acessível ao usuário e apenas permanecem funcionais durante a fase inicial do procedimento de partida, ao final do qual tem início o segundo passo: a carga do “UEFI boot manager“, ou gerenciador de inicialização UEFI (isto porque, como também mencionado anteriormente, as rotinas de inicialização de um sistema baseado em UEFI constituem quase um minissistema operacional e uma de suas funcionalidades é a possibilidade de gerenciar a carga de diferentes sistemas operacionais em uma mesma máquina caso o fornecedor da placa-mãe inclua o suporte a esta função no “firmware“).

A partir deste ponto passam a ser carregados os “serviços em tempo de execução” (“runtime services“). Eles incluem serviços como o gerenciamento de hora e data e suas rotinas permanecem armazenadas em um circuito de memória não volátil (mostrado na figura como NVRAM, de “Non Volatile RAM”) que podem ser acessadas pelo sistema operacional quando este último assumir o controle da máquina. Para facilitar a comunicação do SO e dos dispositivos de hardware com estas rotinas, todos os gerenciadores de dispositivos desenvolvidos de acordo com a especificação UEFI, assim como as demais rotinas que se constituem nos “serviços em tempo de execução”, se intercomunicam utilizando um protocolo específico estabelecido pela especificação UEFI.

O que dota a especificação UEFI de sua notável flexibilidade e facilita a incorporação de tecnologias como a ACPI, mencionada na coluna anterior, é justamente esta possibilidade de incluir entre as rotinas de inicialização algumas que permanecem habilitadas e ativas mesmo depois da carga do sistema operacional e são capazes de interagir com ele.

Na Figura 1 o gerenciador de inicialização UEFI carregou o Windows Boot Manager, que dá início à carga de Windows e “chama” o “Windows OS Loader” (carregador do sistema operacional Windows) que, finalmente, carrega na memória o cerne (“kernel“) do sistema. Mas, evidentemente, qualquer outro SO poderia ter sido carregado caso invocado pelo gerenciador de inicialização UEFI. E, qualquer que fosse ele, continuaria podendo interagir com os serviços em tempo de execução carregados pela UEFI.