Please note as of Wednesday, August 15th, 2018 this wiki has been set to read only. If you are a TI Employee and require Edit ability please contact x0211426 from the company directory.

TI811X PSP User Guide

From Texas Instruments Wiki
Jump to: navigation, search
TI811X PSP User Guide
Linux PSP

About this Manual

This document describes how to install and work with Texas Instruments' Platform Support Package (PSP) for the TI811x platform. This PSP provides a fundamental software platform for development, deployment and execution on TI811x platform. It abstracts the functionality provided by the hardware. The product forms the basis for all application development on this platform.

Software Overview

To begin developing applications, you need to install Linux PSP package.

Package Contents

The values of MM, mm, pp and bb in this illustration will vary across the releases and actually depends on individual component versions

For TI811x PSP we use 04.07 for the version string

Extract the contents of release package on your Linux host with the following command:

 $ tar -xvzf

This creates a directory with the following contents:

|-- docs
|   |--
|   |--
|   |-- TI811X_PSP_Adding_External_Decoders_to_V4L2_Capture_Driver.pdf
|   |-- TI811X_PSP_AUDIO_Driver_User_Guide.pdf
|   |-- TI811X_PSP_DCAN_Driver_User_Guide.pdf
|   |-- TI811X_PSP_EDMA_Driver_User_Guide.pdf
|   |-- TI811X_PSP_ETHERNET_Switch_User_Guide.pdf
|   |-- TI811X_PSP_Flashing_Tools_Guide.pdf
|   |-- TI811X_PSP_GPIO_Driver_User_Guide.pdf
|   |-- TI811X_PSP_HDMI_Sii9022a_Transmitter_Driver_User_Guide.pdf
|   |-- TI811X_PSP_IOMMU_Driver_User_Guide.pdf
|   |-- TI811X_PSP_McSPI_Driver_User_Guide.pdf
|   |-- TI811X_PSP_MMC_SD_Driver_User_Guide.pdf
|   |-- TI811X_PSP_NAND_Driver_User_Guide.pdf
|   |-- TI811X_PSP_NOR_Driver_User_Guide.pdf
|   |-- TI811X_PSP_PM_CLOCK_FRAMEWORK_User_Guide.pdf
|   |-- TI811X_PSP_USB_Driver_User_Guide.pdf
|   |-- TI811X_PSP_User_Guide.pdf
|   |-- TI811X_PSP_VIDEO_CAPTURE_Driver_User_Guide.pdf
|   |-- TI811X_PSP_VPSS_VIDEO_Driver_User_Guide.pdf
|   `-- TI811X_PSP_WDT_Driver_User_Guide.pdf
|-- host-tools
|   |--
|   |-- nand-flash-writer.out
|   |-- norflash-writer.out
|   |-- spi-flash-writer.out
|   |-- src
|   |   |--
|   |   |--
|   |   |--
|   |   `--
|   |-- switch-config
|   `-- TI811X.gel
|-- images
|   |-- kernel
|   |   `-- uImage
|   `-- u-boot
|       |-- nand
|       |   |-- u-boot.bin
|       |   `-- u-boot.min.nand
|       `-- sd
|           |-- MLO
|           `-- u-boot.bin
|-- src
|   |-- examples
|   |   `-- examples.tar.gz
|   |-- kernel
|   |   |--
|   |   |--
|   |   |--
|   |   |--
|   |   |-- Readme.txt
|   |   |-- ShortLog
|   |   `--
|   `-- u-boot
|       |--
|       |--
|       |-- Readme.txt
|       |-- ShortLog
|       |--
|       |--
|       `--
`-- TI81XXPSP_Software_Manifest.doc

Few points to note about the above structure:

Assuming the release package is extracted inside directory represented as $TI811X-PSP-DIR:

  • U-Boot source tarball is needs to be extracted on Linux build host. This will create U-Boot source base for TI811X
$ cd $TI811X-PSP-DIR/
$ tar -xvzf
  • Similarly kernel source tarball from directory needs to be extracted to have kernel source directory setup for building kernel and/or modules
$ cd $TI811X-PSP-DIR/
$ tar -xvzf
  • Various Video and Audio example sources are included inside $TI811X-PSP-DIR/examples/examples.tar.gz
  • Additionally, Watchdog timer and PCIe Endpoint boot applications are provided in respective directories inside $TI811X-PSP-DIR/examples


To build U-Boot and the Linux kernel, you will need to download and install CodeSourcery ARM tool chain version 2009-q1. For additional documentation on installing the CodeSourcery tools, please visit

To help you get started quickly the PSP package comes with pre-built binaries. However, after making any changes to U-Boot and Linux Kernel you need to cross-compile them using the CodeSourcery toolchain and use the new binaries that are generated

In this context, the document contains instructions to:

  • Install the release
  • Build the sources contained in the release

The document also provides detailed description of drivers and modules specific to this platform - as implemented in the PSP.



Before you begin with the installation of the package please make sure you have met the following system requirements:

  • Windows machine
  • Host machine running a version of Linux such as Ubuntu.
  • TI811x EVM baseboard

The Windows machine is used for running CCSv4/v5, which will be used to build flash writers and also to burn the boot images (U-Boot) onto the flash using the flash writers provided.

The Linux host is used for the following:

  • Re-compiling U-Boot and the Linux kernel.
  • Hosting the NFS server to boot the EVM with NFS as root filesystem

You can use either the Windows machine or the Linux host for

  • Hosting the TFTP server required for downloading kernel and file system images from U-Boot using Ethernet.
  • Running a serial console terminal application

Environment Setup

After you have installed the Cross-compilation toolchain you need to setup the environment in the Linux host.

For example, if you are using the Codesourcery 2009-q1 version of the toolchain for cross-compilation

  1. Set the environment variable PATH to contain the binaries of the CodeSourcery cross-compiler tool-chain.
    For example, in bash shell:
    $ export PATH=/opt/toolchain/2009-q1/bin:$PATH
  2. Add the location of U-Boot tools directory to the PATH environment variable (required for mkimage utility that is built as part of U-Boot build process and is needed to generate uImage when building the kernel)
    For example, in bash:
    $ export PATH=/opt/u-boot/tools:$PATH

Actual commands to be used for setting the environment variables will depend upon your shell and location of the tools


Please refer to U-Boot User Guide for details about U-Boot.

Linux Kernel

This chapter describes the steps required to build and configure the Linux kernel. It also provides basic steps to boot kernel on the EVM.

Compiling Linux Kernel

Change to the base of the Linux source directory.

Choose default kernel configuration for your platform.

$ make CROSS_COMPILE=arm-arago-linux-gnueabi- ARCH=arm ti811x_evm_defconfig

Initiate the build.

$ make CROSS_COMPILE=arm-arago-linux-gnueabi- ARCH=arm uImage

For the kernel image (uImage) to be built, mkimage utility must be included in the path. mkimage utility is generated (under tools folder of U-Boot) while building the U-Boot binary.

On successful completion, file uImage will be created in the directory ./arch/arm/boot.

Copy this file to the root directory of your TFTP server.

Modifying Kernel Configuration

This section describes the steps to configure the kernel for TI811x EVM and illustrates related configuration items for reference.

Start with the default configuration for your platform

$ make CROSS_COMPILE=arm-arago-linux-gnueabi- ARCH=arm ti811x_evm_defconfig

To view configuration interactively:

$ make CROSS_COMPILE=arm-arago-linux-gnueabi- ARCH=arm menuconfig

From the onscreen menu, select System Type and press ENTER:

   General setup  --->
[*] Enable loadable module support  --->
-*- Enable the block layer  --->
System Type  --->
Bus support  --->
Kernel Features  --->

Select ARM system type

ARM system type (TI OMAP)  --->   
TI OMAP Common Features  --->
TI OMAP2/3/4 Specific Features  ---> 

You will be presented with various ARM based SoCs. Select OMAP as


After pressing ENTER, you will be presented earlier menu. Select "TI OMAP2/3/4 Specific Features" and press ENTER. Select various options as shown below (marked with '[*]') by pressing Y on each item after selecting it.

[*] Typical OMAP configuration 
[ ] TI OMAP2
[ ] TI OMAP3
[ ] TI OMAP4
[*] TI 81XX
[ ] TI816X support
[*] TI814X support
*** TI81XX Board Type ***
[*] TI811X Evaluation Module

Note that the "TI814X support" option will be shown only if you enable "TI 81XX". Similarly, "TI811X Evaluation Module" option will be presented only after selecting "TI814X support"

Choose Exit successively to return to previous menu(s) and eventually back to the shell. Make sure to save the changes you have made when prompted at exit.

Some of the key drivers which may be enabled in the default configuration are:

  • Audio (AIC3016 codec)
  • Ethernet Switch
  • I2C
  • MMC/SD
  • NAND
  • Serial port
  • SPI flash
  • USB Host support
  • WDT

If you are looking for some particular functionality please double-check that it is enabled in the config options.

Auto detection of Kernel Load Address and Runtime RAM Base Determination

By default, the DM81xx kernel is built to be loaded at physical address 0x80008000 in RAM and take start of RAM as 0x80000000.

It is possible to load the kernel at a different location in RAM with kernel automatically determining RAM base depending upon the load address.

This is achieved by the combination of two features added the kernel:

  1. Run time PHYS_OFFSET determination: This feature enables determining physical to virtual translations dynamically depending upon the position of kernel in system memory.
  2. Auto calculation of address for uncompressed kernel: This feature enables the compressed kernel entry code (part of kernel zImage) to determine the address to uncompress the kernel depending upon the location it is loaded (started from).

Subsequent sub-sections assume that you have already downloaded and extracted the kernel snapshot from above mentioned link/page or set up git working directory with latest PSP kernel from repository associated with the above page. It is also assumed that the environment for kernel build is setup and 'mkimage' executable utility from U-Boot is available in the PATH (this utility gets built with U-Boot and available inside 'tools' directory form U-Boot source base).

Configuring the Kernel

Note: The run time physical offset support is treated as EXPERIMENTAL feature currently. The default kernel configurations for DM8168 EVM have this feature enabled in latest source. You can follow steps similar to those described below and build the kernel to enable this support for any custom board as well as to view/disable this feature as per the need.

Generate default config for the Board

BUILDHOST$ make ARCH=arm ti811x_evm_defconfig

The above steps should configure the kernel to include run time physical to virtual translation support (CONFIG_ARM_PATCH_PHYS_VIRT=y) and auto detection of load address (CONFIG_AUTO_ZRELADDR=y).

If you desire to view the exact configuration options to be controlled to enable or disable these features, read the next steps.

Enter the configuration menu

BUILDHOST$ make ARCH=arm menuconfig

You will be presented with configuration menu as shown below:

[*] Patch physical to virtual translations at run time (EXPERIMENTAL)
General setup  --->
[*] Enable loadable module support  --->
Kernel Features  --->
Boot options  --->

Enable/Disable runtime physical to virtual translation feature
Ensure that the "Patch physical to virtual translations..." option is highlighted and press 'n' key (without quotes) to disable it (the default kernel configuration done in the earlier step had enabled this option).

[ ] Patch physical to virtual translations at runtime (EXPERIMENTAL)
General setup  --->
[*] Enable loadable module support  --->

Pressing 'y' on this option will (again) enable it.

Enable/Disable auto calculation of decompressed kernel location
Now navigate to "Boot options --->" option by using DOWN arrow key and press SPACE to enter the sub-menu shown below.

Here, using DOWN ARROW key, navigate to the option "Auto calculation..." and press 'y' to enable or 'n' to disable it. You should see a '*' in the box '[ ]' in front of that option when 'y' is pressed (enable) otherwise the box will be empty (disabled) when 'n' is pressed.

(0) Compressed ROM boot loader base address
(0) Compressed ROM boot loader BSS address
()  Default kernel command string
[ ] Kernel Execute-In-Place from ROM
[ ] Kexec system call (EXPERIMENTAL)
[*] Auto calculation of the decompressed kernel image address

Using RIGHT arrow key, highlight the 'Exit' option on the menu page and press ENTER key subsequently till you are asked to save the configuration. Now ensure that 'Yes' is highlighted and press ENTER again to save and exit the configuration.

Building the Kernel

Use following command to build the kernel:

BUILDHOST$ make ARCH=arm zImage

Notice that we are building the standard zImage (compressed kernel image) instead of usual uImage. This is so because the uImage built as part of kernel build will have the load address and entry point @0x80008000 by default while, in this case we desire to load the kernel at different load address. Hence we build a zImage and then pass the desired address to 'mkimage' to get uImage as shown below.

Here we use 0x90008000 as the kernel load address and entry point.

Note: You can chose any other address as per your requirement and available RAM space but please refer next section Points to Note/Restrictions for various important points and constraints.

Use 'mkimage' to generate uImage. Note that the command is run from the kernel source base after zImage is built successfully.

BUILDHOST$ mkimage -A arm -O linux -T kernel -C none -a 0x90008000 -e 0x90008000 -n 'Linux-2.6.37' -d arch/arm/boot/zImage uImage
    Image Name:   Linux-2.6.37
    Created:      Mon Oct 29 21:05:21 2011
    Image Type:   ARM Linux Kernel Image (uncompressed)
    Data Size:    2570504 Bytes = 2510.26 kB = 2.45 MB
    Load Address: 90008000
    Entry Point:  90008000

You can build the zImage once and just execute the 'mkimage' step for different load address requirements with same kernel.

Alternate Method: Single Step Build

You can still achieve the above in single step as part of kernel build by passing zreladdr-y=<desired-load-address> to make when building the uImage.

For example, to build the uImage with load address 0x90008000 considered in earlier case:

BUILDHOST$ make ARCH=arm zreladdr-y=0x90008000 uImage

The above command will build the kernel zImage and then uImage by internally invoking 'mkimage' with the specified load address (passed as zreladdr-y).

Note: In any case, you need to rebuild the uImage for specific load address.

Points to Note/Restrictions
  • Load address and entry point parameter passed to 'mkimage' must be same, that is, values passed for '-a' and '-e' must be same.
  • The auto address calculation of load address is only possible when using compressed kernel image (zImage) and thus, the uImage must be built from zImage - using uncompressed kernel image (Image) will not support this feature.
  • The run time physical RAM base calculation support (called as p2v) adds a string "p2v8" to module version and thus the modules built without p2v support cannot be loaded on the kernel built with p2v support enabled and vice verse. This prevents incompatible modules being loaded mistakenly.
  • This feature may not be used with XIP kernels.
  • Run time physical offset determination feature is an EXPERIMENTAL feature presently.
  • The kernel compressed entry code which determines the address for loading uncompressed kernel considers that the compressed kernel image (zImage) is loaded within first 128MB of the RAM, this also means that the RAM base is determined by masking least significant (LS) 27 bits of the load address.
  • There must be at least 32KiB space available *after* the determined RAM base (see above point) and *before* the kernel load address specified when preparing uImage.

Refer Choosing Load Address and Determination of RAM Base section below for details and examples.

Choosing Load Address and Determination of RAM Base

As mentioned earlier, the load address must be chosen such that it leaves at least 32KiB space below it from the RAM base. This is required since the kernel uses this region of RAM below the image to store page tables (in normal execution as well as during decompress).

Also note that since the RAM base is calculated by truncating to the nearest 128MiB boundary (masking LS 27 bits of the load address), the LS bits getting masked need to evaluate to at least 32K offset from the RAM base (that is, 0x8000 minimum).

  • Following are some examples of correct load addresses (with automatically calculated RAM base) followed by a few incorrect ones:

Correct Load Addresses
Load Address Calculated RAM Base

  • Following addresses would result into a non bootable kernel (kernel will hang/halt during boot):

Incorrect Load Addresses
Load Address Problem Area
Calculated RAM base = 0x90000000 (masking to 0xF8000000), which means the 32KiB requirement for load address is not met
RAM base = 0x98000000, 32KiB requirement not met
RAM base = 0x98000000, only 16KiB available below the load address

Modifying Pin Mux settings

On TI811X devices, the pins are tri-stated and set to Mode 0 or any other mode as required for specific module (e.g., MMC) in U-Boot. If you desire to use a particular pin to any other function than Mode 0 or override any other pin mode which was already set in U-Boot, the kernel needs to be modified and rebuilt.

You can change default mux mode by adding specific mux entry in the beginning of board_mux array in arch/arm/mach-omap2/board-ti811xevm.c or calling omap_mux_init_signal() during initialization (e.g., in device specific initialization function called from omap2_init_devices() in arch/arm/mach-omap2/devices.c).

The names of multiplexed signals are specified in arch/arm/mach-omap2/mux814x.c file in kernel source directory.

e.g., for setting xref_clk0 pin (mode 0) to usb1_drvvbus (mode 7 or FUNCTION 8), add


to board_mux structure in board file or call

omap_mux_init_signal("xref_clk0.usb1_drvvbus", 0)

The string passed above should be mode0_name.desired_mode_name format.

Note: On TI811x devices,

  • some pins do not have mode0, in such case, the mode0 name for corresponding pin of DM814x is retained and suffixed with "_ti811x" to be accessible in the mode0.mode format.
  • some pins have some extra modes/functions added to existing modes on dm814x or replaced with new functions in such cases the pin mode0 name is suffixed with "_ti811x" to differentiate from the existing pin.

Refer arch/arm/mach-omap2/mux814x.c file for specific details.

e.g, omap_mux_init_signal("mmc1_dat0_ti811x.gpio4_12", 0);

The API approach is useful if you desire to set the pin-mux run time depending upon the board/hardware detected without need of maintaining separate kernel binaries.

Note: On TI811X device, the bit positions for pull up/down are different and hence use macros TI814X_PULL_DIS (to disable pull up/down) or TI814X_PULL_UP to select pull up.

Alternatively, you can set particular pins by passing respective pinmux details to kernel command line in following format


E.g., to set mmc1_cmd_mux0 (mode 0) pin to gpio0_0 and enable pull down, append following to kernel command line passed from the boot loader:


For pull up (set bit 17):


You can pass configuration for multiple pins separated by comma.

For details about this boot parameter, refer Documentation/kernel-parameters.txt in kernel source directory.

Updating the DHCP Script

The latest kernel has changed the entry for root filesystem name as appear in /proc/mounts file. This might impact boot process if some of the init scripts in your filesystem read this entry to determine the root device type.

The existing scripts checking /proc/mounts may not work as intended.

One such case is the /etc/udhcpc.d/50default script in the filesystem, which skips sending DHCP requests if the root device is a network mounted filesystem.

If you face any issue where the filesystem is mounted successfully but hangs after showing udhcpc related prints. The issue is most likely with incompatibility between latest kernel and the udhcpc script.

To fix this, open the /etc/udhcpc.d/50default in your DM81xx filesystem and check if a check like the one shown below exists:

 root_is_nfs() {
       grep -qe '^/dev/root.*\(nfs\|smbfs\|ncp\|coda\) .*' /proc/mounts

Update the above fragment by replacing the check as below:

 root_is_nfs() {
       grep -qe 'nfs\|smbfs\|ncp\|coda.*' /proc/mounts

The above change will be required even when you want to (manually) run 'udhcpc' client after booting.

Power Management

Clock details

H/W Details

TI811X has two on chip oscillators which are the main source of clock, OSC0 - 20 MHz and OSC1(20-30MHz)and has 8 PLLs, by default OSC0(20 MHz) provides the input clock source for all PLLs.These PLLs are configured to generate higher frequencies required for interface and functional clocks of various modules on the device.Clock out from PLLs is distributed to various modules as per the hardware connections and requirements, with divider at place where lower frequencies are required.

Clock Framework Overview and Usage

For clock framework software implementation, features and usage refer to Clock Framework User Guide

List of available clocks

For list of available clocks,

  • Refer to ti814x_clks[] in arch/arm/mach-omap2/clock814x_data.c. All the clocks with the flag CK_TI811X are available on this platform.
  • Refer to "Feature performance guide" for list of clocks and their default rate/usecount.
  • Run the clock browser script available here Browse clocks

GPIO Driver

TI811Xx has two additional GPIO banks as compared to TI814X, total six GPIO Banks, each provides 32 dedicated general-purpose pins with input and output capabilities, total 0 - 191 pins are available for usage.

Configuring Interrupts for GPIO4 and 5 Banks

GPIO banks 0-3 have dedicated interrupt lines but GPIO 4 and 5 banks do not. Using Interrupt Crossbar muxes GPIO 4/5 can be configured to use any of the 8-127 interrupt lines to generate an interrupt to A8. In this release Interrupts 92-95 (timer 4-7) have been chosen for GPIO4 and 5, this overrides the default functionality of these interrupt lines as timer interrupts to serve the GPIO4 and 5 interrupts. This is only to illustrate how to configure the multiplexers to get interrupts. The interrupts to be overridden must be chosen carefully based on use case/application requirements and current system configuration(peripherals in use).

The interrupt crossbar configuration is done in arch/arm/mach-omap2/board-ti811xevm.c in ti811x_interrupt_xbar_config() function. The default value of the mux TI811X_A8_INT_MUX_95_92 is 0x0 which corresponds to timer interrupts, we override this by writing 0x1F1E1D1C to configure the interrupts for GPIO-4 and 5. For more details on Interrupt/event Crossbar, A8_INT_MUXes and interrupt numbers please refer to the Technical reference manual and Datasheet for TI811X.

DCAN Driver

DCAN driver features and usage details can be found in DCAN Driver Guide

EDMA3 Driver

Information related to features and usage can be found in EDMA Driver User Guide

Audio Driver

The audio driver in the PSP package conforms to the ASoC framework in the Linux kernel. The current driver supports audio capture and playback using the AIC3106 codec on the EVM. For more details on the audio driver refer to Audio User Guide

USB Driver

The USB subsystem includes two USB(mentor) controller. There are independent usb ports for two controller musb0 and musb1 can be configured to host/device mode operation.

USB_ID configuration The value USBx_ID pin decides the role of host or device mode. Before loading the kernel image, make sure USBx_ID pin is grounded for host mode operation and open for device mode operation.

Please refer TI811X PSP USB Drive User Guide for more details.

Ethernet Switch Driver

Ethernet Switch driver follows standard Linux Network Interface Architecture.

Please refer to Ethernet Switch User Guide for more details

VPSS Video Driver

VPSS Video Driver User Guide

VPSS Video Capture driver

Capture is not supported by default. For capture to work TVP5158 Decoder driver should be added to driver stack. For adding Decoder to V4l2 Linux stack refer TI811X_PSP_Adding_External_Decoders_to_V4L2_Capture_Driver.pdf in release package

Information related to driver features and usage can be found in VPSS Video Capture Driver User Guide

Note: TVP5158 is multi channel decoder(Present in JAMR2 daughter card) but V4L2 Framework supports only single channel. Only one channel capture is supported even if TVP5158 driver is added

Sii9022a External HDMI Transmitter Driver

Information related to features supported by the driver and usage can be found in Sii9022a external HDMI Transmitter UserGuide

McSPI Driver

Information related to features supported by the driver and usage can be found in McSPI Driver Guide

NOR Flash Support

Information related to features supported by the driver and usage can be found in NOR Driver User Guide

SD driver

SD Driver supports SD/SDHC/uSD cards. HSMMC peripheral (and driver) has support for 4 data lines at the max operating frequency of 48MHz. HSMMC is a slave DMA peripheral and uses EDMA to move data between SD card and system memory.

Supported Features

  • SD
  • SDHC
  • uSD
  • uSDHC

Not supported Features

  • PIO mode of operation

Detailed usage information can be found in MMC/SD guide

NAND driver

Information related to features supported by the driver and usage can be found in NAND guide

PCI Express Root Complex Driver

Please refer the PCIe RC Driver User Guide online.

PCI Express Endpoint Boot Driver

Please refer the PCIe Boot Driver User Guide online for details about booting TI811X PCIe Endpoint connected to TI811X or x86 Linux PCIe Root complex using PCIe boot driver (running on RC).

PCI Express Endpoint Driver

Please refer the PCIe Endpoint Driver User Guide online for details about using this driver on TI811X PCIe Endpoint part of PCIe topology.

Watchdog Timer (WDT)

Information related to features supported by the driver and usage can be found in WDT guide

Real Time Clock (RTC)

Please refer the Kernel RTC documentation [| RTC Doc]


TILER driver has dependency on Multimedia. TILER support is disabled in defconfig. TILER driver can be enabled from,

  Device Drivers  ---> 
    <*> Multimedia support  ---> 
        <*>   TI TILER support  ---> 
                --- TI TILER support                                  
                (128) Allocation granularity (2^n) (NEW)              
                (4096) Allocation alignment (2^n) (NEW)               
                (40)  Memory limit to cache free pages in MBytes (NEW)
                (1)   Process security (NEW)                          
                (0)   Use SSPtr for id (NEW)                          
                [ ]   Secure TILER build (NEW)                        
                [*]   Expose SSPtr to userspace (NEW)                 

Leave the default values as those are the one's which were validated for this release.

Following features are supported in the current TILER driver,

  • Single PAT and run-time memory allocation

Features not supported,

  • Dual PAT
  • PAT bypass mode


For features and usage information please refer to IOMMU Driver Guide.