Mini-HOWTO for using the earlyprintk=dbgp boot option with a USB2 Debug port key and a debug cable, on x86 systems. You need two computers, the 'USB debug key' special gadget and and two USB cables, connected like this: [host/target] <-------> [USB debug key] <-------> [client/console] 1. There are a number of specific hardware requirements: a.) Host/target system needs to have USB debug port capability. You can check this capability by looking at a 'Debug port' bit in the lspci -vvv output: # lspci -vvv ... 00:1d.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #1 (rev 03) (prog-if 20 [EHCI]) Subsystem: Lenovo ThinkPad T61 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- /grub.cfg.) On systems with more than one EHCI debug controller you must specify the correct EHCI debug controller number. The ordering comes from the PCI bus enumeration of the EHCI controllers. The default with no number argument is "0" or the first EHCI debug controller. To use the second EHCI debug controller, you would use the command line: "earlyprintk=dbgp1" NOTE: normally earlyprintk console gets turned off once the regular console is alive - use "earlyprintk=dbgp,keep" to keep this channel open beyond early bootup. This can be useful for debugging crashes under Xorg, etc. b.) On the client/console system: You should enable the following kernel config option: CONFIG_USB_SERIAL_DEBUG=y On the next bootup with the modified kernel you should get a /dev/ttyUSBx device(s). Now this channel of kernel messages is ready to be used: start your favorite terminal emulator (minicom, etc.) and set it up to use /dev/ttyUSB0 - or use a raw 'cat /dev/ttyUSBx' to see the raw output. c.) On Nvidia Southbridge based systems: the kernel will try to probe and find out which port has a debug device connected. 3. Testing that it works fine: You can test the output by using earlyprintk=dbgp,keep and provoking kernel messages on the host/target system. You can provoke a harmless kernel message by for example doing: echo h > /proc/sysrq-trigger On the host/target system you should see this help line in "dmesg" output: SysRq : HELP : loglevel(0-9) reBoot Crashdump terminate-all-tasks(E) memory-full-oom-kill(F) kill-all-tasks(I) saK show-backtrace-all-active-cpus(L) show-memory-usage(M) nice-all-RT-tasks(N) powerOff show-registers(P) show-all-timers(Q) unRaw Sync show-task-states(T) Unmount show-blocked-tasks(W) dump-ftrace-buffer(Z) On the client/console system do: cat /dev/ttyUSB0 And you should see the help line above displayed shortly after you've provoked it on the host system. If it does not work then please ask about it on the linux-kernel@vger.kernel.org mailing list or contact the x86 maintainers.