DaVinci PSP 03.02 Linux Installation User Guide

Document License

This work is licensed under the Creative Commons Attribution-Share Alike 3.0 United States License. To view a copy of this license, visit http://creativecommons.org/licenses/by-sa/3.0/us/ or send a letter to Creative Commons, 171 Second Street, Suite 300, San Francisco, California, 94105, USA.

DaVinci PSP Overview

This is the installation guide for DaVinci PSP 3.02 - open source community based PSP release. DaVinci PSP 3.02 release supports DaVinci DM6467 and DM6467T SoC and the EVM. The PSP release includes following components:

• DaVinci Linux Kernel version 2.6.31-rc7 with the support for DM6467 and DM6467T device (baseport and device drivers)
• Arago filesystem version 2009.05. More information on Arago file system available at the Arago website
• Secondary bootloader - U-Boot 2009.08-rc0 with the support for DM6467 device
• Primary bootloader - User Boot Loader (UBL) for NAND boot mode
• Serial flash utilities and CCS based NAND Writer utilities
• The Pre-built binaries for Kernel, Filesystem and U-Boot are compiled using CodeSourcery GNU Toolchain for ARM Processors: 2007q3-51 version
• The Pre-built binaries for UBL and NAND Writer utilities are compiled using Code Composer Studio (CCS) 3.3.38 installed on Windows XP with Service Pack 2
• The Pre-built binary for Serial flash utility is compiled using CodeSourcery GNU Toolchain and Mono Framwork

Downloading the Release

Please refer to the DaVinci PSP 3.02 Beta Release at DaVinci PSP 03.02 Beta Release Notes

System Requirements

Building and running all of the PSP components requires both a Windows XP and a Linux machine.

The Windows XP (with Service Pack 2) machine is required for running CCS 3.3.38. CCS is required for building the UBL and NAND Writer utilities. NAND Writer should be executed in CCS environment to program UBL and U-Boot binaries on to the NAND device on the EVM.

Linux host is required for compiling U-Boot, Linux kernel and filesystem in the Arago Build environment. Linux host can also be used to host the TFTP server (for downloading images) and NFS server (for the root filesystem).

DaVinci PSP 3.02 Installation on DM6467 and DM6467T EVM

Flashing DM6467 and DM6467T EVM using NAND Writer utilities (CCS environment)

For flashing the DaVinci DM6467 and DM6467T EVM using NAND Writer utilities, refer to the instructions provided here. The pre-built binaries for NAND Writer, UBL and U-Boot can be downloaded from the link specified in the release notes.

Flashing DM6467 and DM6467T EVM using Serial flash utilities

For flashing the DaVinci DM6467 and DM6467T EVM using Serial Flash utilities, refer to the instructions provided here. The pre-built binaries for Serial Flash, UBL and U-Boot can be downloaded from the link specified in the release notes.

Migration to DaVinci PSP 3.02

This section provides details on the migration path for customers using Montavista Professional Edition 5.0 based LSP releases (LSP 2.00 is the latest supporting DaVinci DM6467 device).

Montavista Pro 5.0 based LSP 2.00 release used the kernel version 2.6.18. DaVinci PSP 3.02 is the first step to get closer to the Open Source Kernel version (kernel.org). DaVinci PSP 3.02 release uses 2.6.31-rc5 Kernel.

There are generic changes in the core part of the kernel in 2.6.31-rc5, compared to 2.6.18. The baseport (architecture) for DaVinci SoC's have been re-arranged after reviewing the architecture with ARM sub-system maintainers. Other changes are mainly in the sub-system specific core code (e.g. V4L2, USB, MMC/SD, ALSA/Sound). For e.g. V4L2 sub-system introduced the framework called sub-device model to be used as an interface between Capture driver and the decoder drivers. Details on the DaVinci specific device drivers are given below.

Baseport SoC, EVM support

DaVinci PSP 3.02 release re-arranged the DaVinci architecture (arch/arm/mach-davinci) to clearly separate SoC specific and EVM/Board specific details, with the goal to re-use the common drivers across multiple SoCs. The baseport has a better pinmux, interrupt and EDMA event mux capabilities and better clock structures. The kernel also brings in stricter adherence to clock framework and modules for which there are no requests to enable the clocks will be kept disabled. So, modules like HDVICP which were being left enabled in MontaVista based kernels will not be enabled in this kernel. The header files have also been re-arranged and moved to arch/arm/mach-davinci/include/mach folder (used to be in include/asm-arm/arch-davinci folder).

