Difference between revisions of "EHCI Gadget Debug"

From coreboot
Jump to navigation Jump to search
m (I had issues getting serial to work, but printk works fine.)
(various enhancements (IMHO ;))
Line 1: Line 1:
== Introduction ==
== Introduction ==
This page is about using embedded GNU/Linux devices in order to get the USB debug logs.
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 [[#Tested hardware|table]] below lists tested devices.


== Howto ==
== Howto ==
=== Patching ===
=== Patching ===
Download the [[:File:Ehci-debug-gadget-patches.tar.gz|patches]] that maintain TTY connected while debug target power-cycles or when host controller is reset.
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.


Apply the patches from one of the v3.8- or v3.10-debug-gadget directories on your kernel build tree.
Download and apply the [[:File:Ehci-debug-gadget-patches.tar.gz|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.


=== Compiling ===
=== Compiling ===
* You need to be familiar with (cross) compiling your kernel.
* You need to be familiar with (cross) compiling your kernel.
Be sure to set CONFIG_LOCALVERSION.
Be sure to set <tt>CONFIG_LOCALVERSION</tt> correctly if you want to only compile ''g_dbgp''.
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:
For a full build this does not matter.
For example, on Fedora the output of 'uname -r' is <tt>3.16.6-200.fc20.armv7hl</tt>, so to be able to load g_dbgp later on <tt>CONFIG_LOCALVERSION</tt> 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-
  uname -r | cut -d- -f 2-


Line 28: Line 34:
         EHCI Debug Device mode (serial)  --->
         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)
(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)


Then run
Then run
  make M=drivers/usb/gadget
  make M=drivers/usb/gadget
which will take about 2,5 minutes when running a native compile on the beagleboneblack. 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.
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.


=== Loading ===
=== Installation and loading ===
Remove all usb gadget drivers such as g_ether or g_mass_storage with rmmod or modprobe -r.
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
Then move the distribution's dir
  /lib/modules/$(uname -r)/kernel/drivers/usb/gadget/
  /lib/modules/$(uname -r)/kernel/drivers/usb/gadget/
Line 48: Line 56:
Finally, load g_dbgp:
Finally, load g_dbgp:
  modprobe g_dbgp
  modprobe g_dbgp
You should now have a new TTY at <tt>/dev/ttyGS0</tt> and some messages in <tt>dmesg</tt> (including some lines with <tt>setup: failure req 6 v 200</tt>).


=== Running ===
=== Running ===
I recommend to open the TTY before starting debug target. Doing it the other way
I recommend to open the TTY before starting debug target.
around slows down the debug target boot and seems to confuse serial gadget framework.
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:
You may want to disable some CR/LF translations on the device:
Line 58: Line 68:
You can directly open the device node, possibly redirecting to file:
You can directly open the device node, possibly redirecting to file:
  cat /dev/ttyGS0
  cat /dev/ttyGS0
.. or use a terminal client:
.. or use a terminal client (e.g. ''cu'', ''minicom'', ''microcom'' or ''picocom''):
  picocom -ir /dev/ttyGS0
 
* ''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 ===
=== Finding the USB debug port on the target ===
See [[EHCI Debug Port#Finding the USB debug port]]
See [[EHCI Debug Port#Finding the USB debug port]]


Line 67: Line 84:
{| class="wikitable"  border="1"
{| class="wikitable"  border="1"
! Brand and Device
! Brand and Device
! kernel used
! Kernel used
! Target devices
! Target devices
! works?
! works?
|-
! [http://beagleboard.org/black Beaglebone Black (rev. C from Farnell)]
| Vanilla 4.0-rc6 with some unrelated device tree patches
| ASRock IMB-A180-H
| {{yes}}
|-
|-
! [http://projects.goldelico.com/p/gta04-main/ Goldelico GTA04 A3]
! [http://projects.goldelico.com/p/gta04-main/ Goldelico GTA04 A3]

Revision as of 17:17, 6 April 2015