- AMD openSIL es una librería abierta y modular que reemplazará progresivamente a AGESA como base de inicialización del silicio.
- Su arquitectura se basa en tres bibliotecas (xSIM, xPRF y xUSL) que se integran estáticamente con distintos firmwares anfitriones.
- La transición comienza en servidores (EPYC Genoa, Turin y Venice) y plataformas como Phoenix y AM5 con Zen 5, culminando con Zen 6 y Zen 7.
- Busca mejorar seguridad, transparencia y escalabilidad del firmware, permitiendo auditoría y colaboración de comunidad y socios.
Si sigues de cerca el hardware de PC, seguro que últimamente has oído hablar de AMD openSIL como sustituto de AGESA y quizá te preguntas qué es exactamente, por qué es tan importante y qué va a significar para tu próxima placa base o servidor. No es un simple cambio de BIOS, sino un giro profundo en cómo se inicializa el silicio de AMD, con un enfoque abierto y modular.
En las últimas conferencias y pruebas públicas, se ha visto cómo AMD acelera el salto hacia un firmware abierto, con prototipos funcionales ya ejecutándose en hardware real, desde servidores EPYC hasta plataformas AM5 con procesadores Zen 5 y SoC Phoenix. Todo apunta a una transición gradual que culminará con Zen 6 y que terminará enterrando definitivamente a AGESA, tanto en equipos de consumo como en entornos profesionales.
Qué es AMD openSIL y en qué se diferencia de AGESA
AMD openSIL (Open-Source Silicon Initialization Library) es una nueva arquitectura de firmware pensada para encargarse de la inicialización del silicio en plataformas x86 de AMD, reemplazando de forma progresiva a la veterana biblioteca AGESA. Su objetivo es mover buena parte de la lógica crítica de arranque a un conjunto de librerías de código abierto, reutilizables y auditables, que se integran de forma estática con distintos tipos de firmware anfitrión.
Por contra, AGESA (AMD Generic Encapsulated Software Architecture) es la pila cerrada que desde 2011 ha sido el corazón de las BIOS en placas base AMD64. AGESA se encarga de tareas como la inicialización de los núcleos de CPU, el chipset, la memoria principal y el controlador HyperTransport (en generaciones antiguas), además de coordinarse con la SMU y otros bloques internos del procesador en las familias Ryzen y EPYC modernas.
Durante unos años, AMD llegó a publicar versiones abiertas de AGESA para ayudar al desarrollo de Coreboot, pero ese esfuerzo se quedó limitado a la familia de procesadores Bulldozer (Bulldozer, Piledriver, Steamroller y Excavator). A partir de ahí, las nuevas generaciones dejaron de contar con lanzamientos públicos, y AGESA se consolidó como un componente cada vez más complejo y opaco.
Con openSIL, AMD quiere volver a la idea original de ofrecer una base de firmware sencilla, transparente, extensible y realmente abierta, capaz de integrarse tanto con UEFI tradicional como con soluciones alternativas como Coreboot, oreboot, FortiBIOS o Project µ. El objetivo es que cualquier proveedor de firmware o fabricante de placas pueda enlazar estas librerías y construir sobre ellas sin quedar atado a paquetes binarios cerrados.
Arquitectura interna de openSIL: las tres librerías clave
La propuesta técnica de AMD se articula en torno a tres bibliotecas principales que se vinculan estáticamente al firmware anfitrión en tiempo de compilación. En lugar de exponer una gran monolito como AGESA, openSIL divide responsabilidades en módulos bien definidos.
La primera pieza es xSIM (x86 Silicon Initialization Library), que proporciona la API necesaria para la inicialización básica de la plataforma anfitriona. Aquí entran funciones críticas como el entrenamiento de memoria, la inicialización DRAM conforme a JEDEC, la configuración del controlador de memoria y el acondicionamiento de señales, algo que también preocupa a usuarios que realizan overclocking de memoria RAM. En la práctica, xSIM se encarga de que la memoria del sistema esté disponible en cuanto se libera el reinicio x86.
En segundo lugar está xPRF (x86 Platform Reference Library), orientada a componentes de hardware dependientes de la placa. Incluye servicios para configurar GPIO, controladores en modo SMM y manejadores de eventos como RAS, entre otros elementos sujetos al diseño concreto del PCB. Es la capa que permite adaptar openSIL a topologías reales de placas base, VRM, rutas eléctricas y dispositivos específicos.
La tercera pieza es xUSL (x86 Utility and Service Library), un conjunto de utilidades internas que dan soporte tanto a xSIM como a xPRF. Estos controladores y servicios no se exponen directamente al firmware anfitrión, sino que funcionan como infraestructura común para las otras dos librerías.
Este reparto modular permite que los desarrolladores añadan soporte para nuevo hardware de forma más rápida y mantenible, tanto en firmwares UEFI clásicos como en entornos alternativos. En lugar de mantener múltiples ramas de firmware para cada equipo, se reutiliza el mismo núcleo de inicialización de silicio y se adaptan únicamente las piezas dependientes de la placa.
Motivos del cambio: límites de AGESA y ventajas del modelo abierto
Tras más de una década en servicio, AGESA se ha convertido en un bloque extremadamente complejo, con muchísimo código heredado y una integración muy profunda con todo el ecosistema AMD. Esa misma complejidad ha dado pie a numerosos problemas de estabilidad, bugs difíciles de reproducir y una velocidad de reacción limitada ante vulnerabilidades de seguridad.
Aunque AGESA está sobradamente parcheada y madura, igualar su estabilidad con un nuevo sistema como openSIL va a requerir tiempo. Sin embargo, AMD considera que mantener el modelo actual ya no es sostenible: la demanda de transparencia, las exigencias de ciberseguridad y la necesidad de escalar a nuevas arquitecturas y modelos de firmware hacen que el enfoque cerrado sea un freno.
Con openSIL, la compañía busca un ecosistema en el que la comunidad y los socios puedan auditar, revisar y mejorar el código, identificando fallos de seguridad, mejorando la cobertura de pruebas y reduciendo la superficie de ataque mediante una arquitectura más limpia. Abrir también las especificaciones permite que otros fabricantes de silicio evalúen participar y, potencialmente, adopten la misma filosofía.
En las presentaciones oficiales, AMD enfatiza que openSIL debe ser ligero, sencillo, transparente, seguro y fácil de ampliar. Eso contrasta con la percepción actual de AGESA en el mercado doméstico, donde muchos usuarios y fabricantes lo ven como un componente algo opaco, pesado y con un historial de problemas en ciertas configuraciones de memoria o combinaciones de CPU y placa base.
Además, al convertir openSIL en una base común para UEFI, Coreboot, LinuxBoot y otros proyectos, se facilita el soporte de plataformas variadas, desde servidores de alto rendimiento hasta equipos embebidos, Chromebooks y, más adelante, PCs de escritorio y portátiles convencionales.
Hoja de ruta oficial: fases del proyecto y plazos de despliegue
AMD ha ido definiendo un plan en varias etapas para llevar openSIL desde un prototipo cerrado hasta un firmware listo para uso generalizado. Esta hoja de ruta combina hitos de desarrollo, publicaciones de código y despliegues en productos reales.
La primera fase se llevó a cabo a puerta cerrada, centrada en crear un prototipo funcional de la plataforma sin exposición pública. Esa etapa permitió validar el concepto de arquitectura abierta y modular antes de enseñar nada a la comunidad.
En la fase 2, ya completada, AMD publicó el código de un prototipo openSIL para una plataforma CRB con procesadores EPYC de cuarta generación (Genoa). Ese código está disponible en GitHub y sirve como prueba de concepto, permitiendo a los desarrolladores estudiar la arquitectura y empezar a experimentar con ella.
La tercera etapa, que se extiende hasta el cuarto trimestre de 2024, tiene como objetivo llevar el prototipo a un estado apto para uso más amplio, con una arquitectura pulida, documentación y herramientas de integración con diferentes firmwares anfitriones como Coreboot y AMI Aptio OpenEdition.
Mirando un poco más allá, AMD ha marcado 2026 como el año en que llegará el primer firmware UEFI comercial basado en openSIL. En paralelo, se trabaja en guías detalladas para integrarlo con Coreboot y otras soluciones, además de publicar la especificación completa de la arquitectura de firmware openSIL.
openSIL en plataformas reales: EPYC, Phoenix y AM5 con Zen 5
Más allá de las transparencias de conferencia, lo realmente interesante es que openSIL ya se está ejecutando sobre hardware real. Hay varios frentes públicos: servidores EPYC, SoC Phoenix y, más recientemente, placas base AM5 con procesadores Zen 5.
En el ámbito de los servidores, AMD mostró pruebas de concepto con EPYC Genoa en repositorios de GitHub hace un par de años, y posteriormente librerías adaptadas a la arquitectura Turin (Zen 5 para servidor) que siguen recibiendo pequeñas actualizaciones. Estas implementaciones permiten a los desarrolladores y proveedores de firmware empezar a trabajar sobre plataformas críticas de datacenter.
Un paso clave ha sido la publicación del código de openSIL para los SoC Phoenix, confirmando el plan de migrar estas APU desde AGESA a la nueva arquitectura. Aunque AMD llegó algo más tarde de lo que pretendía (quería hacerlo en 2024), el lanzamiento demuestra que la compañía mantiene el compromiso de plantear openSIL como un proyecto abierto, con ramas específicas como “Phoenix_poc” en GitHub.
Quizá el movimiento que más ha llamado la atención a la comunidad entusiasta es la validación de openSIL en una placa base comercial AM5 con Zen 5: la MSI PRO B850-P. El equipo de 3MDEB ha conseguido portar el firmware a este modelo, ejecutándolo fuera del entorno controlado de AMD y sin soporte oficial de la propia MSI.
Ese port implica lidiar con detalles muy concretos de la placa como el diseño de VRM, la topología de memoria, controladores integrados y las limitaciones físicas del PCB, lo que convierte a esta placa en un testbench para verificar hardware. Que openSIL funcione en estas condiciones demuestra que la arquitectura empieza a ser lo bastante sólida como para salir del laboratorio y entrar en el terreno de los fabricantes y la comunidad.
Relación con Coreboot, Linux y otros firmwares alternativos
Uno de los puntos fuertes de openSIL es que nace desde el principio con vocación multipila, es decir, pensada para convivir con distintos modelos de firmware anfitrión sin imponer UEFI como única vía. Esto contrasta con la pila actual basada en AGESA, muy centrada en UEFI como firmware del host.
AMD ha demostrado integraciones de openSIL tanto con UEFI como con Coreboot en eventos como la Cumbre Regional de la Open Compute Project Foundation en Praga. También se han citado explícitamente otras soluciones como LinuxBoot, oreboot, FortiBIOS o Project µ como firmwares con los que se busca compatibilidad.
Esta flexibilidad es especialmente relevante para dispositivos donde Coreboot y Linux tienen un peso importante, como Chromebooks o determinados servidores y equipos embebidos. De hecho, Raj Kapoor, arquitecto jefe de firmware en AMD, explicó los desafíos a los que se enfrentaron al intentar adaptar AGESA a Coreboot en dispositivos Ryzen orientados a Chrome OS.
Con openSIL se espera que Linux y los entornos abiertos tengan la vida bastante más fácil, al poder apoyarse en una base de inicialización transparente y bien documentada. Queda por ver, eso sí, hasta qué punto esta misma flexibilidad se llevará a PCs con Windows, equipos sin sistema operativo preinstalado y placas base retail de escritorio.
AMD, al mismo tiempo, ha invitado a otros proveedores de silicio a participar en el desarrollo y evolución de openSIL, aunque la experiencia previa con proyectos “a medias” por parte de la compañía aconseja mantener un cierto grado de cautela hasta que veamos implementaciones masivas en el mercado.
Impacto para fabricantes de placas, empresas y usuarios finales
Para los fabricantes de placas base, el cambio a openSIL supone más libertad y más responsabilidad a la vez. Por un lado, el modelo abierto les da mayor control sobre el firmware, menos dependencia de paquetes cerrados y ciclos de desarrollo más claros. Por otro, reduce el margen para echar balones fuera cuando surgen fallos o problemas de estabilidad.
En entornos empresariales y de servidor, la transparencia de la cadena de arranque se ha vuelto un factor crítico, especialmente con el despliegue masivo de sistemas de IA y cargas sensibles. Contar con firmware auditable y con trazabilidad mejorada (incluyendo SBOM) permite reforzar las estrategias de ciberseguridad y cumplir requisitos normativos cada vez más exigentes, y exige también entender cuestiones como el ECC integrado en DDR5.
AMD espera que openSIL mejore la seguridad, funcionalidad y escalabilidad de la plataforma, ampliando la cobertura de pruebas para validar sistemas completos, facilitar tests de penetración más profundos y tener un seguimiento unificado de vulnerabilidades. El objetivo es que tanto los binarios de firmware como sus componentes internos sean rastreables y comprobables.
Para las empresas tecnológicas que construyen soluciones alrededor del firmware (por ejemplo, para gestión remota, telemetría o automatización de despliegues), un entorno abierto como openSIL abre la puerta a pipelines de actualización más avanzados, con integración en nubes como AWS o Azure, monitorización continua de instalaciones y paneles BI (Power BI u otros) para detectar anomalías en arranques, consumos o comportamiento térmico.
En cuanto al usuario doméstico, de momento no hay impacto directo en su día a día. Seguimos en un mundo dominado por BIOS basadas en AGESA, sin versiones listas para flashear con openSIL. La fase actual es de porting, pruebas y validación por parte de desarrolladores y socios, así que todavía queda recorrido antes de que un usuario final se encuentre con una placa comercial con openSIL de serie.
Transición por generaciones: de Zen 5 a Zen 7
El calendario que se va perfilando indica una transición escalonada que abarca varias arquitecturas de CPU, empezando por el entorno servidor y extendiéndose al resto de gamas de producto en unos pocos años.
Lo primero que veremos, salvo cambios de planes, es la adopción de openSIL en servidores EPYC Venice, la generación basada en Zen 6 que llegará después de EPYC Turin (Zen 5), prevista para finales de 2025. Todo apunta a que Venice será la primera familia de AMD en estrenar openSIL a gran escala.
En paralelo, las APU Phoenix ya tienen disponible código de openSIL como alternativa a AGESA, lo que encaja con el compromiso de AMD de migrar estas plataformas alrededor de 2024-2025, aunque con algo de retraso respecto al plan inicial. El soporte continuado en GitHub demuestra que el proyecto está vivo y en evolución.
Para el ecosistema AM5, las pruebas en Zen 5 con placas como la MSI PRO B850-P sirven como banco de pruebas dentro del ciclo de vida actual, sin arriesgar una arquitectura completamente nueva desde el primer día. Esto permite ir afinando compatibilidad, estabilidad y rendimiento antes de lanzar Zen 6 ya apoyado de lleno en openSIL.
Las hojas de ruta que se han ido filtrando y comentando apuntan a que Zen 6 aprovechará openSIL como plataforma principal, con el objetivo de tener la transición prácticamente cerrada en 2026. A partir de ahí, con Zen 7, se espera que AGESA haya desaparecido por completo, probablemente coincidiendo con nuevos sockets y plataformas.
En conjunto, todo este movimiento indica que AMD no está esperando pasivamente a Zen 6 para mover ficha, sino que ya está haciendo pruebas reales con Zen 5 y potenciando el ecosistema de desarrollo alrededor de openSIL para que la llegada del nuevo firmware no implique un salto al vacío.
Mirando todo lo anterior, queda bastante claro que openSIL se perfila como una pieza clave en la estrategia futura de AMD: un firmware de inicialización abierto, modular y orientado a largo plazo que busca mejorar seguridad, transparencia y flexibilidad, a costa de una transición compleja que llevará años y exigirá mucha colaboración entre AMD, fabricantes, comunidad y empresas de software que operan encima de esta nueva capa fundamental.
