Low Pin Count

Low Pin Count
Low Pin Count
Year created1998
Created byIntel
SupersedesIndustry Standard Architecture
Superseded byEnhanced Serial Peripheral Interface Bus (2016)
Width in bits4
Speed33 MHz
StyleParallel
Hotplugging interfaceno
External interfaceno
Low Pin Count interface Winbond chip
Trusted Platform Module installed on a motherboard, and using the LPC bus

The Low Pin Count (LPC) bus is a computer bus used on IBM-compatible personal computers to connect low-bandwidth devices to the CPU, such as the BIOS ROM (BIOS ROM was moved to the Serial Peripheral Interface (SPI) bus in 2006[1]), "legacy" I/O devices (integrated into Super I/O, Embedded Controller, CPLD, and/or IPMI chip), and Trusted Platform Module (TPM).[2] "Legacy" I/O devices usually include serial and parallel ports, PS/2 keyboard, PS/2 mouse, and floppy disk controller.

Most PC motherboards with an LPC bus have either a Platform Controller Hub (PCH) or a southbridge chip, which acts as the host and controls the LPC bus. All other devices connected to the physical wires of the LPC bus are peripherals.

Overview

[edit]
A diagram showing the LPC bus connecting the southbridge, the flash ROM, and the Super I/O chip

The LPC bus was introduced by Intel in 1998 as a software-compatible substitute for the Industry Standard Architecture (ISA) bus. It resembles ISA to software, although physically it is quite different. The ISA bus has a 16-bit data bus and a 24-bit address bus that can be used for both 16-bit I/O port addresses and 24-bit memory addresses; both run at speeds up to 8.33 MHz. The LPC bus uses a heavily multiplexed four-bit-wide bus operating at four times the clock speed (33.3 MHz) to transfer addresses and data with similar performance.

LPC's main advantage is that the basic bus requires only seven signals, greatly reducing the number of pins required on peripheral chips. An integrated circuit using LPC will need 30 to 72 fewer pins than its ISA equivalent. This also makes the bus easier to route on crowded modern motherboards. The clock rate was chosen to match that of PCI in order to further ease integration. Also, LPC is intended to be a motherboard-only bus; there is no standardized connector in common use, though Intel defines one for use for debug modules.[3] A small number of LPC peripheral daughterboards are available, with pinouts proprietary to the motherboard vendor: Trusted Platform Modules (TPMs),[2] POST cards for displaying BIOS diagnostic codes,[4] and ISA-compatible serial port peripherals for industrial use.[5] Device discovery is not supported; since only motherboard devices or specific models of TPM are connected, the host firmware (BIOS, UEFI) image will include a static description of any devices and their I/O addresses expected to be present on a particular motherboard.

Signals

[edit]

LPC control signals are active-low, as indicated by the "#" symbol in their names. Signals are divided into three categories:

  • Unidirectional. These are driven from a single source at all times.
  • Open-collector. These are low-speed signals which are pulled up (to the inactive state) by the host when not in use, and may be pulled down by any device.
  • Bidirectional. These high-speed signals are actively driven high for one cycle whenever a device is done using them, after which weak pull-up resistors hold them high until another device begins using them.

The LPC specification defines seven mandatory signals required for bidirectional data transfer:

  • LCLK (unidirectional, from host): 33.3 MHz clock. May be connected to the conventional PCI clock (PCICLK), thereby not requiring a dedicated pin on the host (south bridge). Like PCI, other signals are driven after the falling edge of LCLK, and received after the rising edge.
  • LRESET# (open-collector): Active-low bus reset. May be connected to PCIRST#.
  • LFRAME# (unidirectional, from host): This active-low signal indicates the beginning of an LPC bus transaction. Only the host may initiate bus transactions.
  • LAD[3:0] (bidirectional): These four bidirectional signals carry multiplexed address, data, and other information.

There are six additional signals defined, which are optional for LPC devices that do not require their functionality, but support for the first two is mandatory for the host:

  • LDRQ# (unidirectional, from device): DMA/bus master request. This is an output from a device that wants to perform direct memory access, either via the Intel 8237 compatible DMA controller, or the LPC-specific bus master protocol. The host must provide one corresponding input pin per device that needs it (minimum two).
  • SERIRQ (bidirectional): Serialized Intel 8259 compatible interrupt signal.[6] One line is shared by all LPC devices and the host. Like the LAD lines, this has a weak pull-up which will maintain it high if no device is driving it.
  • CLKRUN# (open-collector): Signal used to restart the clock in systems that can stop it for power management. Not required if the host does not stop the clock. May be connected to the equivalent PCI signal.
  • LPME# (open-collector): Power management event, to wake the system from a sleep state. Equivalent to the PCI bus PME# signal.
  • LSMI# (open-collector): System management interrupt request. This is only required if an LPC device needs to trigger an SMI# in response to a bus access (e.g. to perform software emulation of a missing hardware peripheral). Otherwise, the slower SERIRQ protocol can be used to request an SMI.
  • LPCPD# (unidirectional, from host): Optional output from the host to warn the LPC device that power is about to be removed and it should not make any interrupt or DMA requests.