Setting up U-Boot Environment for DM6467 EVM

By default U-Boot assumes 33MHz reference clock so the binary can be directly used on DM6467T EVM. While on existing DM6467 EVMs, an environment variable 'clkref' needs to be set as these boards have different clock input. Thus, on existing DM6467 EVMs clkref should be set to 27MHz by using following command sequence:

 setenv clkref 27000000
 saveenv
 reset 

Note that the 'reset' is required to ensure that U-Boot uses new clock reference value (saved to persistent storage using 'saveenv').

Note: clkref value setting is required to display correct ARM and DSP frequency. This will not affect any performance except showing wrong ARM and DSP frequencies in u-boot.

Setting up U-Boot Environment for DM6467T EVM

By default U-Boot assumes 33MHz reference clock so the binary can be directly used on DM6467T EVM.

EDMA

DaVinci PSP 3.02 release re-designed the EDMA driver (set of kernel APIs for use by other device drivers) by cleaning up unused structures and APIs and also renaming almost all APIs.

• davinci_request_dma changed to edma_alloc_channel. The new API does not require dev_name, channel and tcc to be passed. The allocated channel number is returned back to the caller. TCC and PaRAM allocation is handled by other APIs.
• davinci_set_dma_src_params changed to edma_set_src; davinci_set_dma_sest_params changed to edma_set_dest
• davinci_set_dma_src_index changed to edma_set_src_index; davinci_set_dma_dest_index changed to edma_set_dest_index
• davinci_set_dma_transfer_params changed to edma_set_transfer_params
• davinci_get_dma_params has been changed to edma_read_slot. davinci_set_dma_params has been changed to edma_write_slot. The argument should be "struct edmacc_param" (changed from struct paramentry_descriptor). TCC can be set using edma_write_slot and setting the TCC in the edma_param structure. Currently one-to-one mapping (of TCC to the channel) is allowed in the EDMA in the driver.
• davinci_start_dma changed to edma_start; davinci_stop_dma changed to edma_stop
• davinci_dma_link_lch changed to edma_link
• New APIs added to allocate/free PaRAM entries - edma_alloc_slot and edma_free_slot. If PaRAM allocation API is not called the driver assumes one-to-one mapping of PaRAM slots
• For davinci_free_dma, the new EDMA driver expects to call edma_clean_channel, edma_free_slot and then edma_free_channel

GPIO

GPIO driver has been rewritten to use the GPIO core infrastructure from the kernel. However there are no major changes to the APIs (back-end communication with the interrupts are handled with GPIO core).

• Need to call gpio_request() to start using a GPIO (this was not required earlier, we could directly call gpio_direction_xxx and gpio_write APIs)
• Provision to pass falling edge or rising edge information with the request_irq API. The IORESOURCE_IRQ_LOWEDGE and/or IORESOURCE_IRQ_HIGHEDGE can be passed for the "flags" argument.

Video drivers

Video capture

The video capture driver supports capture from TVP5146 and TVP7002. The vpif capture driver (aka vpif capture) is ported based on the v4l2 sub device framework. So both TVP514x (to support TVP5146) and TVP7002 drivers are ported to this framework. The bridge device - sub device bus parameters such as interface type, hd, vd polarity etc are defined in the board specific file for respective evms (example, board-dm6467-evm.c) and allows for easy customization. For vpif capture driver, the platform data structure defines the vpif configuration for the bridge driver as well sub devices and is used by the bridge driver to set the same in the bridge and sub devices (through platform_data).

The vpif capture supports both MMAP and USERPTR IO. For high resolution frame buffer usage (beyond NTSC/PAL resolution) USERPTR (Both mmap-ed user address and virtual address pointers supported) IO is recommended since MMAP buffer allocation fails due to fragmentation.

Video display

The Video Port Interface (VPIF) module is used to receive and transmit video data on DM6467. VPIF module has to input channels to receive video data and two output channels to output video data. Both input and output channels have same architecture. This write up focuses on the Output Channels

The VPIF Output Interface consists of following interfaces

- 2 channels of SD output in BT656 format

- 1 Channel of HD output in REC1120 format

DM6467T uses following video encoders for different kinds of displays

- ADV7343 for SD, ED and HD display on Composite, S-Video and Component outputs

- THS8200 for SD, ED and HD display on Component output.

