Serial ports have been the primary means of early debugging of new LinuxBIOS ports. New hardware doesn't always have a serial port and another method for early debugging is needed.

+

[[Image:PLX_NET20DC.jpg|thumb|right|Ajays NET20DC USB Debug Device.]]

−

The '''EHCI Debug Port''' is an optional capability of EHCI controllers. All USB2 host controllers are EHCI controllers. The debug port provides a mode of operation that requires neither RAM nor a full USB stack. A handful of registers in the EHCI controller PCI configuration and BAR address space are used for all communication. All three transfer types are supported (OUT/SETUP/IN) but transfers can only be a maximum of 8 bytes and only one specific physical USB port can be used. A Debug Class compliant device is the only supported USB function that can be communicated with.

+

Serial ports have been the primary means of early debugging of new coreboot ports. New hardware doesn't always have a serial port and another method for early debugging is needed.

−

== Debug Class Device ==

+

The '''EHCI Debug Port''' is an optional capability of EHCI controllers which can be used for that purpose.

−

While the Debug Class functional spec describes a device communicating over USB also with the debugging host (aka remote) it would be very possible to make a Debug Class device with a regular serial port on the other end. One thing to watch out for is that such a device might not be able to handle the same throughput as the debug port itself and hence may lose data unless it can do some buffering.

−

== Considerations in LinuxBIOS ==

+

All USB2 host controllers are EHCI controllers. The debug port provides a mode of operation that requires neither RAM nor a full USB stack. A handful of registers in the EHCI controller PCI configuration and BAR address space are used for all communication. All three transfer types are supported (OUT/SETUP/IN) but transfers can only be a maximum of 8 bytes and only one specific physical USB port can be used. A Debug Class compliant device is the only supported USB function that can be communicated with.

−

We'll use Mode 1 since a full USB stack and EHCI driver isn't running when we're using the debug port. We get early two-way communication from PCI memory write accesses. printf() should transmit also to the debug port on any (all?) EHCI controllers sporting the capability. Linux already supports this and we could probably copy code or headers from the kernel.

+

+

While the '''Debug Class''' functional spec describes a device communicating over USB also with the debugging host (aka remote) it would be very possible to make a Debug Class device with a regular serial port on the other end. One thing to watch out for is that such a device might not be able to handle the same throughput as the debug port itself and hence may lose data unless it can do some buffering.

+

+

== Supported chipsets ==

+

+

The following southbridges have USB debug support in coreboot:

+

+

{| border="0" style="font-size: smaller" valign="top"

+

|- bgcolor="#6699dd"

+

! align="left" | Vendor

+

! align="left" | Southbridge

+

! align="left" | Status

+

! align="left" | Comments

+

+

|- bgcolor="#eeeeee" valign="top"

+

| AMD

+

| SB600

+

| style="background:lime" | OK

+

| Tested by [[User:Uwe|Uwe Hermann]].

+

|- bgcolor="#eeeeee" valign="top"

+

| AMD

+

| SB700

+

| style="background:orange" | WIP

+

| Probably won't work, a patch is being prepared.

+

+

|- bgcolor="#dddddd" valign="top"

+

| Intel

+

| 82801GX (ICH7)

+

| style="background:lime" | OK

+

| Tested by [[User:SvenS|Sven Schnelle]] on Lenovo Thinkpad X60/T60.

+

|

+

+

|- bgcolor="#eeeeee" valign="top"

+

| NVIDIA

+

| MCP55

+

| style="background:lime" | OK

+

| Tested by [[User:Uwe|Uwe Hermann]]. Any physical USB port will work, as the code tries all ports until the one with the attached USB Debug device is found.

+

+

|- bgcolor="#dddddd" valign="top"

+

| SiS

+

| SiS966

+

| style="background:yellow" | Untested

+

| '''Note:''' It's unclear if the chipset actually has EHCI Debug Port functionality, and (if yes), whether the current coreboot code supports it properly (or whether it's just copy-pasted code from another chipset).