Timing and performance

[edit]

The LPC bus derives its electrical conventions from those of conventional PCI. In particular, it shares the restriction that two idle cycles are required to "turn around" any bus signal so that a different device is "speaking". In the first, the bus is actively driven high. In the second, the bus is undriven and held high by the pull-up resistors. A new device may begin sending data over the bus on the third cycle. LPC operations spend a large fraction of their time performing such turn-arounds.

As mentioned, the LPC bus is designed to have performance similar to the ISA bus. The exact data transfer rates depend on the type of bus access (I/O, memory, DMA, firmware) performed and by the speed of the host and the LPC device. All bus cycles spend a majority of their time in overhead rather than data transfer—except the 16- and 128-byte firmware read cycles, which have 17 cycles of overhead but 32 and 256 cycles (respectively) of data transfer, achieving throughputs of 10.88 and 15.63 MB/s.[7] The next fastest bus cycle defined in the standard, the 32-bit ISA-style DMA write cycle, spends only 8 of 20 total clock cycles transferring data (the other 12 cycles are overhead), achieving up to 6.67 MB/s.[7]

One of the slowest bus cycles is a simple memory read or write, where only 2 of the 17 clock cycles (plus any wait states imposed by the device) transfer data, for a transfer rate of 1.96 MB/s.

Transaction structure

[edit]

LPC transactions begin on a low-to-high transition of LFRAME#. While LFRAME# is low, the host places a 4-bit START code on the LAD lines. The code sent on the last cycle before LFRAME# transitions high defines the following bus transaction.

Normally, the host only holds LFRAME# low for a single clock cycle, for efficiency. An exception is the abort transaction, which may begin even in the middle of another operation. The host pulls LFRAME# low for a minimum of four clock cycles, during which any devices must cease to drive the LAD bus. On the fourth cycle, the host drives LAD high (to 1111). Upon the high-to-low transition of LFRAME#, the bus is reset to an idle state.

In almost all other cases, LPC transactions use the following general structure:

  • START code
  • Transaction type and address from host
  • Data from host (if a write)
  • Bus turnaround (2 cycles)
  • SYNC from device (1 or more cycles)
  • Data from device (if a read)
  • Bus turnaround (2 cycles)

DMA transfers differ somewhat. § ISA-compatible DMA may have multiple SYNC and data phases. § Bus master DMA has a bus turnaround immediately following the START code and no final turnaround,

The SYNC phase allows the device to insert wait states in the transaction. There are six possible SYNC values, all with even parity (even Hamming weight). Three of them end the SYNC phase, while the other three cause the host to wait for another SYNC nibble:

  • 0000: Ready. The device is ready to proceed with the transaction. For DMA cycles, this also clears the DMA request (DREQ) signal.
  • 0011: (not used)
  • 0101: Short wait. Another SYNC cycle follows. At most 8 short wait cycles are permitted.
  • 0110: Long wait. Like short wait, but the wait may be long (e.g. Enhanced Parallel Port operations)
  • 1001: Ready more. A DMA-only code that signals "Ready" and the device requests additional DMA cycles (DREQ remains asserted).
  • 1010: Error. The device is ready to proceed, but there was some serious error (such as a parity error) with the transfer. This is equivalent to the ISA bus IOCHK# or PCI bus SERR# signals. In the case of a read, data follows but is likely to be corrupted.
  • 1100: (not used)
  • 1111: Device not present. If no device responds to the transaction, the host will see this code and can abort the transaction. To accommodate slow devices, up to 2 cycles of this code are permitted before the transaction is aborted.

Applications

[edit]

Intel designed the LPC bus so that the system BIOS image could be stored in a single flash memory chip directly connected to the LPC bus. Intel also made it possible to put operating system images and software applications on a single flash memory chip directly connected to the LPC bus, as an alternative to a Parallel ATA port.[8]

A CPLD or FPGA can implement an LPC host or peripheral.[9]

