Debug Port Background
Legacy COM ports have become a prime source of confusion and frustration for PC users. Over the years, a huge array of devices has appeared that attach to the COM port. Each device uses the COM port and its various signals in proprietary ways that often have difficult timing requirements. This leads to interoperability problems that are confusing to the user.
Further, the COM port "bus" does not have a fully featured Plug and Play standard--making it difficult to detect when a device has been attached, removed, or swapped with another. This also leads to confusing scenarios that are difficult for the user solve.
For example, a user plugs a modem into the COM port. After making a call, that user unplugs the modem and plugs in a personal digital assistant. However, the operating system and modem application do not have any way of knowing that the modem is no longer attached, and therefore prevent the PDA synchronization software from running.
For all of these reasons, legacy-free machines do not include COM ports.
However, operating system vendors, device driver writers, and others still need some mechanism for running a kernel debugger. In order to prevent a continuation of COM port problems, it is undesirable to include a COM port in machines. This specification describes the options available to OEMs to provide the required debug port. These options reflect the assertion that implementation for a debug port must be cheap, easy to manufacture, and standard. Note that these options pertain to the Windows Millennium Edition (Windows Me) and Windows 2000 operating systems, and follow-on products.
General Requirements and Approach
Such a device has the following high-level requirements:
Simple design: cheap, easy to manufacture.
Simple standard software interface.
Uses a standard connector and pinout--to eliminate logistical problems of proprietary cables and so that any computer can debug any other computer. In some cases, this connector may use existing standards or may be a new standard.
Software interface requires only a very small overhead to run it. (This rules out SMI emulations.)
Portable: the solution can be used on x86-based, Intel Itanium-based, and future platforms.
Relatively high speed: 57600 baud or better.
In addition, for use in the field and for debugging crashes after the fact, it is highly desirable that a debug cable can be connected and used on the fly without requiring a reboot.
To meet the needs of upcoming product schedules for OEMs, both a long-term and short-term approach must be taken. Any register interface required (called the Debug Port register interface in this document) is discovered via the Debug Port Table in ACPI. The differences between the two approaches are in the external interface and in which component the debug port is implemented.
Of the solutions described in this document, the following are available for use as of January 2000 with legacy-free-capable Windows operating systems:
IEEE 1394 port (support under Windows 2000 yet to be announced).
Super I/O based, using rerouted, non-legacy addresses.
Low-pin count (LPC) based with a debugging dongle.
Long-term Approach
Over the long term, the approach is to support debugging using either an IEEE 1394 or USB port.
IEEE 1394 Port
Machines equipped with one or more standard OHCI-compliant IEEE 1394 controllers can utilize the standard IEEE 1394 ports for connecting a host machine with one or more targets (up to 62 on a single bus). The host controller can be on the motherboard or attached via PCI (including CardBus). Standard IEEE 1394 cables can be used for this purpose.
This approach is supported in the Windows Millennium Edition operating system and will be supported in future versions of the Windows 2000 operating system. Plans for support under the original version of Windows 2000 have not been announced.
USB
Work is currently underway within the USB organization to develop a USB debug solution utilizing the USB 2.0 host controller specification. This approach will require a special debug dongle between the host and the target machine.
Microsoft is committed to working on this solution. Support for this solution in particular releases of the Windows operating system will be announced after hardware is available for testing.
Short-term Approach
There are two different short-term approaches if the IEEE 1394 solution is not chosen. These options are provided so that they can be implemented as quickly as possible with existing components. There are two options available to manufacturers: Super I/O-based and LPC-based. Note that both of these options result in a DF9 connector replacement for the legacy COM port.
Super I/O-based
In machines where the Super I/O is still on the motherboard (but disabled via the BIOS) and the chip allows it, a COM port can be enabled and rerouted to non-legacy addresses (that is, addresses other than 03F8-03FF, 03E8-03EF, 02F8-02FF, and 02E8-02EF). The standard motherboard header is stuffed with the standard connector common on many motherboards today. This header is compatible with existing ribbon cable header-to-DB9 adapters. The external port is not stuffed.
The serial port connector used for the debug solution on a legacy-free PC must not be accessible to the end user. This can be ensured either by hiding the serial port connector or by providing a connection point for an internal expansion serial cable.
Although this is a quick and efficient solution for most desktops and servers, it is not well-suited for mobile platforms due to limited real estate to place the header, and the platform continues to carry the burden of the serial interface circuitry.
The Windows Me and Windows 2000 operating systems provide support for this solution. Future versions of Windows operating systems will also likely support this solution, although the expectation is that the Super I/O will disappear over time.
LPC-based
The low-pin count (LPC) bus can provide a connection for a debugging dongle. The basic design encompasses using a Super I/O and UART on the dongle with a DB9 port out to provide similar debugging capabilities to the serial port. Both Intel  and AMD provide such solutions to the industry.
The Windows Me and Windows 2000 operating systems provide support for this solution. Future versions of Windows operating systems will also likely support this solution, although the expectation is that this is a short-term solution due to the availability of the IEEE 1394 solution and, ultimately, a USB solution.
Software Implementation Requirements
Debug Port I/O range must be fixed. The location of these registers is described using the ACPI FADT table. (See "Debug Port Table" section later in this specification.)
Debug Port and I/O range must be reported as system resources in the ACPI BIOS.
Debug Port must also be claimed by the PNP0C02 devnode, so that its resources are not allocated to anything else and detection does not try to find it.
Physical Connection Requirements
The Debug Port connector must not be easily accessible to the end user, so that the end user does not accidentally connect any devices to this port. It should, however, be relatively easy to access by field support personnel (for example, behind a removable panel).
The Debug Port connector must be dedicated for use for system debugging (or as a management port).
Debug Port Table
If the Debug Port Table is not present, the operating system should revert to existing debugging devices. Systems indicate the address of the short-term debug port (this table is irrelevant for IEEE 1394 or USB debugging) by way of the Debug Port Table. This table is located in system memory with other ACPI tables. It must be referenced in the ACPI RSDT table.
The presence of the Debug Port Table indicates that the system includes a debug port. The contents contain information about the configuration of the debug port.
Note: This table has been submitted to the ACPI specification working group for inclusion in the next release of the ACPI specification. The table definition is reprinted here for reference.
Debug Port Table Format
Field
|
Byte Length
|
Byte Offset
|
Description
|
Header
|
|
|
|
Signature
|
4
|
0
|
DBGP. Signature for the Debug Port Table.
|
Length
|
4
|
4
|
Length, in bytes, of the entire Debug Port Table.
|
Revision
|
1
|
8
|
1
|
Checksum
|
1
|
9
|
Entire table must sum to zero.
|
OEMID
|
6
|
10
|
OEM ID
|
OEM Table ID
|
8
|
16
|
For the Debug Port Description Table, the table ID is the manufacturer model ID.
|
OEM Revision
|
4
|
24
|
OEM revision of Debug Port Description Table for supplied OEM Table ID.
|
Creator ID
|
4
|
28
|
Vendor ID of utility that created the table. For the DSDT, RSDT, SSDT, and PSDT tables, this is the ID for the ASL Compiler.
|
Creator Revision
|
4
|
32
|
Revision of utility that created the table. For the DSDT, RSDT, SSDT, and PSDT tables, this is the revision for the ASL Compiler.
|
InterfaceType
|
1
|
36
|
Indicates the type of the register interface:
0 = full 16550 interface
1 = 16550 subset interface compatible with Microsoft Debug Port Specification
2-255 = reserved.
|
Reserved
|
3
|
37
|
Must be 0.
|
BASE_ADDRESS
|
12
|
40
|
The base address of the Debug Port register set described using the Generic Register Address Structure
|
History
v.0.1 - 4/30/99 - First draft compiled from introductory meeting.
v.0.2 - 5/5/99 - Notes/changes compiled from e-mail review.
v.0.8 5/13/99 - Advanced version to indicate were closing. Removed CardBus example option; added requirement for 8 ports using UART registers.
v0.9 - 5/15/99 - Added UART register detailed requirements. Updated signal requirements (3 lines; compatibility); clarifications.
v0.91 - 5/15/99 - Minor edits.
v0.92 6/16/99 - Added discussion, general requirements, and clarifications.
v0.93 6/24/99 - Added debug port table.
v0.94 7/15/99 - Added long/short approaches; debug table changes; removed questions; integrated exclusions in other sections; added more detail.
V0.95 7/23/99 - Minor edits.
v1.00RC1 1/28/2000 - Incorporate new information for supported solutions.
v1.00RC2 2/2/2000 - Added requirement that user cannot access serial solution.
v1.00 2/9/2000 - Posted final.
v1.0c 8/10/15 – Updated patent notice
© 2015 Microsoft Corporation. All rights reserved.
|
Debug Port Background