On your "host PC" you need a Linux system which is recent enough to provide the '''usb_debug''' kernel module. When you attach the Ajays Net20DC device to your host PC, it will create a '''/dev/ttyUSB0''' device to which you can connect as usual using any serial terminal program, e.g. '''minicom''' (115200, 8n1).

+

+

TODO: Is the Baud rate actually configurable somewhere?

+

+

You must connect the NET20DC to a special USB port on your coreboot target board (not all of the USB ports will work!), often this is USB port 1. If in doubt, try all available ports to check which one works on your board.

+

+

Then you can power up your coreboot target board and you should see the usual coreboot bootlog in minicom on your host PC.

+

+

=== usb_debug_io.c ===

+

+

As an alternative, you can also use [http://tracker.coreboot.org/trac/coreboot/ticket/57 this small libusb-based user-space program] on the host PC to retrieve the coreboot logs.

+

+

== Finding the USB debug port ==

+

+

Generally, each EHCI controller can offer at most one debug port. That port corresponds to a fixed physical USB port. Locating that physical port is rather difficult because you need to look at lots of information.

+

+

Carl-Daniel Hailfinger has written [http://coreboot.org/pipermail/coreboot/2008-September/038635.html a script] which can help finding that port.

== Hardware capability ==

== Hardware capability ==

+

The Debug Port is optional, please check if EHCI controllers near you support it:

The Debug Port is optional, please check if EHCI controllers near you support it:

Look for a line like the last one above. Please include the PCI device ID too:

−

# lspci -ns $(lspci|grep EHCI|cut -f1 -d' ')

+

$ '''for i in $(lspci|grep EHCI|cut -f1 -d' ') ; do

+

$ ''' lspci -ns $i'''

+

$ '''done'''

00:1d.7 0c03: 8086:265c (rev 03)

00:1d.7 0c03: 8086:265c (rev 03)

−

If your controller isn't already listed below then please add it or send an email to the [[Mailinglist]] if you don't have a wiki account yet and want one, or want us to add your controller to the page.

+

If your controller isn't already listed below then please add it or send an email to the [[Mailinglist|mailing list]] if you don't have a wiki account yet and want one, or want us to add your controller to the page.

Revision as of 20:42, 23 September 2012

Serial ports have been the primary means of early debugging of new coreboot ports. New hardware doesn't always have a serial port and another method for early debugging is needed.

The EHCI Debug Port is an optional capability of EHCI controllers which can be used for that purpose.

All USB2 host controllers are EHCI controllers. The debug port provides a mode of operation that requires neither RAM nor a full USB stack. A handful of registers in the EHCI controller PCI configuration and BAR address space are used for all communication. All three transfer types are supported (OUT/SETUP/IN) but transfers can only be a maximum of 8 bytes and only one specific physical USB port can be used. A Debug Class compliant device is the only supported USB function that can be communicated with.

While the Debug Class functional spec describes a device communicating over USB also with the debugging host (aka remote) it would be very possible to make a Debug Class device with a regular serial port on the other end. One thing to watch out for is that such a device might not be able to handle the same throughput as the debug port itself and hence may lose data unless it can do some buffering.

Using the EHCI debug port

usb_debug kernel module and minicom

On your "host PC" you need a Linux system which is recent enough to provide the usb_debug kernel module. When you attach the Ajays Net20DC device to your host PC, it will create a /dev/ttyUSB0 device to which you can connect as usual using any serial terminal program, e.g. minicom (115200, 8n1).

TODO: Is the Baud rate actually configurable somewhere?

You must connect the NET20DC to a special USB port on your coreboot target board (not all of the USB ports will work!), often this is USB port 1. If in doubt, try all available ports to check which one works on your board.

Then you can power up your coreboot target board and you should see the usual coreboot bootlog in minicom on your host PC.

usb_debug_io.c

Finding the USB debug port

Generally, each EHCI controller can offer at most one debug port. That port corresponds to a fixed physical USB port. Locating that physical port is rather difficult because you need to look at lots of information.

Carl-Daniel Hailfinger has written a script which can help finding that port.

Hardware capability

The Debug Port is optional, please check if EHCI controllers near you support it: