En resumen: si no aparece la pantalla del BIOS, comprueba el hardware antes de volver a flashear nada
Una ZimaBoard 232 que muestra un LED rojo fijo pero nunca muestra el firmware está fallando antes de llegar al sistema operativo. Las memorias USB de arranque con Linux o CasaOS no pueden ayudar hasta que la placa complete el POST y genere salida de vídeo del firmware. El orden seguro es alimentación → ruta de vídeo → RTC/CMOS → hardware mínimo → recuperación del BIOS solo con el paquete correcto y siguiendo las indicaciones de soporte.
No consideres el LED rojo por sí solo una prueba completa del estado
La respuesta de soporte de 2025 interpretó la secuencia de LED posterior a la extracción del RTC como una comprobación automática correcta, pero la placa seguía sin mostrar vídeo utilizable. Para solucionar el problema, utiliza varias señales: enlace/actividad de Ethernet, concesión DHCP, respuesta de los LED del teclado, señal de pantalla y si las teclas de acceso rápido del firmware tienen algún efecto. Un solo LED no debe prevalecer sobre pruebas contradictorias.
Elimina por completo la cadena de pantalla
- Usa una ruta Mini DisplayPort y un monitor que sepas que funcionan correctamente.
- Selecciona manualmente la entrada del monitor en lugar de depender de la detección automática.
- Conecta la pantalla antes de aplicar la alimentación.
- Prueba las teclas del firmware durante el encendido.
- Comprueba al mismo tiempo si el router muestra una concesión DHCP.
El hardware original de ZimaBoard incorpora Mini DisplayPort 1.2. Los puertos de hardware de ZimaBoard son la referencia actual del hardware.
En esta fase, la máquina sigue estando en el ámbito del firmware, no del sistema operativo. El modelo de firmware UEFI describe la capa de arranque previa al sistema operativo, mientras que los estándares DisplayPort proporcionan el contexto del enlace de pantalla. Estas referencias no diagnostican la placa por sí solas, pero refuerzan por qué debe existir vídeo del firmware antes de que una USB con el sistema operativo sea relevante.
Restablece el RTC/CMOS una vez y vuelve a probar con los valores predeterminados conocidos
Apaga completamente el equipo, desconecta la alimentación de entrada y restablece el estado del RTC/CMOS. Después del restablecimiento, no vuelvas a conectar inmediatamente todos los periféricos. Empieza con la alimentación, el monitor, Ethernet y el teclado. Si la placa llega ahora al firmware, carga los valores predeterminados antes de cambiar la configuración de arranque o alimentación.
Un restablecimiento de CMOS puede recuperar una configuración incorrecta del firmware; no puede reparar una memoria flash dañada, los raíles de alimentación ni los componentes de la placa.
Por qué una USB de arranque no diagnostica una placa que no completa el POST
Si no puedes acceder al firmware, el sistema nunca llega lo bastante lejos como para ejecutar el cargador de arranque de la USB. Probar varias imágenes de sistemas operativos demuestra muy poco en esta fase. Deja la solución de problemas de instalación para cuando F11 o la selección de arranque sean realmente visibles.
La recuperación de la instalación de ZimaOS separa los fallos del firmware de los del instalador.
No flashees el BIOS a ciegas en una placa que no muestra el firmware
El material actual de ZimaSpace sobre el BIOS de la ZimaBoard original advierte que no se recomiendan las actualizaciones del BIOS en placas que funcionan normalmente y que una operación incorrecta puede impedir el arranque de la placa. Si una unidad que no completa el POST necesita un flasheo de recuperación, solicita a soporte el procedimiento exacto específico para la placa en lugar de utilizar un paquete de BIOS de ZimaCube o ZimaBoard 2.
La versión del BIOS de ZimaBoard es específica del modelo. La recuperación del firmware UEFI depende del fabricante del hardware; no existe un método universal y seguro para volver a flashearlo mediante USB.
Usa el hardware mínimo para distinguir un fallo de la placa de uno de los periféricos
Desconecta las unidades SATA externas, las tarjetas PCIe y los dispositivos USB innecesarios. Prueba la placa con su configuración compatible más sencilla. Si vuelve el vídeo o la red, añade el hardware de nuevo, un elemento cada vez. Una tarjeta de expansión defectuosa o una carga de alimentación excesiva pueden imitar un fallo de la placa base.
Cuándo la sustitución o el servicio a nivel de placa son el siguiente paso lógico
Si una alimentación y un equipo de pantalla que sabes que funcionan correctamente, el restablecimiento del RTC y una configuración de hardware mínima siguen sin producir BIOS, DHCP ni una respuesta útil del firmware, detén los ciclos repetidos de encendido. Recopila la secuencia de LED y los resultados de las pruebas para el equipo de soporte. El hardware de ZimaBoard 2 solo es relevante si la sustitución o actualización resulta preferible a reparar la placa.
Preguntas frecuentes
¿Un LED rojo fijo de ZimaBoard significa que el POST se completó correctamente?
Es una señal de diagnóstico, pero no debe considerarse una prueba de que todas las etapas del firmware y la salida de pantalla funcionan correctamente.
¿Puedo solucionar la falta de vídeo reinstalando CasaOS o ZimaOS?
No, si la placa nunca llega al BIOS ni al menú de arranque. La recuperación del sistema operativo ocurre después del POST del firmware.
¿Debo retirar la batería del RTC?
Un restablecimiento único del RTC/CMOS es un paso razonable para recuperar la configuración del firmware cuando la placa no completa el POST con normalidad.
¿Puedo instalar el BIOS de una ZimaCube en una ZimaBoard?
No. Los paquetes de BIOS y los procedimientos de recuperación son específicos del modelo. Utiliza únicamente el paquete y el procedimiento exactos destinados a la ZimaBoard original.
¿Cuándo debo contactar con el soporte de hardware?
Después de que las pruebas con una alimentación y una pantalla que funcionen correctamente, el restablecimiento del RTC y las pruebas con el hardware mínimo sigan sin producir una pantalla del firmware ni indicios de red.