The original Xbox game console has an LPC debug port that can be used to force the Xbox to boot new code.[10][11]

ISA-compatible operation

[edit]

All ISA-compatible LPC bus transactions use START code of 0000.[7] During the first cycle with LFRAME# high again, the host drives a "cycle type/direction" (CTDIR) field: two bits indicating the type (I/O, memory, or DMA) and one bit indicating the direction (read from device, or write to device) of the transfer to follow. This is followed by the transfer address field, whose size depends on the type of cycle:

  • For I/O access, the address is 16 bits, transferred most-significant nibble first over 4 cycles.
  • For system memory access, the address is 32 bits, transferred most-significant nibble first over 8 cycles.
  • For ISA-compatible DMA accesses, there is no address per se, but a two clock cycles transfer a nibble containing the DMA channel number, and a second nibble giving the transfer size. The memory address is programmed into the ISA-style DMA controller in the chipset or the CPU outside of the LPC bus. See § ISA-compatible DMA below.

ISA-compatible reads and writes

[edit]

Memory and I/O accesses are allowed as single-byte accesses only, and operate as described in § Transactoin structure:: address, data from host if write, turnaround, SYNC, data from device if read.

If the host attempts a transfer to an unused address, no device will drive the SYNC cycles and the host will see 1111 on the LAD bus. After seeing three cycles of 1111 (two cycles are allowed, in addition to the two turn-around cycles, for a slow device to decode the address and begin driving SYNC patterns), the host will abort the operation.

ISA-compatible DMA

[edit]

The Platform Controller Hub (PCH) chip or the southbridge chip acts as the host and controls the LPC bus. It also acts as the central DMA controller for devices on that bus if the memory controller is in the chipset. In CPUs that contain their own memory controller(s), the DMA controller is located in the CPU. For compatibility with software originally written for systems with the ISA bus, the DMA controller contains the circuit equivalents of "legacy" onboard peripherals of the IBM PC/AT architecture, such as the two programmable interrupt controllers, the programmable interval timer, and two ISA DMA controllers, which are all involved in "ISA-style DMA".

ISA-compatible DMA uses an Intel 8237-compatible DMA controller on the host, which keeps track of the location and length of the memory buffer, as well as the direction of the transfer. The device simply requests service from a given DMA channel number, and the host performs a DMA access on the LPC bus.

The request is made by a virtual ISA-compatible DMA request (DRQ) line, which is emulated using the device's LDRQ# signal to indicate transitions on the emulated DRQ line. This is done with 6-bit requests on the LDRQ# signal: a 0 start bit, the 3-bit DMA channel number (most significant bit first), one bit of new request level (almost always 1, indicating that a DMA transfer is requested), and a final 1 stop bit. The host responds by performing a DMA cycle at the next available opportunity. DMA cycles are named based on the direction of memory access, so a "read" is a transfer to the LPC device, and a "write" is a transfer from the LPC device.

