Un defecto visible rara vez revela por sí solo la capa defectuosa. La pantalla negra podría significar un arranque interrumpido, un perfil de panel incorrecto, una sesión DRM no válida o un marco producido que nunca llegó al cristal. Por lo tanto, el diagnóstico comienza con la última evidencia confiable, no con el componente más fácil de reemplazar.
Regla general: una salida limpia del proceso no prueba que la pantalla mostrara la imagen. Una prueba por computadora tampoco reemplaza la validación en una computadora portátil.
El orden de la investigación.
- Fija el objetivo. Dispositivo de registro, revisión, DTB activo, hashes y versión del sistema.
- Localiza la última capa viva. LED, serial, banner U-Boot, inicio del kernel, ensamblaje del sistema, apertura de sesión DRM y presentación del primer cuadro son diferentes hitos.
- Mida antes de cambiar. Preservar el registro mínimo que diferencia dos hipótesis.
- Cambiar una variable. Vuelva a hacer la misma prueba y compare la evidencia.
- Validar en hardware. La pantalla, los controles, el audio y la sesión de juego deben observarse en el dispositivo del perfil.
Problemas que ya enseñaron algo.
Reiniciar antes del kernel
En una variante R36S v12, la descompresión ZSTD parecía ser la causa del reinicio. La investigación aisló otra fuente: faltaba un búfer de memoria segura BL32/TOS en esa combinación de arranque. ZSTD fue solo el primer consumidor en tocar la región problemática. La reserva de la memoria interrumpió el reseteo en la prueba física; esto, por sí solo, no certificaba la salida visual.
Lección: el punto donde aparece el error puede ser simplemente el primer observador del defecto.
El sistema funciona, pero el vidrio permanece negro.
Hubo una sesión en la que SDL con KMSDRM/GLES2 produjo fotogramas y finalizó sin errores, mientras que la pantalla física permaneció en negro. Por otro lado, el importador del perfil había descartado polaridades con valor cero, a pesar de que cero era un valor explícito y válido.
Lección: preservar valores explícitos, incluido el cero, y tratar renderizou y ficou visível como prueba separada.
Combinación técnicamente válida, pero no homologada.
Un ensamblaje pasó la validación estática y aún mostraba una pantalla negra y se reiniciaba en el R36S. El hash y la procedencia confirmaron los bytes, pero no la compatibilidad física de esa combinación de cargador, confianza, U-Boot, kernel, DTB y módulos.
Lección: Integrity responde "¿es el archivo esperado?". La aprobación responde "¿funciona en este hardware?". Son preguntas diferentes.
árbol rápido
| Evidencia observada | Capa inicial | Siguiente prueba útil |
|---|---|---|
| Sin alimentación, LED o serie | Base física y arranque inicial. | Energía, medios y primeros bytes de arranque. |
| Aparece U-Boot, el kernel no se inicia | Inicio | Direcciones, reservas de memoria y artefactos del grupo |
| El kernel se inicia, el sistema no se monta | Kernel y rootfs | Dispositivo de bloque, módulos y montaje. |
| La interfaz se abre, la pantalla no se muestra | Perfil, DRM y panel | Maestro DRM, conector, modo, polaridades y prueba visual |
| El menú funciona, el juego falla | Núcleo, contenido o configuración | Registro de sesión, núcleo seleccionado y archivo de entrada |
| El juego comienza con mal ritmo. | Rendimiento | FPS reales, frametime, audio, temperatura y perfil activo |
Cómo registrar una solución
Un registro útil contiene: síntoma reproducible, objetivo exacto, última capa probada, hipótesis descartada, cambio mínimo, resultado antes y después y estado de validación física. Si aún es necesario probar el dispositivo, escríbalo explícitamente. "Pasado al host" no debe quedar "fijado en el hardware".