Getting Started Guide for DM385 FossilShale
Using the RidgeRun DM385 SDK requires the use of a supported host operating system on your development workstation, toolchain to cross compile for ARM, several packages from TI, and the RidgeRun SDK of course. Start by downloading the following packages:
- EZSDK version 5.05.02.00
- toolchain 2009q1-203 from codesourcery
- as well as the RidgeRun DM385 SDK following the steps from the RidgeRun Installation guide.
The first section of this guide shows you how to install the EZSDK for DM385 on your computer. Subsequently, the second section contains instructions about how to configure the RidgeRun's SDK to create an SD card with all software components (uboot, kernel and filesystem) needed to boot Linux with the busybox shell running on your FS-DM385. Furthermore we describe how to enable the Graphics SDK support on the Professional SDK. Finally, instructions are provided showing how to run opemax demos to encode and decode 1080p/h264 videos and some pipelines using MIPI/CSI2 video capture.
In the rest of this document, we refer as $DEVDIR to the path where the RidgeRun SDK is installed.
Installing the EZSDK
1. Get the EZSDK software from TI's web site.
2. Set the EZSDK binary as executable.
sudo chmod 777 ezsdk_dm814x-evm_5_05_02_00_setuplinux
3. Install EZSDK. For Ubuntu versions different than Ubuntu 10.04 LTS 32-bit you will need to add the --forcehost argument to install it:
./ezsdk_dm814x-evm_5_05_02_00_setuplinux --forcehost --mode console
During the EZSDK installation process you will be asked for the toolchain's path, assuming that you installed it on /opt, the path that you need to provide is /opt/codesourcery/arm-2009q1/bin.
Installing the SDK
Follow the instructions you received via email after requesting access to the SDK. Once you have downloaded the SDK, you can install it on your development machine.
md5sum RidgeRun-SDK-DM385FOSSILSHALE-EVAL2014Q4-Linux-x86-Install.bin DEVDIR=$HOME/work/rr-dm385fs # adjust to match your preferences mkdir -p $HOME/work ./RidgeRun-SDK-DM385FOSSILSHALE-EVAL2014Q4-Linux-x86-Install.bin --mode console --prefix $DEVDIR
Build the SDK
1. Set your environment variables
cd $DEVDIR `make env`
3. Activate the SDK configuration system
Running make config your SDK is going to download all basic packages needed by the SDK build system. Press exit to save the configuration.
2. Build the system
Booting from a SD card
Configuring SDK to deploy firmware to a SD card
You need to configure the DM385 SDK to deploy the firmware components (kernel, uboot and MLO) into a bootable SD card. The RidgeRun SDK support several filesystem types (EXT3, NFS, etc) for the target file system that will be stored on the SD card.
1. Set your environment variables
cd $DEVDIR `make env`
2. Activate the SDK configuration system
3. Go to Installer Configuration submenu and configure your installer as is shown in Fig.2
Using the Firmware deployment mode submenu you can set how to deploy your kernel, uboot and filesystem image into your target board. There are three options in this submenu: Attached board on communication port, Deploy all the firmware to an SD card and Create an SD card installer for flash memory.
- Attached board on communication port will allow you to send images to your target board using a serial port or a TFTP server, more details about this option are explained in the next section.
- Deploy all the firmware to an SD card tells to the installer that it must create the needed partitions on a SD card located in SD device on Linux host (please be sure that the option called Flash SD card image into loopback file instead of real SD is not selected) and that it have to install there the software's images generated by the SDK.
- Create an SD card installer for flash memory is going to create and SD card with all the logic and software's images needed to flash the EVM's NAND from the SD card.
4. Go to File System Configuration submenu and configure your filesystem as is shown in Fig.3
5. Compile your SDK
Installing SDK's firmware to a SD card
Once you have built your SDK, you need to install it on the SD card running make install, but before issuing this command you need to unmount your SD card, otherwise the you host Ubuntu system won't let you install onto a mounted file system. Let's suppose that the environment variable called $SDNAME contains your SD card file system mount point name (Normally if you press tab after umount /media/ it will complete it with you SD card name, if you have problems to find the name you can use commands like "df" or "mount" to verify it)
umount /media/$SDNAME cd $DEVDIR make install
you will be asked to confirm the device that you are going to partition and format, please enter yes if it is correct. After this, the SDK will start to create a bootable SD card.
Now you are ready to test your SDK booting from a SD card. Two partitions were created by the SDK: boot partition which contains the kernel, uboot and MLO image and the rootfs partition containing the target file system. It's important to notice that the environment of uboot is located in a *.txt file in the partition called boot, which allows you to modify it easily.
Using GStreamer and saLoopBack
Some examples of use of GStreamer to implement basic multimedia pipelines can be found at Gstreamer pipelines for DM385. Please be aware that in order to display video you need to do the Video initialization
This application demonstrates simple loop back from capture to display. The application takes input through the specified port (in this case, the application is modified to take input from CSI2 port). Capture buffers are displayed using V4L2 display driver. The sample application design incorporates a user pointer buffer mechanism for both capture and display. User pointer buffers are taken from the FBDEV driver. V4L2 capture driver outputs YUV422 (y and cbcr interleaved) data to memory and the display driver accepts the same format from memory. The capture driver detects the incoming resolution, then configures the capture and display driver for the same resolution. For example, with 1080P60 input resolution, saLoopBack sets the buffer size to 1920*1080*2 for both display and capture. The application changes the display resolution to 1080P60 using the sysfs entry. Review the saLoopBack code for details.
In order to execute saLoopBack example, go to the linux psp-examples ubication
And execute the saLoopBack software example
Configure RidgeRun SDK to load V4L2 Firmware
In order to enable MIPI/CSI2 capture support in the FS-DM385, the V4L2 VPSS firmware has to be loaded. Specifically, the VPSS media controller needs to be running the DM385 modified firmware in order to support the new ISS capture features. Remember that Evaluation SDK for DM385 has a limited video capture when using ISS hardware module. The Professional SDK does not have this limitation when capturing frames through the MIPI/CSI2 port.
1. If you are using the RidgeRun SDK please run make config to display the SDK configuration menu. Go to the Proprietary software submenu and choose the 'Enable V4L2 capture capability option as is shown in Fig. 7.
cd $DEVDIR `make env` make config
2. Enable the V4L2 capture Driver.
Go to Kernel configuration -> Device Drivers -> Multimedia support -> Video capture adapters and select TI81XX V4L2-Capture driver
Then close the menu and save your changes.
3.Compile and install your SDK
make make install
4. Verify proper video port mapping on the FS-DM385
Your system should be ready to capture using V4L2 and you will be able to capture from both video input nodes. If the V4L2 display driver is enabled as well, the video nodes would have the following map:
/dev/video0 --> Capture VIP 0 Port A /dev/video1 --> Display 0 /dev/video2 --> Display 1 /dev/video3 --> Display 2 /dev/video4 --> Capture VIP 0 Port B /dev/video5 --> Capture VIP 1 Port A /dev/video6 --> Capture VIP 1 Port B /dev/video7 --> Capture MIPI/CSI2 Port
/dev/video7 and /dev/video1 have been tested with the RidgeRun SDK for MIPI/CSI2 capture and HDMI display.
You can test dual capture using the saLoopBack demo application installed on /usr/share/ti/ti-psp-examples or with gstreamer pipelines.
There are performance parameters that can be tuned in the Linux kernel. Here some interesting pages are listed with tuning solutions and tricks specially for memory lateness issues.
Customize console number to be used by the SDK
The RidgeRun SDK doesn't use the default bootargs and instead it generates the bootargs according to what is configured from the make config menu, one part is fixed and the other part can be specified from the make config menu
-> Kernel configuration (mem=364M@0x80000000 mem=320M@0x9FC00000 vmalloc=512M vram=81M) Extra kernel arguments
In case of the console, it can't be set from the make config, instead it is set in:
$DEVDIR/fs/mach/base$ rgrep console * Makefile: $(V)echo -n "console=ttyO2,115200n8 ">>$(CMDLINEFILE)
You will also need to change the console to be used by inittab on busybox for the filesystem.
cd $DEVDIR/fs mkdir mach/base/etc/ cp arch/base/etc/inittab mach/base/etc/inittab
open the inittab file and set the tty* needed (for instance ttyO0)