Note: 1, Only one of the video encoder can be available at any point of time.

2, Support for ED and some HD modes are yet to be added for both THS8200 and ADV7343 drivers.

The vpif display driver (aka vpif display) is ported based on the v4l2 sub device framework. So both ADV7343 and THS8200 drivers are ported to this framework. The bridge device - sub device bus parameters such as interface type, hd, vd polarity etc are defined in the board specific file for respective evms (example, board-dm6467-evm.c) and allows for easy customization. For vpif display driver, the platform data structure defines the vpif configuration for the bridge driver as well sub devices and is used by the bridge driver to set the same in the bridge and sub devices (through platform_data).

Change in Video display connector between DM6467 EVM and DM6467T EVM

Placement of J11 (Y) has changed between DM6467 EVM and DM6467T EVM (Revisions A and B).

On DM6467 EVM, order is J10,J11,J12 and in DM6467T, order is J10,J12,J11.

Change in Video capture between DM6467T EVM Rev C and earlier revisions

If you are using DM6467T revisions A and B, the Linux kernel configuration should set CONFIG_VIDEO_THS7353_LUMA_CHANNEL to 3.

If you are using DM6467T revisions C and above, the Linux kernel configuration should set CONFIG_VIDEO_THS7353_LUMA_CHANNEL to 2.

Change from LSP 2.00

1. For both DM6467T and DM6467 EVM, clock source for display is derived from on board PLL supported through CDCE949.

2. THS8200 encoder support is added that supports 1080p60 display

3. ADV7343 will be supported through daughter card interface in DM6467T boards

Features	LSP	GIT
Pixel Format	Supports V4L2_PIX_FMT_YUV422UVP pixel format	Supports V4L2_PIX_FMT_NV16 pixel format
Standard Selection	Output is selected using /sys/class/davinci_display/ch0/mode sysfs entry	Standard is selected using VIDIOC_S_STD and VIDIOC_G_STD ioctls
Control Configuration	Controls are configured using /sys/class/davinci_display/ch0/brightness sysfs entry	There is no support for configuring controls
Sliced VBI services	Closed Caption, CGMS and WSS sliced VBI services are supported using VIDIOC_S_FMT ioctls	Sliced VBI services are not supported
Device specific parameters	Encoder and VPIF specific parameters are configured using VPIF_CMD_S_ENCODER_PARAMS/ VIDIOC_S_VPIF_PARAMS ioctls	Device specific parameters are not supported
Boot time parameters	Supported boot time parameters are default output, default mode, number of buffers and buffer size.	Only number of buffers and buffer size as boot time parameters are supported
Memory Allocation	Memory will be allocated using __get_free_pages Linux Kernel API	Memory is allocated using dma_alloc_coherent Linux Kernel API. This is because driver is using videobuf-config layer for the buffer management. Also there is not boottime allocation of memory. Memory will be allocated when application call VIDIOC_REQBUFS ioctl and them mmap system call.

VDCE

Video Data Conversion Engine module in DM6467 processes Video data. This module has several capabilities that not only includes pure video data processing, but also functions that are required for the video codec. VDCE module is capable of DownScaling, Edge Padding, Chroma Conversion, Bitmap Blending and Range mapping. VDCE driver supports above features through a character driver interface.

Change from LSP 2.00

Application interface header file of the VDCE driver was moved from include/asm/arch folder to arch/arm/mach-davinci/include/mach folder.

PCI Host Driver

PCI Host Driver gives a standard Linux interface for interfacing slave devices over PCI bus. PCI Driver has been validated against ethernet interface and DM6467 EVM.

PCI Host Driver Known Issues

Issues preceded with [HW] are h/w specific known issues/limitations.

• Currently PCI Host doesn't advertise 66MHZ Capability on DM4667T even though the device supports 66MHz PCI operation.

Note: This should not impact 66MHz operation since the hardware would still work at 66MHz on 66MHz PCI Bus. Only the advertised capability will be wrong.

• Linux (with PCI Host support included) hangs on DM6467 EVM (both 1GHz and 594MHz) on reset from CCS. Boots fine across power cycles. This issue is particularly observed when booting kernel with PCI Host support on a standalone EVM.

Workaround: Power cycle the EVM (i.e., PCI Backplane in case connected to PCI setup) and reconnect CCS and boot the board.

• DM6467/T EVMs switch to PCI mode by default and thus won't boot (from NAND) as EMIFA is disabled and needs CCS to carry out booting the DM6467/T PCI Host.

