DaVinci PSP 3.00 Linux Installation User Guide

DaVinci PSP Overview

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

• DaVinci Linux Kernel version 2.6.31-rc2 with the support for DM355 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.06-rc0 with the support for DM355 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 GIT Linux Kernel Releases for the latest release.

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.00 Installation on DM355 EVM

DaVinci PSP Installation on DM355 EVM covers how to install the DaVinci PSP 03.00 release software components on DM355 EVM.

Migration to DaVinci PSP 3.00

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 DM355 device).

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

There are generic changes in the core part of the kernel in 2.6.31-rc2, 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. MMC/SD sub-system improved the performance using a better buffer allocation/management mechanism and also brought in SDIO support. Details on the DaVinci specific device drivers are given below.

Baseport SoC, EVM support

DaVinci PSP 3.00 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 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).

EDMA

DaVinci PSP 3.00 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_dest_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.

Current driver has a limitation of using GPIO 0-9 direct/unbanked interrupts together with the banked interrupts. The default behavior of the driver is use banked interrupts for all GPIOs (including GPIO 0-9). In this case all GPIO interrupts work, provided they are available through pinmux. The DM355 SoC file - arch/arm/mach-davinci/dm355.c file can be configured to enable direct/unbanked interrupts for GPIO 0-9. However, with this change GPIO 10 - 103 in interrupt mode (through banked interrupts) would not work.

@@ -865,11 +865,12 @@ static struct davinci_soc_info davinci_soc_info_dm355 = {

        .intc_irq_prios         = dm355_default_priorities,
        .intc_irq_num           = DAVINCI_N_AINTC_IRQ,
        .timer_info             = &dm355_timer_info,
        .gpio_base              = IO_ADDRESS(DAVINCI_GPIO_BASE),
        .gpio_num               = 104,
-       .gpio_irq               = IRQ_DM355_GPIOBNK0,
+       .gpio_irq               = IRQ_DM355_GPIO0,
+       .gpio_unbanked          = 10,
        .serial_dev             = &dm355_serial_device,
        .sram_dma               = 0x00010000,
        .sram_len               = SZ_32K,
 };

Video drivers

Video capture

The video capture driver supports capture from TVP5146 and MT9T031 sensor. The vpfe capture bridge driver (aka vpfe capture) is ported based on the v4l2 sub device framework. So both TVP514x (to support TVP5146) and MT9T031 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-dm355-evm.c) and allows for easy customization. For vpfe capture driver, the platform data structure defines the vpfe 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 CCDC modules for a specific platform is registered with the vpfe capture. It registers a set of function calls that are called by vpfe capture driver to configure the ccdc module for capture.

The vpfe 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.

For MT9T031, the driver doesn't support VIDIOC_S_STD ioctl. So to capture a specific resolution frame, application needs to call VIDIOC_S_FMT ioctl. The vpfe capture from MT9T031 requires following bootargs to be set:- vpfe_capture.interface=1. By default, vpfe capture has this variable set to 0 for tvp5146 capture.

Video display

Only display driver supported is the old frame buffer display driver that was available in davinci git tree. This has been ported to DM355 and DM6446. It has only few features supported. It supports VID1 for displaying video and OSD0 and OSD1 for graphics. V4L2 display driver is currently not available.

IPIPE - Previewer/Resizer

IPIPE driver is ported from LSP 2.00. It works similar to what is available in LSP 2.00.

H3A - AF/AEW

H3A driver is ported from LSP 2.00. It works similar to what is available in LSP 2.00.