Troubleshooting KGDBoc Startup on Linux 3.2 Cortex-A8

The request path starts at the host GDB session, crosses the serial adapter and wiring, enters the target UART, passes through the active Linux TTY driver, and reaches the KGDB-over-console transport. Follow that path in order. In this case, the decisive break was before KGDB configuration or UART polling: the bootloader loaded a different kernel image from the one prepared for debugging.

What path must carry the GDB request?

KGDB cannot exchange packets until the target kernel has initialized the selected transport. For kgdboc=ttyO0,115200n8, the transport is the console-capable serial device named ttyO0. The host and target settings must agree, but matching serial settings cannot compensate for an incorrect kernel image or an inactive TTY driver.

The serial format in the attempted configuration is 115200n8: 115200 baud, no parity, and eight data bits. Flow control is not specified by that token. Read the target driver and host serial configuration rather than adding an assumed flow-control mode.

Does the physical serial path work in both directions?

Layer one first. Visible boot output proves that target transmit data reaches the host; it does not prove that bytes from the host reach the target UART. KGDB requires both directions. Check the target receive path with a monitor, bootloader input, or another receive test before treating a silent GDB session as a protocol fault.

The description calls the connection a “232 port” while also discussing a USB hub or converter. Do not infer the electrical interface from the connector or operating-system device name. Read the board schematic and adapter specification to determine whether level conversion is present. A signal-level mismatch can allow misleading partial behavior or damage hardware.

A USB-to-serial converter on the host side remains outside the target kernel. The host USB stack drives the converter, while the target still sees its hardware UART. The target therefore does not need USB polling callbacks merely because the host adapter plugs into USB. A target-side USB gadget console such as ttyGS0 is a different path: GDB packets would traverse the target USB gadget and serial-function stack instead of the hardware UART.

Did the kernel receive the intended command line?

Read the command line printed by the running kernel, not only the bootloader environment. The captured line contains kgdboc=ttyO0,115200n8 and kgdbwait, so those tokens reached the kernel. It also contains ekgdboc=ttyO0,115200n8 and the suspicious neighboring text ip=nonen8. Remove duplicate, experimental, and misspelled tokens while diagnosing so the printed command line has one unambiguous transport selection.

If either required token is absent or altered in the kernel log, correct the bootloader variable, quoting, spacing, and image-specific boot entry. If both are intact, continue to kernel identity. Repeatedly changing KGDB options at that point skips the stronger diagnostic.

Is the bootloader loading the kernel that was built?

Compare the complete Linux version banner with the build just produced. The first captured boot identifies Linux 3.2.18, compiler gcc 4.5.4 20120305 (prerelease), build host koen@dominion, build number #1, and timestamp Thu Jun 14 23:26:20 CEST 2012. That identity did not match the newly prepared debugging build.

A later boot identifies Linux 3.2.0, compiler 4.7.2 from Sourcery CodeBench Lite 2012.09-63, build host root@debian, build number #1, and timestamp Sun Jan 13 19:33:48 MSK 2013. These are different kernel artifacts, not two configurations of one running image.

If the release, build identity, timestamp, or other deliberately changed marker differs from the expected artifact, stop. Locate the image address, filename, storage partition, or boot entry actually selected by the bootloader. Replace that artifact and reboot. Configuration analysis of a file that did not produce the running kernel cannot explain runtime behavior.

Does the running build contain the required KGDB features?

After confirming image identity, inspect the configuration belonging to that exact image. The documented menu selections used here are Kernel hacking, Kernel debugging, KGDB: kernel debugger, and KGDB: use kgdb over the serial console. The UART polling code is guarded by CONFIG_CONSOLE_POLL, so that setting must also be active in the build that boots.

Built-in timing matters. kgdbwait acts during startup only after the KGDB core and selected transport initialize. If a required component is deferred until a loadable module becomes available, it cannot service an earlier boot-time stop. Check the link form in the kernel configuration rather than assuming that a selected menu item is built into the image.

The boot messages omap_hwmod: gfx: failed to hardreset, omap_hwmod: pruss: failed to hardreset, and hw-breakpoint: debug architecture 0x4 unsupported. identify other subsystems. They do not replace the missing KGDB transport message. Track them separately unless the boot fails before the serial driver and KGDB transport can initialize.

Does the active UART driver register polling operations?

The source shown for drivers/tty/serial/omap-serial.c implements serial_omap_poll_get_char and serial_omap_poll_put_char under CONFIG_CONSOLE_POLL. The receive function reads UART_LSR, returns NO_POLL_CHAR when UART_LSR_DR is clear, and otherwise reads UART_RX. The transmit function waits for the transmitter and writes through UART_TX.

Function definitions alone are not the whole check. The active UART driver's operations table must register callbacks through .poll_get_char and .poll_put_char, and the conditional code must be compiled. An example for another UART driver adds both functions under CONFIG_CONSOLE_POLL and assigns them in its UART operations table. Apply that structural check to the driver actually bound to the port.

The installation descriptions mention both the OMAP serial driver and a Serial: 8250/16550 driver. Resolve that ambiguity from the running kernel: inspect the boot registration, active console, device binding, and port identity. Checking polling functions in omap-serial.c proves nothing if ttyO0 is served by a different compiled driver, and checking the 8250/16550 implementation proves nothing if it is not bound to the selected port.

What procedure resolves and verifies the startup failure?

1. Connect a serial terminal at 115200n8 and confirm readable boot output.
2. Verify host-to-target traffic through the same adapter and wiring. Close any program that retains exclusive ownership of the host serial device.
3. Capture the running kernel command line. Reduce it to one intended kgdboc=ttyO0,115200n8 token plus kgdbwait while testing.
4. Capture the full Linux version banner and compare its release, compiler identity, build marker, and timestamp with the kernel just built.
5. If the identities differ, correct the bootloader's image filename, address, partition, or boot entry, then reboot. This was the resolving branch for the recorded failure.
6. For the confirmed image, check the four KGDB-related menu selections and CONFIG_CONSOLE_POLL. Confirm that the serial-console transport is built into the boot image.
7. Identify the driver actually bound to ttyO0. Verify that its compiled UART operations register .poll_get_char and .poll_put_char.
8. Reboot and watch for KGDB transport initialization followed by the waiting state requested by kgdbwait.
9. Release the terminal's ownership of the serial device, connect the host GDB session through that same device, and verify that the target leaves the waiting state under debugger control.

KGDB is a kernel service, so it cannot debug instructions that execute before enough of the kernel exists to initialize KGDB and its transport. A graphical GDB front end does not move that boundary to the first instruction of start_kernel(). Use an earlier-stage debugging method when execution must stop before KGDB initialization.

FAQ