• DM6467/T PCI Host on default EVMs cannot receive PCI interrupts from targets connected over the bus (INTA to INTD).

Workaround: Connect INTA-D lines from PCI targets directly to available GPIO interrupt pins on DM6467/T PCI Host and add interrupt hooking code in DM6467/T PCI Host controller driver as applicable. In this case, ensure that GPIO bank 0 interrupt, pin direction (in) and trigger (rising edge), pin muxing (e.g., disable AUDCLK0 if using GPIO3) is configured in board specific file before any PCI target driver supposed to use GPIO interrupts is loaded. Refer DM6467_PCI_Host_Interrupts.

• PCI_RST is not generated over the PCI bus when DM6467/T PCI Host is reset without power cycling the backplane (e.g., typing 'reboot' from Linux on PCI Host or reset using CCS).

Workaround: 1) Disconnect and connect the expansion cable connected to backplane and Power cycle OR 2) Use h/w workaround and program CPLD as described @ Pinmux_Switching_from_NAND_to_PCI

PCI Boot

Please refer here for Host side sample application for PCI boot mode. This sample application demonstrates booting of DM6467 over PCI. This sample application can be compiled and run from a DM6467 EVM that acts as PCI Host.

The primary purpose of the PCI-Boot driver is to boot custom binaries on DM6467 device, over the PCI interface. The current release package demonstrates the use case scenario of booting Linux on DM6467 device over the PCI interface. The PCI boot driver provides the memory map functionality to allow zero copy of binary images on DM6467 memory. The driver also provides five IOCTL capabilities to the user application. These IOCTL calls are explained below.

1. DM646X_PCI_RUN_TCM_IMG - This IOCTL is invoked to indicate to the RBL that the UBL/TCM program image has been copied to the TCM memory. This is achieved by specifying the start address of UBL/TCM program and setting of the BC flag. This IOCTL transfers the control to UBL/TCM program.

2. DM646X_PCI_BOOT_IMAGE – This IOCTL is invoked to specify the start address of the U-Boot or secondary boot-loader to the UBL. This is achieved by writing the start address to the last location of TCM memory and setting of the BC flag. This IOCTL transfers the control to the secondary boot-loader like U-Boot or any custom image.

3. DM646X_PCI_REMAP_BAR – This IOCTL allows the remapping of BAR registers to any alternative memory locations on DM6467. This operation is transparent to the memory mapping on the Host machine. Thus no remapping is required to be done on the Host application.

This IOCTL allows copying of large sized binary images to DDR2 memory by remapping of BAR and partial image copying to consecutive BAR mapped regions.

4. DM646X_PCI_GEN_INTRPT – This IOCTL is invoked to generate a software interrupt on the DM6467 device. The current implementation raises this interrupt using software interrupt line 0.

5. DM646X_PCI_EDMA_XFER – This IOCTL provides a convenient approach to use the DM6467 EDMA support to transfer data between the Host machine and the DM6467 device. The IOCTL provides a flag to indicate the direction of transfer.

1.5. Operation Sequence The sequence of events followed to achieve the booting is explained below in detail.

1. Firstly, it is required for the host driver to map the DM6467 internal memory onto the PCI shared bus. To do this it must configure the DM6467 as a PCI device and read the BAR regions exposed by the DM6467 device to gain access on the host side to the memory regions of the DM6467.

2. Once this is achieved, the host application copies the UBL onto the DM6467 TCM. The host driver transfers the control to the start point of the UBL binary and waits for the boot complete flag to be reset by the DM6467 device.

3. The UBL then initializes the DM6467 hardware and initializes the DDR2 RAM for access over the PCI interface. The UBL resets the boot complete flag in the system registers to indicate to the host that the DDR2 initialization has been completed and can now be accessed over the PCI interface. Once it has done this, the UBL once again waits for the boot complete flag to be set by the host machine. The host is expected to set the BC bit as an indication of the copy of U-boot being made available in the specified location.

4. The host machine continues the boot process by copying four images on the shared DDR2 memory using memory mapping (zero copy). The Linux built image, the initrd ram-disk image and the boot-script image containing the kernel parameters are copied on into different locations on the shared memory. Once these three images are copied, it completes the activity by copying the U-boot image on another location and setting the boot complete flag. As soon as the UBL detects the BC flag being set, it jumps the control to the start of U-boot boot loader.

