EHCI Gadget Debug
The wiki is being retired!
Documentation is now handled by the same processes we use for code: Add something to the Documentation/ directory in the coreboot repo, and it will be rendered to https://doc.coreboot.org/. Contributions welcome!
This page is about using embedded GNU/Linux devices with support for the USB debug gadget kernel module (g_dbgp) to capture coreboot output with the help of a EHCI Debug Port. The table below lists tested devices.
The first fixes a bug and makes sure that the TTY remains operational after disconnects. It was upstreamed in fall 2014 and is included since version 3.18. The second one is a hack to make sure the connection/TTY remains in place even when the target power cycles or when host controller is reset.
Download and apply the patches on your kernel build tree as you see fit. There are only versions for 3.8 and 3.10 included but porting them to newer kernels should be easy.
- You need to be familiar with (cross) compiling your kernel.
Be sure to set CONFIG_LOCALVERSION correctly if you want to only compile g_dbgp. For a full build this does not matter. For example, on Fedora the output of 'uname -r' is 3.16.6-200.fc20.armv7hl, so to be able to load g_dbgp later on CONFIG_LOCALVERSION must be set to -200.fc20.armv7hl. You can extract this from a running system by using this shell command:
uname -r | cut -d- -f 2-
- (Cross) compile it as usual but during the configuration do the following:
Go into Device Drivers:
Device Drivers --->
Then go into USB support:
[*] USB support --->
Then go into USB Gadget Support:
<M> USB Gadget Support --->
Then enable the following option (CONFIG_USB_G_DBGP=m):
<M> EHCI Debug Device Gadget
Then select the serial option:
EHCI Debug Device mode (serial) --->
(The 'printk' option will also work and may be easier to debug, but 'serial' is more convenient for grabbing logs (it simply creates another virtual serial console at /dev/ttyGS0)
which will take about 2.5 minutes when running a native compile on the Beaglebone Black (BBB). As long as you use the distribution's kernel source code package there is no need to compile all the other modules and initramfs/uImage/uInitrd/vmlinuz. A full build takes about 3 hours on the BBB.
Installation and loading
Remove all usb gadget drivers such as g_ether or g_mass_storage with rmmod or modprobe -r if they are loaded. Then move the distribution's dir
Copy over the modules:
for f in $(find drivers/usb/gadget/ -name *.ko); do sudo cp $f /lib/modules/$(uname -r)/kernel/drivers/usb/gadget/ ; done
Finally, load g_dbgp:
You should now have a new TTY at /dev/ttyGS0 and some messages in dmesg (including some lines with setup: failure req 6 v 200).
I recommend to open the TTY before starting debug target. Doing it the other way around slows down the debug target boot and seems to confuse serial gadget framework.
You may want to disable some CR/LF translations on the device:
stty -icrnl -inlcr -F /dev/ttyGS0
You can directly open the device node, possibly redirecting to file:
.. or use a terminal client (e.g. cu, minicom, microcom or picocom):
- picocom supports translating CR/LF by itself but sometimes aborts to output too early.
picocom --imap lfcrlf -ir /dev/ttyGS0
Alternatively one can use microcom that correctly translates CR/LF automatically.
microcom -p /dev/ttyGS0
- By using script one can easily create log files, e.g.:
script -c "microcom -p /dev/ttyGS0" coreboot.log
Finding the USB debug port on the target
|Brand and Device||Kernel used||Target devices||works?|
|Beaglebone Black (rev. C from Farnell)||Vanilla 4.0-rc6 with some unrelated device tree patches||ASRock IMB-A180-H||Yes|
|Goldelico GTA04 A3||neil-plus kernel and branch (3.7)||Lenovo X60||Yes|
|Buglabs's bug 2.0||bug20-2.6.35-linaro's master (2.6.35)||Lenovo X60||Yes|
|Carambola 2 dev board (or any other AR9331 board where the location of the usb mode strap resistor is known)||OpenWRT git master (3.10.58) with chipidea ar9331 patch||ASUS F2A85M-LE||Yes|
|Cubietech Cubietruck||Mainline v4.2-4282-gae98207||Lenovo X60||Yes|