Uma falha visível raramente revela sozinha a camada que falhou. Tela preta pode significar boot interrompido, perfil de painel incorreto, sessão DRM inválida ou um quadro produzido que nunca chegou ao vidro. Por isso, o diagnóstico começa pela última evidência confiável, não pelo componente mais fácil de trocar.
Regra de trabalho: uma saída limpa do processo não prova que a tela exibiu a imagem. Um teste no computador também não substitui a validação no portátil.
A ordem de investigação
- Fixe o alvo. Registre aparelho, revisão, DTB ativo, hashes e versão do sistema.
- Localize a última camada viva. LED, serial, banner do U-Boot, início do kernel, montagem do sistema, abertura da sessão DRM e apresentação do primeiro quadro são marcos diferentes.
- Meça antes de alterar. Preserve o log mínimo que diferencia duas hipóteses.
- Mude uma variável. Refaça o mesmo teste e compare a evidência.
- Valide no hardware. Tela, controles, áudio e sessão de jogo precisam ser observados no aparelho do perfil.
Problemas que já ensinaram algo
Reinício antes do kernel
Em uma variante R36S v12, a descompressão ZSTD pareceu ser a causa do reinício. A investigação isolou outra origem: uma reserva de memória segura BL32/TOS ausente naquela combinação de boot. O ZSTD apenas foi o primeiro consumidor a tocar a região problemática. Reservar a memória interrompeu o reset no teste físico; isso não certificou, por si só, a saída visual.
Lição: o ponto onde o erro aparece pode ser apenas o primeiro observador do defeito.
Sistema executa, mas o vidro permanece preto
Houve sessão em que SDL com KMSDRM/GLES2 produziu quadros e encerrou sem erro, enquanto a tela física continuou preta. Em outra frente, o importador do perfil havia descartado polaridades com valor zero, embora zero fosse um valor explícito e válido.
Lição: preserve valores explícitos, inclusive zero, e trate renderizou e ficou visível como evidências distintas.
Combinação tecnicamente válida, mas não homologada
Uma montagem passou pela validação estática e ainda assim apresentou tela preta e reinício no R36S. Hash e proveniência confirmavam os bytes, mas não a compatibilidade física daquela combinação de loader, trust, U-Boot, kernel, DTB e módulos.
Lição: integridade responde “é o arquivo esperado?”. Homologação responde “funciona neste hardware?”. São perguntas diferentes.
Árvore rápida
| Evidência observada | Camada inicial | Próxima prova útil |
|---|---|---|
| Sem energia, LED ou serial | Base física e boot inicial | Alimentação, mídia e primeiros bytes do boot |
| U-Boot aparece, kernel não inicia | Inicialização | Endereços, reservas de memória e artefatos do conjunto |
| Kernel inicia, sistema não monta | Kernel e rootfs | Dispositivo de bloco, módulos e montagem |
| Interface abre, tela não mostra | Perfil, DRM e painel | DRM master, conector, modo, polaridades e teste visual |
| Menu funciona, jogo falha | Núcleo, conteúdo ou configuração | Log da sessão, núcleo selecionado e arquivo de entrada |
| Jogo abre com ritmo ruim | Desempenho | FPS real, frametime, áudio, temperatura e perfil ativo |
Como registrar uma solução
Um registro útil contém: sintoma reproduzível, alvo exato, última camada comprovada, hipótese descartada, alteração mínima, resultado antes e depois e estado da validação física. Se ainda falta teste no aparelho, escreva isso de forma explícita. “Passou no host” não deve virar “corrigido no hardware”.