The "address" consists of 6 bits sent as two nibbles: a 3-bit channel number and 1-bit terminal count indication (the ISA bus's TC pin, or the 8237's EOP# output), followed by a 2-bit transfer size.

By default, DMA channels 0–3 perform 8-bit transfers, and channels 5–7 perform 16-bit transfers; but an LPC-specific extension allows 1-, 2-, or 4-byte transfers on any channel. When a multi-byte transfer is performed, each byte has its own SYNC field, as described below.

A normal SYNC "ready" pattern of 0000 (or an error pattern of 1010) also causes a deassertion of the corresponding emulated DMA request signal; the host will stop DMA after the immediately following byte until the device makes another DMA request via the LDRQ# signal. A SYNC pattern of 1001 indicates that the host should consider he device's DMA request still active; the host will continue with any remaining bytes in this transfer or start another transfer, as appropriate, without a separate request via LDRQ#.

For a DMA write, where data is transferred from the device, the SYNC field is followed by the 8 bits of data and another SYNC field, until the host-specified length for this transfer is reached, or the device stops the transfer. A two-cycle turnaround field completes the transaction. For a DMA read, where data is transferred to the device, the SYNC field is followed by a turnaround, and the data—turnaround—sync—turnaround sequence repeats for each byte transferred.

Serialized interrupts

[edit]

Interrupts are transmitted over a single shared SERIRQ line using the "serialized interrupts for PCI" protocol originally developed for the PCI bus.[6] The host periodically sends interrupt packets, within which each interrupt request is assigned a 1-clock time slot, separated by 2-clock turnaround cycles. The initial synchronization is done by the host. As a simplified example:

  • The host drives the SERIRQ line low for four to eight clocks, followed by a 2-clock turnaround cycle: SERIRQ is driven high for 1 clock, then floats high for the second turnaround clock.
  • If a device needs to request IRQ#6, it waits for 6×3=18 clocks, then drives SERIRQ low for one clock and high for another.

The devices can recognize the beginning of the frame because only the host will ever drive the line low for more than one cycle. The host identifies the interrupt by counting the number of clocks cycles: if it sees the SERIRQ line driven low at the eighteenth clock, then IRQ 18/3=6 is asserted.

The number of interrupt slots is system-specific, with 17 being a typical number: 16 ISA-compatible interrupts (IRQ0–IRQ15), plus NMI.

After the final interrupt slot, the host appends a "stop" signal consisting of two or three low cycles followed by two turnaround cycles.

In "continuous" mode, the host periodically initiates a new packet. There is also a "quiet" mode in which a device requests a new packet by driving SERIRQ low for one clock cycle. The host then continues driving the line low for the other seven clocks. From this point on, the protocol is the same.

The mode is controlled by the length of the host's stop signal at the end of each packet. If it consists of three clocks of low signal, continuous mode follows and only the host may begin a new packet. If the stop signal consists of two low clocks, quiet mode follows and any device may initiate an interrupt packet.

LPC non-ISA transactions

[edit]

START field values other than 0000 or 1111 are used to indicate various non-ISA-compatible transfers.[7] The supported transfers are:

START = 1101, 1110: Firmware memory read and write

[edit]

This allows the firmware (BIOS) to be located outside the usual peripheral address space. These transfers are similar to ISA-compatible transfers, except that:

  • There is no CTDIR field; the direction is encoded in the START field (1101 for read, 1110 for write).
  • The first 4 address bits are defined as a device select (IDSEL) field to allow the selection of one firmware hub out of many. For example, a second firmware hub can be used to hold a backup BIOS in case the primary BIOS is corrupted by malware or a bad flash.
  • The remaining 28 address bits define the address within the device, most significant nibble first.
  • The address is followed by a size field. Supported read/write sizes are 1, 2, and 4 bytes. Sizes of 16 and 128 bytes are supported for read only.
  • The data is transferred in one continuous burst, with no wait states. There is only one SYNC field for the whole transfer.

START = 0010, 0011: Bus master DMA

[edit]

Up to two devices on an LPC bus can request a bus master transfer by using the LDRQ# signal to request use of the reserved DMA channel 4. In this case, the host will begin a transfer with a special START field of 0010 for bus master 0 or 0011 for bus master 1, followed immediately by two turnaround cycles to hand the bus to the device requesting the bus master DMA cycle. Following the turnaround cycles, the transfer proceeds very much like a host-initiated ISA-compatible transfer with the roles reversed:

  • The device sends a one-cycle CTDIR field (only I/O and memory transfer types are permitted).
  • The device sends an address (16 or 32 bits, depending on the type). It is transferred most significant nibble first.
  • The device sends a one-cycle transfer size field, encoding 8, 16 or 32 bits.
  • In the case of a write, the data follows. Unlike ISA-compatible DMA cycles, the data is transferred in one burst, with no more wait states.
  • Then come two turn-around cycles while the LAD bus is handed back to the host.
  • A variable-length SYNC field is inserted, under control of the host.
  • In the case of a read, the data provided by the host follows.

This differs from 16-bit ISA bus mastering because LPC bus mastering requires a 32-bit memory address when performing a memory transfer, does not use an ISA-style DMA channel, and can support 8, 16, or 32-bit transfers; while 16-bit ISA bus mastering requires a 24-bit memory address when performing a memory transfer, requires the use of an ISA-style DMA channel, and cannot perform 32-bit transfers.[12]

START = 0101: TPM Locality access

[edit]

Trusted Platform Module 2.0 specifications define special TPM-Read cycles and TPM-Write cycles that are based on the I/O Read and the I/O Write cycles.[13] These cycles use a START field with the formerly-reserved value of 0101, followed by a CTDIR nibble and 16-bit I/O address just like an ISA-compatible write.[13] These cycles are used when using a TPM's locality facility.[13]

Supported peripherals

[edit]

The LPC bus specification limits what type of peripherals may be connected to it. It only allows devices that belong to the following classes of devices: super I/O devices, nonvolatile BIOS memory, firmware hubs, audio devices, and embedded controllers. Furthermore, each class is restricted on which bus cycles are allowed for each class.[7]

Super I/O devices and audio devices are allowed to accept I/O cycles, accept ISA-style third-party DMA cycles, and generate bus master cycles. Generic-application memory devices like nonvolatile BIOS memory and LPC flash devices are allowed to accept memory cycles. Firmware hubs are allowed to accept firmware memory cycles. Embedded controllers are allowed to accept I/O cycles and generate bus master cycles. Some ISA cycles that were deemed not useful to these classes were removed. They include host-initiated two-byte memory cycles and host-initiated two-byte I/O cycles. These removed transfer types could be initiated by the host on ISA buses but not on LPC buses. The host would have to simulate two-byte cycles by splitting them up into two one-byte cycles. The ISA bus has a similar concept because the original 8-bit ISA bus required 16-bit cycles to be split up. Therefore, the 16-bit ISA bus automatically split 16-bit cycles into 8-bit cycles for the benefit of 8-bit ISA peripherals unless the ISA device being targeted by a 16-bit memory or I/O cycle asserted a signal that told the bus that it could accept the requested 16-bit transfer without assistance from an ISA cycle splitter.[12] ISA-style bus mastering has been replaced in the LPC bus with a bus mastering protocol that does not rely on the ISA-style DMA controllers at all. This was done in order to remove ISA's limit on what type of bus master cycles a device is allowed to initiate on which DMA channel. The ISA-style bus cycles that were inherited by LPC from ISA are one-byte host-initiated I/O bus cycles, one-byte host-initiated memory cycles, and one- or two-byte host-initiated ISA-style DMA cycles.[7]

However, some non-ISA bus cycles were added. Cycles that were added to improve the performance of devices beside firmware hubs include LPC-style one-, two-, and four-byte bus master memory cycles; one-, two-, and four-byte bus master I/O cycles; and 32-bit third-party DMA which conforms to all of the restrictions of ISA-style third-party DMA except for the fact that it can do 32-bit transfers. Any device that is allowed to accept traditional ISA-style DMA is also allowed to use this 32-bit ISA-style DMA. The host could initiate 32-bit ISA-style DMA cycles, while peripherals could initiate bus master cycles. Firmware hubs consumed firmware cycles that were designed just for firmware hubs so that firmware addresses and normal memory-mapped I/O addresses could overlap without conflict. Firmware memory reads could read 1, 2, 4, 16, or 128 bytes at once. Firmware memory writes could write one, two or four bytes at once.[7]

See also

[edit]

References

[edit]
  1. ^ Kovah, Xeno; Kallenberg, Corey; LegbaCore LLC (15 October 2015). SPI Flash (PDF). Advanced x86: BIOS and system management mode internals. OpenSecurityTraining.info. p. 5.
  2. ^ a b Johannes Winter (2011). "A Hijacker's Guide to the LPC bus". tugraz.at. Retrieved 2013-12-19.
  3. ^ Installable LPC Debug Module Design Guide (PDF) (Specification). Revision 1.0. Intel. 2000. p. 15. Archived from the original (PDF) on 2017-06-04.
  4. ^ "BIOS POST Code Reader with the Raspberry Pi Pico". Retrieved 2024-09-11.
  5. ^ "Industrial motherboard peripherals: EXT-RS232". DFI. Retrieved 2024-09-11.
  6. ^ a b Serialized IRQ Support For PCI Systems (Revision 6.0; September 1, 1995)
  7. ^ a b c d e f g "Intel Low Pin Count (LPC) Interface Specification" (PDF). Revision 1.1. Intel. August 2002. Document number 251289-001. Archived (PDF) from the original on 2019-03-31. Retrieved 2024-09-11.
  8. ^ Dagan, Sharon (2002-05-03). "Flash Storage Alternatives for the Low-Pin-Count (LPC) Bus". EE Times.
  9. ^ "LPC Bus Controller. Reference Design RD1049". www.latticesemi.com. Lattice Semiconductor. Archived from the original (PDF) on 2013-08-07.
  10. ^ Huang, Andrew (2003). Hacking the Xbox: An Introduction to Reverse Engineering. No Starch Press. pp. 48, 151. ISBN 1-59327-029-1.
  11. ^ O. Theis. "Modding the XBox". section "Details of the LPC".
  12. ^ a b Intel Corp. (2003-04-25), "Chapter 12: ISA Bus" (PDF), PC Architecture for Technicians: Level 1, retrieved 2015-01-27
  13. ^ a b c "TCG PC Client Platform TPM Profile (PTP) Specification" (PDF). Trusted Computing Group. January 26, 2015. pp. 29, 123–124. Retrieved October 5, 2016..
[edit]