Reading a TV boot log over UART
The boot log is the first thing a TV says when it powers on. Even without any commands, it tells you the chip family, the bootloader, whether the memory is readable and where the boot stops.
Part of the UART guide.
Before you capture
- Connect GND, adapter TX to board RX and adapter RX to board TX, as in connecting to a TV UART. Do not connect the adapter’s VCC.
- Use 3.3 V logic. Some boards use 1.8 V UNVERIFIED check the signal level with a multimeter or the SoC datasheet before connecting.
- Start with 115200 8N1; it is the most common. 57600, 38400 and 921600 also occur.
- Turn on logging to a file before powering the TV.
What you see, and what it means
| Terminal shows | Meaning |
|---|---|
| Readable text | Right speed and wiring |
| Random symbols | Wrong baud rate |
| Nothing | TX/RX swapped, no common ground, wrong level, or the wrong pad |
Stages of a typical log
- First-stage loader / ROM messages. Short lines about memory initialisation. If the log ends here, suspect RAM or the supply.
- Bootloader banner. U-Boot, LK, or MBoot on MStar-based boards, with a version and date, and the board name.
- Storage detection. Lines about the eMMC or SPI flash: size, bus width, errors. Repeated read errors or “no device” point to the storage or its contacts.
- Autoboot prompt. Text such as “Hit any key to stop autoboot” or “Press Enter” with a short window of one to three seconds.
- Kernel start. The kernel command line and the partition list, then init and the Android or Linux services.
- Panic or reboot loop. A kernel panic, a watchdog reset, or the same lines repeating are the symptom you came for.
What to note
- The last line before the log stops or restarts.
- Any word like error, fail, timeout, CRC or bad.
- Storage size and partition names, to compare with a dump (see comparing dumps).
- The prompt text of the bootloader, which tells you how to enter its console.
Interrupting autoboot gives you a console with powerful commands. Stay with read-only commands until you know the board. Writing to the storage from the console without a verified dump can destroy the only copy of the data. Closed boards with secure boot may not allow interruption at all.
Typical mistakes
- Judging by a log captured at the wrong speed.
- Starting capture after power-on, so the first stage is missing.
- Reading only the screen and not saving the log.
- Sending keys at random. Use the method for the bootloader family.
How this is done in FW Tool
- The UART tab has port and speed selection and bootloader profiles, including Realtek, MediaTek and MStar presets with short cheat sheets.
- Every session is written to a time-stamped log file; the log can be saved from the program.
- “Interrupt boot” sends keys repeatedly (space, Enter, Ctrl+C, Esc, or “stop”) for the first seconds; you press it and power on at once. An automatic mode tries all the keys in turn.
- “Recon” runs read-only commands (version, bdinfo, printenv, help, mmc list, mmc part, usb start, plus Linux or Android queries) and saves a report you can use to build a profile for the board.
- “Check eMMC wear” reads the eMMC life registers and shows an estimate of wear and reserve blocks. See features.
FAQ
The log is garbage only in the first line. Why?
The first stage may use a different speed from the later stages, or the line is shortened by the adapter. If the rest is readable, ignore it.
The boot cannot be interrupted.
The window may be too short, the key wrong for this loader, or the loader locked. Read the banner and try the other method.
Can the log tell me which firmware to flash?
It gives the board name and versions. Compare these with the strings in the package (package structure).
Comparing logs
A log from a working TV of the same model is the best reference. Place the two logs side by side: the point where they diverge is the first place to investigate. Pay attention to the order of messages rather than exact numbers, because timestamps and memory addresses differ from boot to boot.
Save every log with the date and the symptom in the file name. After a few repairs you will recognise the typical endings of a failed boot: a storage that is not found, a kernel that does not start, or a loop of resets. This habit also gives you material for the repair record, which helps when the customer returns with the same complaint.
Lastly, do not be discouraged by a silent port. Many boards expose several UART pads, and only one of them is the console of the main SoC; others belong to the standby microcontroller or the Wi-Fi module. Try each candidate pad at the common speeds before concluding that the board gives no console, and record the result in your notes for the next time.