Gustavo Sied > Sin categoría > UEFI y ARM

UEFI y ARM

5 febrero, 2014 0 Comentarios

Sin categoría

Introducción

UEFI [Universal Extensible Firmware Interface] es un estándar para la implementación del gestores de arranque y la interfaz entre el gestor de arranque y el sistema operativo. />

Ventajas

  • API fijo y ABI
  • tipo Extended anotaciones [como, IN / OUT / INOUT de argumentos de la función]. Esta teoría puede ayudar a detectar algunos errores de codificación en tiempo de compilación.
  • Proporcionar gama IO y descripciones de IRQ (como ACPI) para sistemas ARM

Desventajas

  • Fue diseñado por Microsoft e Intel (por lo tanto, la hinchazón de código innecesario)
  • Todo el código se ejecuta en el mismo espacio de direcciones, el acceso MMIO no está protegido por la capacidad o cualquier otra garantía mecanismo. Si bien la situación es la misma con otros gestores de arranque y el uso de la asignación de memoria uno a uno compartido entre todos los componentes [procesos o bibliotecas] permite utilizar el gestor de arranque en los sistemas sin MMU, UEFI fue ideado para proporcionar una cadena segura de fiduciario para el proceso de arranque y

Servicios UEFI

Dado que los servicios de UEFI son PE / COFF binarios, que exportan los símbolos a través de las tablas de importación / exportación. Esto permite para buscar las funciones necesarias en los módulos binarios. UEFI define una serie de servicios. Por ejemplo, el gestor de arranque inicial puede basarse en el gestor de arranque UEFI para la lectura de datos del disco. La parte que me confunde es que la mayoría de estos servicios se destruyen con las ExitBootServices () llamada, y el único servicio útil disponible en tiempo de ejecución es el servicio RTC / temporizador. Dado que el sistema operativo no puede piggy-back en el gestor de arranque para todos sus rutinas de controlador, ¿por qué introducir un bootloader complejo en absoluto? Lo hace entregar vulnerabilidades potenciales, pero no tiene ventajas sobre la BIOS, en términos de inicialización del hardware.

TianoCore EDK2 y UEFI en ARM

TianoCore EDK2 es una implementación de referencia de Intel UEFI. Viene con varios paquetes interesantes y se puede utilizar para construir dos gestores de arranque UEFI y aplicaciones independientes para los sistemas que ya están funcionando UEFI (como, la mayoría de placas de nivel de consumidor y las computadoras portátiles disponibles en el mercado)

  • ArmPkg – contiene el cargador de Linux y los controladores para las CPU (Cortex A8, A9, A15) – caché, interrupciones (GIC), Timer
  • ArmPlatformPkg – contiene los controladores UART, GPIO y ni de la ARM plataformas de referencia, las rutinas de preparación TrustZone, manejo de excepciones y la pila de código de conmutación
  • CryptoPkg – contiene los contenedores para OpenSSL para permitir el uso de criptografía (por ejemplo, para el arranque UEFI Secure)
  • DuetPkg – la paquete para probarlo UEFI en un equipo X86
  • EdkShellPkg – la cáscara UEFI que permite navegar controlador de almacenamiento masivo, arrancar imágenes personalizadas e interactuar con los conductores a través de las variables de configuración
  • MdePkg – contiene el tiempo de ejecución servicios y HAL (Hardware Abstraction Layer) para PCI y otros buses
  • NetworkPkg -. contiene el soporte para IPv6, DHCP, TFTP y SCSI (obviamente, para el arranque por red)
  • Nt32Pkg – servicios Bootloader de Windows 7 Embedded
  • OvmfPkg – Emulación de ACPI y Virtio
  • PcAtChipsetPkg – obviamente el soporte x86 -. Timer, PIC, HPET y los controladores de puente PCI
  • stdlib – Biblioteca de EFI y tomas de corriente

Creo que esta implementación particular es una mierda. Lo que podía soportar con el código ilegible, el hecho de que tienes que poner todas las definiciones como en tres archivos (plataforma, archivos de mesa y. Ini). Pero. La implementación de referencia sólo funciona para ARM BeagleBoard. Para PandaBoard, el código fuente se establece claramente que «el controlador de pantalla está rota y eliminando el comentario que conduce a la congelación misteriosa». He pasado algún tiempo la piratería en él, pero todavía no me las arreglo para conseguir el funcionamiento de la pantalla. Ni el MMC. En PandaBoard, simplemente no funcionó. El Galaxy Nexus, que comenzó a trabajar después de que yo cambié desde el modo de bloque para el modo de transmisión «no admitido» en el código de host mmc genérico. Weird.

Procesos de Windows RT Bootup

Windows RT es un puerto de Windows 8 para la arquitectura ARM. Aquí, el UEFI se utiliza para emular una configuración X86 en ARM: las tablas ACPI y estados de energía. Además, UEFI se utiliza para consultar la IO rangos para los controladores de periféricos (se sabe que la mayoría de los SoC ARM utilizan asignado en memoria IO para periféricos con el acceso y las únicas cosas que un sistema operativo tiene que preocuparse son la gama IO y el pin IRQ. Este es lo UEFI proporciona). Por lo tanto, la ventaja de la UEFI es que permite compilar el kernel del sistema operativo y los controladores una vez y usarlo en varias juntas.

Para Windows RT y Windows Phone 8, el proceso de arranque se inicia con el gestor de arranque UEFI cargar el archivo bootarm.efi. A continuación, intenta leer la tabla (Boot Configuration Data) BCD y montar la partición raíz. No confían en UEFI para la lectura de la unidad en esta etapa. Siguiente, el control se transfiere al núcleo de Windows NT que llama a los ExitBootServices () de rutina y carga el controlador de bloque nativo. Hasta ahora, me las he arreglado para dividir la unidad flash usb correctamente y arrancar el bootarm.efi y hacerla reconocer la partición en qemu emulando el BeagleBoard, pero eso es todo.

Alternativas

kernel Linux ha recientemente también ganó el apoyo para la construcción de mutiple SoC en un núcleo. Usted puede tener un solo núcleo que arranca en la OMAP, Tegra y qué no. La ventaja es que usted puede tener un conductor a bordo del lado del núcleo que inicializar los controladores con los datos necesarios que elimina la necesidad de emulación de ACPI y complejos programas de análisis de tabla binarios.

Supongamos que usted es un fabricante de hardware mal querer ocultar los detalles de su tarjeta y no contribuir código para linux. ¿Qué hacer entonces? Derecho, utilice DTS o Árbol de Dispositivos. Se originó en los MACs PowerPC, el árbol de dispositivos aplanado fue posteriormente portado a ARM y ahora es compatible con el cargador de arranque u-boot y kernels Linux y FreeBSD. Permite describir todos los periféricos y los parámetros del controlador en un formato de texto jerárquico que a su vez tampoco pueden pasar al núcleo como es o compilado a un formato binario humano ilegible (que es la seguridad por oscuridad, por supuesto, pero eso es lo que piensan los desarrolladores de propiedad es cool) .
Vamos a echar un vistazo al archivo FTD para una placa tegra tomado de u-boot. Me parece estupendo que se puede especificar todo – oscila IO, GPIO y pins de IRQ. Si el código BSP está escrito correctamente, usted puede conseguir lejos con la escritura de ningún BBcode, sólo declarativa IO mapa Descripción.