5. The U-boot boot loader now boots as usual from the DDR2 memory. The U-boot is built specifically for PCI booting such that its auto-booting command directly reads boot-script image to locate the Linux image and the RAM-disk images in DDR2 and boots the Linux. The boot-script image also provides the kernel arguments to U-Boot providing information about the file system.

The following table provides a sample memory configuration of locations used for UBL, U-boot image, RAM-disk image, boot-script and the Linux built image.

|Image || Location || Limit (Length) |- |UBL ||TCM || 0x8000 (32KB) |- |U-Boot || 0x81080000 to 0x81FFFFFF || |- |Boot-Script Image ||0x82080000 to 0x820FFFFF || |- |Linux Image || 0x82100000 to 0x827FFFFF|| |- |RAM-Disk Image || 0x82800000 || As required -|

U-Boot known issues with PCI Boot

• U-Boot gives following warning when running on EVM (unmodified) put in

PCI slot:

*** Warning - bad CRC, using default environment

This is expected, since NAND is not accessible in this case as on board CPLD switches MUX to PCI and U-Boot can't read environment stored in NAND.

Workaround: Load U-Boot script @0x82080000 with commands to be executed on each boot.

• U-Boot displays incorrect frequencies for ARM and DDR on 1GHz EVM. This

is obvious as U-Boot doesn;t have persistent stoarage for 'clkref' value as always default (27MHz) is assumed for calculations.

• Sometimes it was observed that U-Boot would fail to read Ethernet MAC

Address from EEPROM and show error like "EEPROM @ 0x50 read FAILED!!!". Subsequent network commands (such as 'dhcp') print error "*** ERROR: `ethaddr' not set" and ethernet doesn't work.

Workaround: Set MAC address manually. For example: setenv ethaddr 00:0e:99:02:52:03

Other option is to try after hard-resetting the board.

CIR Driver

There are three UART instances in Davinci-HD: UART0, UART1, and UART2 which have UART modem, IrDA, and CIR functionalities. UART2 is designated as the CIR module on Davinci-HD EVM. This module supports consumer infrared (CIR) communications. The CIR logic is to transmit and receive data packets according to the user-definable frame structure and packet content. CIR functions include consumer Infrared remote control mode with programmable data encoding. In consumer infrared mode, the infrared operation is designed to function as a programmable (universal) remote control. The CIR logic is designed to transmit and receive data packets according to the user definable frame structure and packet content.

Though the CIR module supports both transmit and receive, the driver will support only receive. There are two distinct methods of encoding for remote control applications. The first uses time extended bit forms i.e. a variable pulse distance (or duration) whereby the difference between a logic one and logic zero is the length of the pulse width (Eg: SIRC Bit Encoding); and the second is the use of a bi-phase where the encoding of the logic zero and one is in the change of signal level from 1 ≥ 0 or 0 ≥ 1 respectively (Eg: RC-5 Bit Encoding).

The CIR driver supports only RC-5 encoding.

Programming the universal remote control

Follow the following steps to program the Philips universal remote to emit the codes for a Philips TV.

1. Press and hold the CODE SEARCH button until the red indicator stays on, then release the CODE SEARCH button.
2. Press and release the TV mode button. The red indicator blinks, and then stays lit.
3. Enter the 4 digit code, 0020. After the valid code entry, the red indicator turns off. For an invalid code, the red indicator flashes.
4. Now the remote controller is programmed to give out RC-5 code for Philips TV.

Sample code for CIR driver

The driver can be tested using the application provided here

Run this application and press keys 0-9 to test IR remote.

Audio Driver

The amixer control for volume control across all outputs (master volume control) is managed through 'PCM Playback Volume' amixer control PSP 3.x

In LSP 2.x the master volume control is:

target$ amixer sget Master Volume Playback
Simple mixer control 'Master',0
  Capabilities: pvolume
  Playback channels: Front Left - Front Right
  Limits: Playback 0 - 127
  Mono:
  Front Left: Playback 126 [99%]
  Front Right: Playback 126 [99%]

In PSP 3.x the amixer master volume control is:

target$ amixer sget PCM Volume Playback
Simple mixer control 'PCM',0
  Capabilities: pvolume
  Playback channels: Front Left - Front Right
  Limits: Playback 0 - 127
  Mono:
  Front Left: Playback 80 [63%] [-23.50dB]
  Front Right: Playback 80 [63%] [-23.50dB]