A visible flaw rarely reveals the failed layer on its own. Black screen could mean interrupted boot, incorrect panel profile, invalid DRM session, or a produced frame that never made it to the glass. Therefore, the diagnosis starts with the last reliable evidence, not with the easiest component to replace.
Rule of thumb: A clean process exit does not prove that the screen displayed the image. A computer test also does not replace validation on a laptop.
The order of investigation
- Fix the target. Record device, revision, active DTB, hashes and system version.
- Locate the last living layer. LED, serial, U-Boot banner, kernel start, system assembly, DRM session opening and first frame presentation are different milestones.
- Measure before changing. Preserve the minimum log that differentiates two hypotheses.
- Change a variable. Redo the same test and compare the evidence.
- Validate on hardware. Screen, controls, audio and game session need to be observed on the profile's device.
Problems that already taught something
Reboot before kernel
On an R36S v12 variant, ZSTD decompression appeared to be the cause of the restart. The investigation isolated another source: a missing BL32/TOS secure memory buffer in that boot combination. ZSTD was just the first consumer to touch the problem region. Reserving the memory interrupted the reset in the physical test; this did not, in itself, certify the visual output.
Lesson: the point where the error appears may just be the first observer of the defect.
System runs, but glass remains black
There was a session in which SDL with KMSDRM/GLES2 produced frames and ended without error, while the physical screen remained black. On another front, the profile importer had discarded polarities with a zero value, even though zero was an explicit and valid value.
Lesson: preserve explicit values, including zero, and treat renderizou and ficou visível as separate evidence.
Technically valid combination, but not approved
An assembly passed static validation and still showed a black screen and restart on the R36S. Hash and provenance confirmed the bytes, but not the physical compatibility of that combination of loader, trust, U-Boot, kernel, DTB and modules.
Lesson: integrity responds “is it the expected file?”. Approval answers “does it work on this hardware?”. They are different questions.
fast tree
| Observed evidence | Initial layer | Next useful test |
|---|---|---|
| No power, LED or serial | Physical base and initial boot | Power, media and first bytes of boot |
| U-Boot appears, kernel does not start | Startup | Addresses, memory reserves, and pool artifacts |
| Kernel starts, system does not mount | Kernel and rootfs | Block device, modules and assembly |
| Interface opens, screen does not show | Profile, DRM and Dashboard | DRM master, connector, mode, polarities and visual test |
| Menu works, game crashes | Core, content or configuration | Session log, selected core and input file |
| Game opens with poor pacing | Performance | Real FPS, frametime, audio, temperature and active profile |
How to register a solution
A useful record contains: reproducible symptom, exact target, last proven layer, discarded hypothesis, minimal change, before and after result, and physical validation status. If the device still needs to be tested, write this explicitly. “Passed on host” should not become “fixed on hardware”.