DRA7xx GLSDK Software Developers Guide
Contents
- 1 Introduction
- 2 Starting your software development
- 3 Repo tool Usage
- 4 Building Yocto Filesystem
- 5 GLSDK software overview
- 6 Running Examples
- 6.1 Finding Connector Id
- 6.2 Graphics demos
- 6.3 Running aplay and arecord application
- 6.4 Running viddec3test application
- 6.5 Running DSP sample applications
- 6.6 Running a gstreamer pipeline
- 6.7 Running bvtest application
- 6.8 Running VIP/VPE application
- 6.9 Running DSS application
- 6.10 Gsttestplayer
- 7 Booting EVM with different modes
- 8 Using the Late attach functionality
- 9 Changing MPU Frequency (DVFS)
- 10 Additional Procedures
Introduction
Welcome to the DRA7xx GLSDK Software Developer's Guide.
Thank you for choosing the DRA7xx evm for your application. The purpose of this guide is to get you going with developing software for the DRA7xx on a Linux development host only.
Note! All instructions in this guide are for Ubuntu 12.04. At this time, this is the only supported Linux host distribution for development.
Some commands are to be executed on the Linux development host, some on the Linux target and some on the u-boot (bootloader) prompt. The following conventions are used to distinguish the commands on a host and on the target:
host $ <this command is to be executed on the host> target # <this command is to be executed on the target> u-boot :> <this command is to be executed on the u-boot prompt>
Starting your software development
Setup up ARM linux development Environment on the host. Please refer to this link to see how to set one up.
Configuration of ARM Linux development Environment
Step 1: Install the GLSDK release on the host machine.
- Download the GLSDK installer for your platform.
- If necessary make the installer executable manually by executing:
host $ chmod +x ti-glsdk_dra7xx-evm_6_10_00_02_linux-installer.bin
- Execute the installer on the host and follow the instructions:
host $ ./ti-glsdk_dra7xx-evm_6_10_00_02_linux-installer.bin
Step 2: Setup the GLSDK environment variable to the location where the GLSDK is installed (the following assumes that GLSDK was installed at default location):
host $ export GLSDK="${HOME}/ti-glsdk_dra7xx-evm_6_10_00_02"
Step 3: Setup the GLSDK on host
The GLSDK comes with a script for setting up your Ubuntu 12.04 LTS development host. It is an interactive script, but if you accept the defaults by pressing return you will use the recommended settings. This is recommended for first time users. Note that this script requires ethernet access as it will update your Ubuntu Linux development host with the packages required to develop using the GLSDK.
Note: Please make sure that the proxy settings are done for http, https, git, ftp and wget before proceeding further.
Execute the script in the GLSDK release directory using:
host $ cd ${GLSDK}
host $ ./setup.sh
The setup script would perform the following operations:
- Installs all the necessary package on the host for the SDK.
- Prepares the UART terminal to communicate with the target over Debug USB on Minicom. If you want to use a windows host for connecting to the target instead, see the #Setting_up_Tera_Term section
- Setups the linaro cross compiler
- Installs the dependencies for the repo tool.
- Initialize the repo by pointing it to GLSDK release manifest location.
- Note: During this setup process, if the ducati tools are installed there is known issue as below
- XDC installation contains 64-bit version of gmake binary. Hence would not work with 32-bit Host m/c. Please download 32-bit binary from here and replace exiting gmake with the downloaded one if the installation is on a 32-bit Ubuntu host OS.
To start minicom on your Linux development host execute minicom -w (or Tera Term on Windows).
Step 4: Prepare SD card
To install the release image, you need a µSD Card (at least 4GB) with 2 partitions:
- boot (vfat) partition.
- rootfs (ext4 or ext3) partition.
The following procedure prepares the sdcard: (however, the user can choose to do it manually as well)
- Plug an SD card reader to your PC and insert a µSD card. It must be at least 4GB size.
- Identify which device corresponds to the SD card reader. sudo fdisk -l command can help you find out where the µSD Card is mapped. We will call it /dev/sdY here.
Note : If you are using NFS file system, then edit ${GLSDK}/board-support/pre-built-images/boot.script.sd, add "ip=dhcp" in bootargs.
- Re-format your µSD card with this script mksdboot.sh from the bin directory in the GLSDK
$ sudo ${GLSDK}/bin/mksdboot.sh --device /dev/sdY --sdk ${GLSDK}
The above script would prepare the SD card with the prebuilt images and yocto filesystem for SD boot.
Step 5: Booting the board
To boot the board with the above created SD card, refer to the Quick Start Guide at the GLSDK download location (https://software-dl.ti.com/dsps/dsps_public_sw/glsdk/latest/index_FDS.html) to setup the board.
Then, power cycle the board and login with username as root.
Repo tool Usage
Starting source code development using repo tool
The GLSDK release uses the repo tool to effectively manage the different components of the GLSDK.
NOTE :
1: The first step to the repo tool is the repo initialization and this is done as part of the $GLSDK/setup.sh script
2: The repo tool is downloaded into the bin folder in the GLSDK directory. Please ensure that this path is updated in the environment variable as shown below
host $ export PATH=${GLSDK}/bin:$PATH
The GLSDK release contains a helper script that sets up the development environment. Run the script as shown below:
host $ cd ${GLSDK}
host $ ./bin/fetch-sources.sh
The script does the following:
- Check for the repo tool.
- Perform repo sync
- Create a branch called glsdk_dev
- Checkout the branch glsdk_dev
It is expected that the development is done on the glsdk_dev branch.
How to get updates
If there are changes in the remote repositories, it could be fetched using the same script.
However, please make note of these important points.
1. The script will fetch the latest changes, and switch back to the glsdk_dev branch.
2. The new updates from the remote, will be available in the master branch.
3. The decision on whether to merge the changes to the local branch or merge the local branch to the master is left to the developer
Building Yocto Filesystem
Please ensure that the setup.sh script is run as described in Starting your software development section and answer 'yes' to fetch-sources prompt.
Before building the filesystem, ensure that the svn, http, ftp and git proxies are set correctly. Refer to the following link for these settings https://wiki.yoctoproject.org/wiki/Working_Behind_a_Network_Proxy.
Add the Linaro cross-compile toolchain path in the PATH environment variable.
host $ export PATH=<Path to Linaro cross-compile toolchain>/bin:$PATH
Run this command to as a one-time setup for the yocto build
host $ cd $GLSDK host $ ./bin/setup-yocto.sh
For building core sdk , run the build-core-sdk.sh passing machine name as an argument.
host $ cd yocto-layers
Create a downloads directory (if building using Yocto for the first time), where the Yocto build will place the downloads. Note the path of the directory.
host $ mkdir downloads
NOTE: Please pass the same downloads directory path to the following build-script when prompted
host $ ./build-core-sdk.sh dra7xx-evm
These scripts will build the arago-glsdk-multimedia-image.
After build is complete the generated images can be found in yocto-layers/build/arago-tmp-external-linaro-toolchain/deploy/images/
| Image name | Description |
|---|---|
| arago-glsdk-multimedia-image-<MACHINE-NAME>-<DATE>.rootfs.tar.gz | This is the filesystem tarball. Copy and extract it on the rootfs partition of the boot media. |
| uImage-<MACHINE-NAME>.bin | uImage for the machine. Copy as uImage in boot partition. |
| uImage-<MACHINE-NAME>.dtb | Copy dra7-evm.dtb in boot partition. |
| u-boot-<MACHINE-NAME>.img | Copy as u-boot.img in boot partition. |
Note: The build does not generate a boot.scr. You need to copy it from the prebuilt binaries in the release.
Modifying source code and rebuilding a component
Once the Yocto setup is complete developers would like to modify a certain component source code and rebuild it.
The source code for the generic components like omapdrmtest can be found in ${GLSDK}/yocto-layers/build/arago-tmp-external-linaro-toolchain/work/cortexa15hf-vfp-neon-3.8-oe-linux-gnueabi/
Steps to rebuild:
1. Modify the source of the component in its work area
2. cd to yocto-layers
host $ cd ${GLSDK}/yocto-layers
3. export PATH if not done previously:
host $ export PATH=<Path to Linaro cross-compile toolchain>/bin:$PATH
4. Run one/combination of the folowing tasks:
a. To configure and compile with the latest changes in the work area:
host $ ./build-specific-recipe.sh <MACHINE-NAME> -f -c configure <RECIPE-NAME> host $ ./build-specific-recipe.sh <MACHINE-NAME> -f -c compile <RECIPE-NAME>
For example, if the omapdrmtest source is modified and you want to generate only the binaries for dra7xx-evm, the compile task should suffice:
host $ ./build-specific-recipe.sh <MACHINE-NAME> -f -c compile omapdrmtest
The binaries will be present in the same folder as the source files.
b. To generate .ipk package in addition to the binaries, following additional tasks need to be run after above steps:
host $ ./build-specific-recipe.sh <MACHINE-NAME> -f -c install <RECIPE-NAME> host $ ./build-specific-recipe.sh <MACHINE-NAME> -f -c package <RECIPE-NAME> host $ ./build-specific-recipe.sh <MACHINE-NAME> -f -c package_write_ipk <RECIPE-NAME>
This will generate .ipk packages for the recipe. They can be found in the deploy-ipks folder of the work area of the recipe.
The .ipk packages can be copied and installed on the target by:
target $ opkg install <PACKAGE-NAME>
This approach is useful in the case of recipes that generate a large number of binaries, that are difficult to copy manually, like gst-plugins-bad.
c. During building and debugging the kernel or kernel modules, the compile_kmodules task needs to be executed that generates kernel modules.
host $ ./build-specific-recipe.sh <MACHINE-NAME> -f -c compile_kmodules <RECIPE-NAME>
For a complete set of tasks that a specific recipe executes during its build, please refer to the log.task_order in the temp folder of the component.
Pass the relevant tasks to build-specific-recipe.sh for required outcome.
5. For a robust solution , once the change in source area is tested with the above steps, please update the recipe.
a. create a patch of the change
b. copy it in the folder where the recipe is present
c. add the patch name in the SRC_URI variable in the recipe
The build-specific-recipe.sh recognizes the change in the recipe and builds it if required.
To build a specific component after recipe is updated, use the build-specific-recipe.sh
host $ ./build-specific-recipe.sh <MACHINE-NAME> <RECIPE NAME>
For example to build omapdrmtest:
host $ ./build-specific-recipe.sh <MACHINE-NAME> omapdrmtest
MACHINE-NAME can be either omap5-evm or dra7xx-evm
To clean a specific component:
host $ ./clean-specific-recipe.sh <MACHINE-NAME> <RECIPE NAME>
GLSDK software overview
The GLSDK contains many software components. Some are developed by Texas Instruments and some are developed in and by the open source community(White). TI contributes, and sometimes even maintains, some of these open source community projects, but the support model is different from a project developed solely by TI.
Running Examples
Finding Connector Id
Note: Most of the applications used in the Demos would require the user to pass a connector id. A connector id is a number that is assigned to each of the display devices connected to the system. To get the list of the display devices connected and the corresponding connector id one can use the modetest application (shipped with the file system) as mentioned below:
target # modetest
Look for the display device u need the id for, such as HDMI, LCD etc. Usually LCD is assigned 4 (800x480), HDMI is assigned 12 (multiple resolutions).
Graphics demos
The graphics driver and userspace libraries and binaries are distributed along with the SDK. Please make sure the board is connected to a display. To execute the demos, the graphics driver must be initialised by running pvrsrvinit.
target # pvrsrvinit
kmscube
Run kmscube on default display (LCD):
target # kmscube
Run kmscube on secondary display (HDMI):
target # kmscube -c <connector-id> target # kmscube -c 12 #Usually, the connector id for HDMI is 12.
Run kmscube on all connected displays (LCD & HDMI & FPDLink(optional)):
target # kmscube -a
kmscube with video
A new demo has been added into the GLSDK starting with 6.10.00.01 release. This demo allows a video frame to be applied as a texture onto the surface of the kmscube. The user can invoke the demo by following the syntax below:
target # viddec3test <path_to_the_file> --kmscube --connector <connector_number>
Run kmscube with video on default display (LCD):
target # viddec3test <path_to_the_file> --kmscube
Run kmscube with video on secondary display (HDMI):
target # viddec3test <path_to_the_file> --kmscube --connector 12 #Usually, the connector id for HDMI is 12.
Additionally, to change the field of view of the rotating cube, the user can specify the same on the command line like below:
target # viddec3test <path_to_the_file> --kmscube --connector <connector_number> --fov <number>
Wayland/Weston
Starting from GLSDK 6.04, the supported Wayland/Weston version is 1.3.0 which brings in the multiple display support in extended desktop mode and the ability to drag-and-drop windows from one display to the other.
To execute the demos, the graphics driver must be initialized by running pvrsrvinit.
target # pvrsrvinit
To launch weston, do the following:
On default display (LCD):
target # weston --tty=1 --connector=4
On secondary display (HDMI):
target # weston --tty=1 --connector=12
On the third display (FPD link):
target # weston --tty=1 --connector=16
On all connected displays (LCD, HDMI and FPDLink):
target # weston --tty=1
By default, the screensaver timeout is configured to 300 seconds.
The user can change the screensaver timeout using a command line option
--idle-time=<number of seconds>
For example, to set timeout of 10 minutes and weston configured to display on all connectors, use the below command:
weston --tty=1 --idle-time=600
If you face any issues with the above procedure, please refer GLSDK_FAQs#Unable_to_run_Weston_on_the_GLSDK_release for troubling shooting tips.
The filesystem comes with a preconfigured weston.ini file which will be located in /home/root/.config/weston.ini after running the initialization steps.
Running weston clients
After launching weston, the user should be able to use the keyboard and the mouse for various controls.
There are two icons on the top right hand corner of the weston desktop window which have been configured for
- terminal
- flower application
Clicking these respective icons should launch the applications on the Weston Desktop.
There are several other applications that are included in the default filesystem. To invoke these applications, the user should launch the weston-terminal (top right hand corner of the desktop) and then invoke the client apps as described below from within the terminal window:
wayland sh # /usr/bin/weston-clients/weston-flower
wayland sh # /usr/bin/weston-clients/weston-clickdot
wayland sh # /usr/bin/weston-clients/weston-cliptest
wayland sh # /usr/bin/weston-clients/weston-dnd
wayland sh # /usr/bin/weston-clients/weston-editor
wayland sh # /usr/bin/weston-clients/weston-eventdemo
wayland sh # /usr/bin/weston-clients/weston-image /usr/share/weston/terminal.png
wayland sh # /usr/bin/weston-clients/weston-resizor
wayland sh # /usr/bin/weston-clients/weston-simple-egl
wayland sh # /usr/bin/weston-clients/weston-simple-shm
wayland sh # /usr/bin/weston-clients/weston-simple-touch
wayland sh # /usr/bin/weston-clients/weston-smoke
wayland sh # /usr/bin/weston-clients/weston-info
wayland sh # /usr/bin/weston-clients/weston-terminal
wayland sh # /usr/bin/weston-clients/weston-subsurfaces
Running multimedia with Wayland sink
The GStreamer video sink for Wayland is the waylandsink. To use this video-sink for video playback:
target # gst-launch playbin2 uri=file://<path-to-file-name> video-sink=waylandsink
Exiting weston
If you have invoked Weston from the serial console, exit Weston by pressing Ctrl-C.
It is also possible to invoke Weston from the native console, exit Weston by using pressing Ctrl-Alt-Backspace.
X Server
The X server has been deprecated starting with release version 6.10.00.01. The following instructions apply if you are using X server on older 6.0x releases.
To start the X server, connect a display and run the xinit command.
target # xinit
Launch multiple X terminals
Launch multiple xterms with preferred size and position.
target # xterm --geometry 1000x1000+0+0
Configuration with xrandr
XRandr is a commandline tool that allows an ability to resize, rotate and reflect the root window of a screen. Invoking xrandr without any options will display the connectors, supported, preferred and current mode for the connectors.
target # xrandr
To change the mode, select one of the supported modes from xrandr output, eg. 1920x1080 for connector HDMI-1
target # xrandr --output HDMI-1 --mode 1920x1080
Reflection:
target # xrandr --output HDMI-1 --reflect normal target # xrandr --output HDMI-1 --reflect x target # xrandr --output HDMI-1 --reflect y target # xrandr --output HDMI-1 --reflect xy
Rotation:
target # xrandr --output HDMI-1 --rotate left target # xrandr --output HDMI-1 --rotate right target # xrandr --output HDMI-1 --rotate normal
Running X applications
After starting the X server, the user should be able to use the keyboard and the mouse for various controls.
The SDK comes with X applications that can be run once the X server is initialized. To run them:
target # xgles1test1 target # xgles2test1
Running multimedia with X11 sink
The GStreamer video sink for X11 is the dri2videosink. To use this video-sink for video playback:
target # gst-launch playbin2 uri=file://<path-to-file-name> video-sink=dri2videosink
Running multimedia and graphics
target # gst-launch playbin2 uri=file://<path-to-file-name> video-sink=dri2videosink & xgles1test1
Running dual decode on dual display using X11
By default, the X server runs in a clone mode on the LCD and HDMI display. To run the displays in an extended mode, run the following commands: Please export DISPLAY=:0 if running from serial console.
target # xinit target # openbox-session target # xrandr --output HDMI-1 --auto --output LCD-1 --auto --right-of HDMI-1
This will set the LCD output to the right of HDMI output. You can drag and drop windows between the two outputs. To launch two multimedia decode pipelines:
target # gst-launch playbin2 uri=file:///<file1> video-sink=dri2videosink & gst-launch playbin2 uri=file:///<file2> video-sink=dri2videosink
This will launch playback of the two files on two separate windows on the HDMI screen. Resize and drag one of the windows using mouse on the LCD output.
Running aplay and arecord application
To playback/record on the evm via headset/mic, please make sure the following amixer settings are done:
- For playback via headset, enter the following at prompt target#
amixer sset 'Left DAC Mux',0 'DAC_L2' amixer sset 'Right DAC Mux',0 'DAC_R2' amixer cset name='HP Playback Switch' On amixer cset name='Line Playback Switch' Off amixer cset name='PCM Playback Volume' 127
Once these settings are successful, use aplay application for playback:
target # aplay <path_to_example_audio>.wav
- For recording via Mic In
amixer cset name='Left PGA Mixer Mic3L Switch' On amixer cset name='Right PGA Mixer Mic3L Switch' On amixer cset name='Left PGA Mixer Line1L Switch' off amixer cset name='Right PGA Mixer Line1R Switch' off amixer cset name='PGA Capture Switch' on amixer cset name='PGA Capture Volume' 6
Once these settings are successful, use arecord to record
target # arecord -r 44.1 > <path_to_example_audio>.wav
Running viddec3test application
viddec3test is a demo application for decoder/video playback using hardware accelerators. The application currently runs on the kms display. The application requires the connector information for display. One can get the information of the display connected to the board by running the modetest application in the filesystem.
target # modetest
To execute the application make sure the display is connected to the board.
Running a decode on a display
To run a hardware decode on a display connected to the board, execute the following command:
target # viddec3test -s <connector_id>:<display resolution> filename --fps 30 e.g.: target # viddec3test -s 4:1920x1080 file.h264 --fps 30
Running single decode on dual displays
To run the output of a single decode on the dual displays. Please make sure both the displays are connected and get the information about the connectors and the resolution associated with it for both the displays from the modetest application.
target # viddec3test -s <connector_id_1>:<display resolution> -s <connector_id_2>:<display resolution> filename --fps 30
e.g.: target # viddec3test -s 4:1920x1080 -s 12:1024x768 file.h264 --fps 30
Running dual decode on dual displays
One can also run a dual decode and display their output on two different displays. Please make sure both the displays are connected and get the information about the connectors and the resolution associated with it for both the displays from the modetest application.
target # viddec3test -s <connector_id_1>:<display resolution> filename1 -s <connector_id_2>:<display resolution> filename2 e.g.: target # viddec3test -s 4:1920x1080 file1.h264 -- -s 12:1024x768 file2.h264
Running DSP sample applications
DCE framework running on DSP1 supports C66x codecs with VIDDEC2 interface. In the current version of dspdce package, Universal_copy algorithm (with IUNIVERSAL interface) is invoked from dce VIDDEC2 interfaces. Universal_copy algorithm does simple input buffer to outbuffer memcopy. To integrate C66x codecs with VIDDEC2 interface, iuniversal interfaces needs to be replaced with ividdec2 interfaces in DCE framework.
The following are the applications that one could run from A15 to exercise the above on DSP:
copycodectest: This application is to test Universal_copy with VIDDEC2 interface.
This application fills the input buffer with a number entered as argument and after process output buffer is tested for same pattern.
usage: copycodectest pattern.
Example:
target # copycodectest 123
yuvcopytest: This applciation reads one frame of yuv of known width and height into input buffer.
Luma output buffer after process call is sent to display to check if universal_copy running on DSP is properly copied to output buffer.
usage: yuvcopytest -s <connector_Id>:<mode> yuvfile -w width -h height
Example:
target # yuvcopytest -s 4:800x480 input.yuv -w 1920 -h 1080
Running a gstreamer pipeline
One can run an audio video file using the gstreamer playbin2 from the console. Currently, the supported Audio/video sink is kmssink,waylandsink,dri2videosink and alsassink.
kmssink: target # gst-launch playbin2 uri=file:///<path_to_file> video-sink=kmssink audio-sink=alsasink
waylandsink: 1. refer #Wayland/Weston to start the weston 2. target # gst-launch playbin2 uri=file:///<path_to_file> video-sink=waylandsink audio-sink=alsasink
dri2videosink: 1. refer #X_Server to start the X11 2. target # gst-launch playbin2 uri=file:///<path_to_file> video-sink=dri2videosink audio-sink=alsasink
The following pipelines show how to use v4l2src and ducatih264enc elements to capture video from VIP and encode captured video respectively. This is supported with GLSDK release version 6.10.00.02 onwards.
Capture and Display Fullscreen target # gst-launch v4l2src device=/dev/video1 queue-size=8 use-dmabuf=true ! 'video/x-raw-yuv, \ format=(fourcc)YUY2, width=(int)1280, height=(int)720' ! vpe num-input-buffers=8 ! queue ! kmssink
Capture and Display to a window in wayland 1. refer #Wayland/Weston to start the weston 2. target # gst-launch v4l2src device=/dev/video1 queue-size=8 use-dmabuf=true ! 'video/x-raw-yuv, \ format=(fourcc)YUY2, width=(int)1280, height=(int)720' ! vpe num-input-buffers=8 ! queue ! waylandsink
Capture and Encode into a MP4 file. target # gst-launch -e v4l2src device=/dev/video1 queue-size=8 use-dmabuf=true ! 'video/x-raw-yuv, \ format=(fourcc)YUY2, width=(int)1280, height=(int)720' ! vpe num-input-buffers=8 ! queue ! \ ducatimpeg4enc bitrate=4000 ! queue ! mpeg4videoparse ! qtmux ! filesink location=x.mp4
Capture and Encode and Display in parallel. target # gst-launch -e v4l2src device=/dev/video1 queue-size=8 use-dmabuf=true ! 'video/x-raw-yuv, \ format=(fourcc)YUY2, width=(int)1280, height=(int)720' ! vpe num-input-buffers=8 ! tee name=t ! queue ! \ ducatimpeg4enc bitrate=4000 ! queue ! mpeg4videoparse ! qtmux ! filesink location=x.mp4 t. ! queue ! kmssink
Running bvtest application
bvtest is an application used to test bltsville implementation using GC320.
usage:
target # bvtest: this will display the help menu and the command line options.
target # bvtest -src1file test-pattern-RGBA24-320x256\(1280\).raw -src1rect 0,0-320x256 -cliprect 80,64-160x128 -dst RGBA24 320x256 -dstrect
0,0-320x256 -dstfile copy-RGBA24-to-RGBA24-clip-center.tga -rop CCCC -imp hw2d
Running VIP/VPE application
Video Input Port
Video Input Port is used to capture video frames from Camera.
GLSDK linux kernel includes a V4L2 standard capture driver for VIP
Currently the VIP driver supports following features
- Standard V4L2 capture driver
- Supports single planar buffers
- Supports MMAP buffering method
- Supports DMABUF based buffering method (GLSDK 6.04 onwards)
- Supports V4L2 endpoint standard way of specifying camera nodes (GLSDK 6.04 onwards)
- Supports captures upto 60FPS (GLSDK 6.04 onwards)
- Multi instance capture - Currently only Vin1a, Vin2a, Vin3a, Vin5a supported (GLSDK 6.04 onwards)
- Capture from a YUYV camera(8bit)
- Capture from 24 bit RGB camera (GLSDK 6.04 onwards)
GLSDK release supports following sensors/cameras/video inputs:-
- OV10635 sensor - YUYV sensor on Vision board
- OV10635 sensor - YUYV sensor connected through LVDS (GLSDK 6.04 onwards)
- OV10633 sensor - YUYV sensor connected on J6 EVM (GLSDK 6.04 onwards)
- TVP5158 decoder - Support for decoding single channel analog video (GLSDK 6.04 onwards)
- FPDlink - Output of FPDlink display can be used as a camera input source (GLSDK 6.04 onwards)
I2C2 v/s HDMI conflict
On J6 EVM, i2c2 lines are pinmuxed with the HDMI DDC lines Before running VIP demos, please run following commands to enable I2C2
target# devmem2 0x4a003808 w 0x60000 target# devmem2 0x4a00380C w 0x60000 target# devmem2 0x4847C010 w 0x4 target# devmem2 0x4847C014 w 0x0
To restore HDMI DDC pins, run following commands
target# devmem2 0x4a003808 w 0x60001 target# devmem2 0x4a00380C w 0x60001 target# devmem2 0x4847C010 w 0x4 target# devmem2 0x4847C014 w 0x4
Running dmabuftest
dmabuftest is a user space application which demonstrates capture display loopback. It can support multiple captures at the same time
Video buffers are allocated by libdrm and they are shared to VIP through dmabuf.
It interfaces with the VIP through standard v4l2 ioctls.
Arago filesystem from GLSDK release has dmabuftest app preinstalled.
To capture and display on the LCD screen, run following command
target# dmabuftest -s 4:800x480 -d /dev/video1 -c 1280x720@YUYV
To capture and display on the HDMI display, run following command
target# dmabuftest -s 12:1920x1200 -d /dev/video1 -c 1280x720@YUYV
Capturing from OV10633 onboard camera
GLSDK kernel driver for OV1063x cameras support OV10633 sensor.
Video capture can be verified from the OV10633 sensor as follows
- Connect OV10633 sensor to the Leopard Imaging port on the J6 EVM
- Reboot the board and enable i2c2 as given above
- I2C device on Bus 2 slave address 0x37 should be probed successfully
- VIP should register a V4L2 video device (e.g. /dev/video1) using this i2c device
- Run dmabuftest with '1280x720@YUYV' as capture format
Capturing from OV10635 Vision board camera
GLSDK kernel driver for OV1063x cameras support OV10635 sensor.
Video capture can be verified from the OV10635 sensor as follows
- Connect OV10635 sensor to the OVcam port on the Vision board
- Change the SW3 switch setting on Vision board as SW3[1-8] = 01010101
- Reboot the board and enable i2c2 as given above
- I2C device on Bus 2 slave address 0x30 should be probed successfully
- VIP should register a V4L2 video device (e.g. /dev/video1) using this i2c device
- Run dmabuftest with '1280x720@YUYV' as capture format
Capturing through TVP decoder
GLSDK linux kernel supports TVP5158 NTSC/PAL decoder.
TVP5158 decoder is a TI chip which can decode upto 4 channels of NTSC/PAL analog video and multiplex it.
Currently, GLSDK supports only 1 channel capture from TVP5158.
Video capture from 1 channel TVP5158 can be verified as follows.
- Connect analog camera to the Vin1 port of the JAMR3 board
- Change the SW2 switch setting on JAMR board as SW2[1-2] = 10
- Reboot the board and enable i2c2 as given above
- I2C device on Bus 2 slave address 0x58 should be probed successfully
- VIP should register a V4L2 video device (e.g. /dev/video1) using this i2c device
- Run dmabuftest with capture format of the analog camera (e.g. '720x240@YUYV')
Capturing through FPDlink camera
This is applicable only for 6.04.00.02 release
FPDlink camera is a device where a FPDlink deserializer can act as a camera.
On JAMR board, the FPDlink deserializer is connected to Vin1a of J6 EVM
GLSDK linux kernel has a dummy driver to control FPDlink camera
Video capture from FPDlink camera can be verified as follows.
- Connect any FPDlink serializer to the JAMR board deserializer port through FPDlink cable
- Another J6 EVM can also be used to genereate FPDlink video and can be connected here
- Even loopback, where FPDlink transmitter of base board can be connected to this port
- Apply patches http://review.omapzoom.org/35064 and http://review.omapzoom.org/35063 on linux kernel and rebuild
- Reboot the board and enable i2c2 as given above
- I2C device on Bus 2 slave address 0x20 should be probed successfully
- Note that this is a dummy driver, if this address conflict with anything else, please change in dts file
- VIP should register a V4L2 video device (e.g. /dev/video1) using this i2c device
- Run dmabuftest with capture format of FPDlink display (e.g. '1280x720@AR24')
- As FPDlink display transmits video in RGB format, in this case, Vin1a is configured for 24bit RGB data
Capturing through LVDS camera
LVDS camera is also a camera connected through a serializer and deserializer
GLSDK linux kernel has driver for FPDlink serializers and deserializers
For interfacing every LVDS camera with J6, an I2C slave for ser, deser and camera is needed. By default, all of the device tree nodes are disabled.
Following table shows mapping between all LVDS cameras on multi deserializer duaghter card for Vision Board.
LVDS camera Camera address alias Serializer address alias Derializer address VIP port
cam1 0x38 0x74 0x60 Vin1a(VIP1 slice0 port A) cam2 0x39 0x75 0x64 Vin2a(VIP1 slice1 port A) cam3 0x3A 0x76 0x68 Vin3a(VIP2 slice0 port A) cam4 0x3B 0x77 0x6C Vin5a(VIP3 slice0 port A) cam5 0x3C 0x78 0x61 Vin4b(VIP2 slice1 port B) cam6 0x3D 0x79 0x69 Vin6a(VIP3 slice1 port A)
Also, the ser/deser drivers fight with HDMI driver for using I2C lines as I2c vs DDC. Therefore, when using LVDS cameras, we need to disable HDMI.
To disable HDMI and enable all the LVDS cameras, apply the patches attached here.
For 6.04 release:- Enable_LVDS_Cameras.zip
For 6.10 release:- Enable_LVDS_Cameras.zip
Video capture from LVDS camera can be verified as follows.
- Connect a LVDS camera to cam1/2/3/4 port of Multides board.
- Change the SW3 switch setting on Vision board as SW3[1-8] = 00100101
- Apply attached patches on linux kernel and rebuild
- I2C device on Bus 2 slave address (e.g. 0x38 for cam1) should be probed successfully
- VIP should register a V4L2 video device (e.g. /dev/video1) using this i2c device
- Run dmabuftest with '1280x720@YUYV' as capture format
Video Processing Engine(VPE)
VPE supports Scalar, Colour Space Conversion and Deinterlace.It uses V4L2 mem2mem API.
Supported Input formats: nv12, yuyv, uyvy
Supported Output formats: nv12, yuyv, uyvy, rgb24, bgr24, argb24, abgr24
Not Supported formats: yuv444, yvyu, vyuy, nv16, nv61, nv21
File to File
testvpe Usage: <SRCfilename> <SRCWidth> <SRCHeight> <SRCFormat> <DSTfilename> <DSTWidth> <DSTHeight> <DSTformat> <interlace> <translen>
Note:
<interlace> : set 1, If input is interlaced and want deinterlaced(progressive) output. output height should be twice of input height.
Deinterlace(DI):-
target# testvpe frame-176-144-nv12-inp.yuv 176 144 nv12 progressive_output.nv12 176 288 nv12 1 1
Scalar(SC):-
target# testvpe frame-176-144-nv12-inp.yuv 176 144 nv12 frame-1920-1080-nv12-out.nv12 1920 1080 nv12 0 1
Colour Space Conversion(CSC):-
target# testvpe frame-720-240-yuyv-inp.yuv 720 240 yuyv frame-720-240-argb32-out.argb32 720 240 argb32 0 1
SC+CSC+DI:-
target# testvpe frame-720-240-yuyv-inp.yuv 720 240 yuyv frame-1920-1080-rgb24-dei-out.rgb24 1920 1080 rgb24 1 1
File to Display
filevpedisplay Usage: <src_filename> <src_w> <src_h> <src_format> <dst_w> <dst_h> <dst_format> <top> <left> <w> <h> <inter> <trans> -s <conn_id>:<mode>
Input without crop:
target# filevpedisplay frame-176-144-nv12-inp.yuv 176 144 nv12 800 480 yuyv 0 0 176 144 0 1 -s 4:800x480
Input with crop:
target# filevpedisplay frame-176-144-nv12-inp.yuv 176 144 nv12 800 480 yuyv 16 32 128 128 0 1 -s 4:800x480
VIP-VPE-Display
Support for this is added from GLSDK 6.04 onwards Camera captures the frames, which are processed by VPE(SC, CSC, Dei) then displays on LCD/HDMI.
capturevpedisplay Usage: <src_w> <src_h> <src_format> <dst_w> <dst_h> <dst_format> <inter> <trans> -s <conn_id>:<mode>
target# capturevpedisplay 640 480 yuyv 320 240 uyvy 0 1 -s 4:640x480
Running DSS application
DSS applications are omapdrm based. These will demonstrate the clone mode, extended mode, overlay window, z-order and alpha blending features. To demonstrate clone and extended mode, HDMI display must be connected to board. Application requires the supported mode information of connected displays and plane ids. One can get these information by running the modetest application in the filesystem.
target # modetest
Running drmclone application
This displays same test pattern on both LCD and HDMI (clone). Overlay window also displayed on LCD. To test clone mode, execute the following command:
target # drmclone -l <lcd_w>x<lcd_h> -p <plane_w>x<plane_h>:<x>+<y> -h <hdmi_w>x<hdmi_h>
e.g.: target # drmclone -l 800x480 -p 320x240:0+0 -h 640x480
We can change position of overlay window by changing x+y values. eg. 240+120 will show @ center
Running drmextended application
This displays different test pattern on LCD and HDMI. Overlay window also displayed on LCD. To test extended mode, execute the following command:
target # drmextended -l <lcd_w>x<lcd_h> -p <plane_w>x<plane_h>:<x>+<y> -h <hdmi_w>x<hdmi_h>
e.g.: target # drmextended -l 800x480 -p 320x240:0+0 -h 640x480
Running drmzalpha application
Z-order:
It determines, which overlay window appears on top of the other.
Range: 0 to 3
lowest value for bottom
highest value for top
Alpha Blend:
It determines transparency level of image as a result of both global alpha & pre multiplied alpha value.
Global alpha range: 0 to 255
0 - fully transparent
127 - semi transparent
255 - fully opaque
Pre multipled alpha value: 0 or 1
0 - source is not premultiply with alpha
1 - source is premultiply with alpha
To test drmzalpha, execute the following command:
target # drmzalpha -s <crtc_w>x<crtc_h> -w <plane1_id>:<z_val>:<glo_alpha>:<pre_mul_alpha> -w <plane2_id>:<z_val>:<glo_alpha>:<pre_mul_alpha>
e.g.: target # drmzalpha -s 800x480 -w 15:1:255:1 -w 16:2:255:1
Testing with FPDLink Display setup
H/W setup
- DRA7xx EVM + 12V supply for the EVM.
- FPDLink Cable between DRA7xx and De-serilzer board (DS90UB928Q).
- 5V power supply for De-serializer board.
- LCD Adapter board (DS90UH928Q) that sits on De-serializer board.
- LCD Adapter cable which is between LCD panel and the Adapter board.
- 12V power supply for LCD Adapter board.
- The actual LCD panel (LG101(10.1in) or AUO (7.1 in))
- Please refer the picture which shows the overall setup attached here
Kernel Configuration
-> Device Drivers
-> Graphics support
-> OMAP2+ Display Subsystem support (OMAP2_DSS [=y])
-> OMAP2/3 Display Device Drivers
<*> LG101 LCD Panel
-> Device Drivers
-> Graphics support
-> OMAP2+ Display Subsystem support (OMAP2_DSS [=y])
-> OMAP2/3 Display Device Drivers
<*> SERLINK
-> Device Drivers
-> Graphics support
-> OMAP2+ Display Subsystem support (OMAP2_DSS [=y])
-> OMAP2/3 Display Device Drivers
<*> DSERLINK
Testing
On power-cycle, the EVM should boot and show the Tux Logo.
Given below is a snippet from the modetest - it should show the FPDLink Display connected via the following path.
Encoders:
id crtc type possible crtcs possible clones
3 10 TMDS 0x00000003 0x00000000
11 14 TMDS 0x00000002 0x00000000 ---------------------------> FPDLink
Connectors:
id encoder status type size (mm) modes encoders
4 3 connected unknown 0x0 1 3
modes:
name refresh (Hz) hdisp hss hse htot vdisp vss vse vtot)
800x480 60 800 841 890 931 480 493 497 526 flags: nhsync, nvsync; type: preferred, driver
props:
1 EDID:
flags: immutable blob
blobs:
value: 2 DPMS:
flags: enum
enums: On=0 Standby=1 Suspend=2 Off=3
value: 0
12 11 connected unknown 0x0 1 11 -----------> FPDLink
modes:
name refresh (Hz) hdisp hss hse htot vdisp vss vse vtot)
1280x800 57 1280 1312 1360 1440 800 804 807 814 flags: nhsync, nvsync; type: preferred, driver
props:
1 EDID:
flags: immutable blob
blobs:
value: 2 DPMS:
flags: enum
enums: On=0 Standby=1 Suspend=2 Off=3
value: 0
Gsttestplayer
gsttestplayer is a gstreamer test application useful for testing some features not testable with gst-launch such as:
- Seek - Seeking to random points in a stream
- Trick play - Playback at different speeds (fast forward, rewind)
- Pause, Resume
- Playing multiple streams simultaneously in the same process, in a loop or one after another.
Running gsttestplayer
Command line options:
target # gsttestplayer -h
Usage: gsttestplayer <options>
-s <sinkname> Specify the video sink name to be used, default: kmssink
-n Do not use VPE, implies no scaling
-r <width>x<height> Resize the output to widthxheight, no scaling if left blank
-a Play with no A/V Sync
-c <cmds file> Non-interactive mode, reading commands from <cmds file>
--help-gst Show GStreamer Options
Example: To use waylandsink and resize the output video to 800x400.
target # gsttestplayer -s waylandsink -r 800x400
In normal mode, when -c option is not used, the application enters an command prompt at which the user enter various commands. Type "help" to print out the list of possible commands:
target # gsttestplayer -s waylandsink -r 800x400
Scaling output to 800x400
Using videosink=waylandsink
<Enter ip> help
Commands available:
start <instance num> <filename>
stop <instance num>
pause <instance num>
resume <instance num>
seek <instance num> <seek to time in seconds> <optional: playback speed>
sleep <sleep time in seconds>
rewind <line number> <rewind command file go to line number>
exit
<Enter ip>
Example commands:
start 0 KMS_MPEG4_D1.MP4 # Start playing the file "KMS_MPEG4_D1.MP4", using instance 0.
start 1 NTSC_h264.mp4 # Start playing the file "NTSC_h264.mp4" (simultaneously) using instance 1.
stop 0 # Stop playback of instance 0.
seek 0 0 2 # Seek to "0"th second mark of the stream playing in instance 0,
# and start playing back at speed 2x.
seek 0 300 -1 # Seek to "300"th second mark of the stream playing in instance 0,
# and start playing back reserve at speed 1x.
All these commands could be put into a text file and given as input to gsttestplayer with the "-c" option. In this case, gsttestplayer runs non-interactively, reading commands from the text file one line after another. The commands sleep and rewind are useful for this mode, to introduce delays or to create a loop respectively.
Notes:
- This application plays video only. Audio path is not used.
- The input filename should have the correct file extension to indicate the type of file. The supported extensions are "mp4", "avi", "ts", "asf" & "wmv".
- The input filename should contain the string "264", "mpeg2", "mpeg4" or "vc1"/"wmv" to indicate which video codec should be used for decoding - H.264, MPEG-2, MPEG-4 or Windows Media Video.
Booting EVM with different modes
Supported Boot modes
The same U-Boot image shipped with the SDK can be used to boot the system in following different modes based on the boot switch settings:
- MMC/SD
- eMMC
- Uart
- QSPI
- NAND
Using QSPI Boot
QSPI is a serial peripheral interface like SPI the major difference being the support for Quad read, uses 4 data lines for read compared to 2 lines used by the traditional SPI.
Supported boot modes
- QSPI Production Boot mode
- QSPI Development Boot mode
QSPI Production Boot Mode
This boot mode also called as 'spl_early_boot' in GLSDK
- In this boot mode SPL(first stage of Uboot) directly boots the Linux kernel and if IPU late attach is enabled, it boots the IPU slave core
- The executables - MLO, DRA7-EVM.dtb, uImage & IPU are stored in QSPI flash memory. Refer the "Memory Layout" section for offset details.
- eMMC partition 2 contains the filesystem & is mounted as rootfs.
SYS BOOT Switch Settings
change the boot switches to QSPI boot mode as:
SW2[5:0] = 110110 Also SW5.4 = 0 (OFF)
Memory Layout of QSPI Flash
+----------------+ 0x00000 | MLO | | | +----------------+ 0x020000 | u-boot.img | | | +----------------+ 0x090000 | DRA7-evm.dtb | +----------------+ 0x100000 | | | uImage | | | | | +----------------+ 0x700000 | | | IPU exe | | | +----------------+
Add choosen node in DTSI file
In 'spl_early_boot' mode the kernel boot arguments are get passed through DTB 'chosen' node. Add a 'chosen' node into dra7.dtsi file and generate the DRA7-evm.dtb file.
chosen
{
bootargs = "elevator=noop console=ttyO0,115200n8 root=/dev/mmcblk0p2 rw rootwait earlyprintk fixrtc omapdrm.num_crtc=2
consoleblank=0";
};
Flashing the Image to QSPI from linux
Unzip the mk-qspi-boot.sh from mk-qspi-boot.zip
mk-qspi-boot.sh runs on the target . It reads the executables from MMC/SD & flashes into QSPI flash memory for 'spl_early_boot'. Also format & flash the rootfs into eMMC parition 2.
Usage: target#mk-qspi-boot.sh --device1 --device2 --bootmode --device1 - devfs entry for qspi flash as char device node e.g /dev/mtd0 --device2 - devfs entry for eMMC flash as block device node e.g /dev/mmcblk1 --bootmode - 'spl_early_boot' & 'two_stage_boot' spl_early_boot - ROM=>SPL=>uImage two_stage_boot - ROM=>SPL=>u-boot.img=>uImage e.g target#: mk-qspi-boot.sh --device1 /dev/mtd0 --device2 /dev/mmcblk1 --bootmode spl_early_boot
QSPI Development Boot Mode
This boot mode also called as 'two_stage_boot' in GLSDK
- In this boot mode SPL(first stage of Uboot) brings-up u-boot.img(second part of u-boot) and if IPU late attach is enabled, it also boots the IPU slave core
- The second stage of u-boot, then, loads & boots the Linux kernel.
- Only MLO and u-boot.img are stored in QSPI flash memory.
- DTB & uImage are stored in MMC/SD boot parition.
- IPU executable is stored in <mmc_rootfs>/lib/firmware/dra7-ipu2-fw.xem4.
- The rootfs is mounted from MMC/SD partition 2
SYS BOOT Switch Settings
change the boot switches to QSPI boot mode as:
SW2[5:0] = 100110 Also, SW5.4 = 0 (OFF)
Flashing UBoot to QSPI from linux
mk-qspi-boot.sh script can be used to flash the MLO and u-boot.img file into QSPI flash memory.
Unzip the mk-qspi-boot.sh from mk-qspi-boot.zip
mk-qspi-boot.sh runs on the target . It reads the executables from MMC/SD & flashes into QSPI flash memory for 'two_stage_boot'
target#mk-qspi-boot.sh --device1 --device2 --bootmode --device1 - devfs entry for qspi flash as char device node e.g /dev/mtd0 --device2 - devfs entry for eMMC flash as block device node e.g /dev/mmcblk1 --bootmode - 'spl_early_boot' & 'two_stage_boot' spl_early_boot - ROM=>SPL=>uImage two_stage_boot - ROM=>SPL=>u-boot.img=>uImage e.g target#: mk-qspi-boot.sh --device1 /dev/mtd0 --device2 /dev/mmcblk1 --bootmode two_stage_boot
Also QSPI flash can be accessed from kernel through MTD device.
Following commands demonstrate how to flash MLO and u-boot from SD card to QSPI.
target# mount /dev/mmcblk0p1 /mnt
target# cat /proc/mtd
target# flash_erase -N /dev/mtd0 0 10
target# mtd_debug write /dev/mtd0 0x0 $(ls -l /mnt/MLO {{!}} awk '{ print $5 }') /mnt/MLO
target# mtd_debug write /dev/mtd0 0x20000 $(ls -l /mnt/u-boot.img {{!}} awk '{ print $5 }') /mnt/u-boot.img
Flashing UBoot to QSPI from UBoot
UBoot can be flashed to QSPI from any boot mode, here we are using MMC boot mode as an example.
Boot from SD card and at the U-Boot prompt, Choose the mmc card to read from
uboot# mmc dev 0 uboot# mmc0 is current device
Load the MLO and u-boot.img to DDR
uboot#fatload mmc 0 0x82000000 MLO uboot#fatload mmc 0 0x83000000 u-boot.img
- Probe the flash to see if there is a device connected,
NOTE: Do NOT copy-paste the commands, please type them at the prompt
#sf probe 0 SF: Detected S25FL256S with page size 64 KiB, total 32 MiB, mapped at 5c000000
- Erase the flash before writing the bin
NOTE: Do NOT copy-paste the commands, please type them at the prompt
#sf erase <offset> <size> where, offset - qspi flash offset address start from 0. size - erase region size. It should be multiple of 64K
- Write MLO (to offset 0x0) and u-boot.img(to offset 0x20000) to the flash,
#sf write 0x82000000 0x0 0x10000 #sf write 0x83000000 0x20000 0x60000
After reset, you should be able to boot from QSPI flash.
NOTE: QSPI_4 boot mode is not supported on PG1.0.
Using eMMC Boot
eMMC boot method is the same as MMC/SD flashing and booting procedure. MMC/SD card must be formatted with the correct partitions prior to flashing any device. Once the MMC/SD is configured it will contain two separate partitions that will be used to boot the device. The FAT32 partition is used for uboot (MLO,u-boot.img,boot.scr, boot.scr.eMMC) and kernel (uImage, dtb file). The ext4 partitions is used for the actual file system. Once both of these are loaded onto an MMC/SD the device can boot up and run the selected file system
Boot switches for eMMC boot
change the boot switches for eMMC boot mode as:
SYSBOOT [0-15] (SW2[1-8],SW3[1-8]): 0100 0100 1000 0001
USERCONFIG[1-10] (SW5): 0010 1000 00 O - OFF 1 - ON
Partitioning and formatting eMMC
Using eMMC is similar to using SD card. eMMC is an Embedded device. So we have to partition and format the the eMMC using kernel utility(fdisk, mkfs.msdos, mkfs.ext4) and that available in FileSystem. To partition and format eMMC, use the following script
./mk-eMMC-boot.sh --device /dev/mmcblk1
Once done, remove MMC/SD & reboot the device.now board should boot from eMMC.
Using UART boot
The GLSDK release for DRA7xx does not support boot over UART out of the box. The purpose of this template is to provide details on how to add UART-boot support on top of GLSDK release.
Boot over UART is tested on a rev D DRA7xx EVM. The ROM code can boot from UART3. By default the EVM supports UART1. Hence it is mandatory to do a hardware change to work with UART-boot.
Hardware Changes for UART-boot support
Populate resistor R776 and R777 with 50 ohm resistor.
Serial port configuration
DRA7xx EVM comes with onboard USB-to-serial converter. The USB cable supplied with the EVM can be used to connect the EVM to a host. The mini-USB end of the cable should be connected to 'J1 Terminal' connector on the EVM.
For correct operation the serial terminal software should be configured with the following settings:
* Baud rate: 115200 * Data bits: 8 * Parity: None * Stop bits: 1 * Flow control: None * Transmit delay: 0 msec/char, 100 msec/line
NOTE: Ensure that version 4.67 or later of Teraterm is installed. The implementation of the kermit protocol in Teraterm is not reliable in older versions. The latest version of Teraterm can be downloaded from here.
Boot Switch Settings
SW2[5:0] = 010011
Other than this,
SW5.5 = OFF for UART3 support.
(Default = ON for UART1)
Note: Apart from this patch following changes should be taken note of: 1. dra7xx_evm_uart3_config should be used instead of dra7xx_evm_config while rebuilding u-boot. For this replace following line in GLSDK's Rules.make file: DEFAULT_UBOOT_CONFIG=dra7xx_evm_config to DEFAULT_UBOOT_CONFIG=dra7xx_evm_uart3_config 2. CONFIG_SPL_TEXT_BASE in include/configs/omap5_common.h should be manually changed from 0x40300350 to 0x40300000 for UART-boot. In memory boot mode ROM code transfers MLO to location OCMC_RAM1 base+offset (CONFIG_SPL_TEXT_BASE = 0x40300000+350). In peripheral boot mode ROM code transfers MLO to location OCMC_RAM1 base (0x40300000). UART-boot will not work without changing this address.
UART protocol used at various phases
ROM Code -> MLO :- binary transfer, UART3: 115.2 Kbps, 8 bits, even parity, 1 stop-bit, no flow control
MLO -> u-boot:- YModem protocol, UART3: 115.2 Kbps, 8 bits, none parity, 1 stop-bit, no flow control
u-boot -> Linux :- Kermit protocol, UART3: 115.2 Kbps, 8 bits, none parity, 1 stop-bit, no flow control
Software & Tools
The following software is needed:
- MLO & u-boot should be built for DRA7xx.
Note: For MLO use the spl/u-boot-spl.bin file. The difference between u-boot-spl.bin and MLO is that u-boot-spl.bin does not contain header information. Peripheral boot needs an MLO without header. For u-boot use u-boot.img file (and not u-boot.bin file)
- The serial-boot.pl script for transferring MLO.
Please note that this perl script is dependent on the perl Device::SerialPort module.
Perl can be downloaded from here. Let's say Perl is downloaded on Windows machine at location c:\perl.
For SerialPort module download following files from here to c:\perl
Win32-SerialPort-0.22-PPM510.tar.gz Win32-SerialPort-0.22-PPM512.tar.gz Win32-SerialPort-0.22-PPM514.tar.gz Win32-SerialPort-0.22-PPM516.tar.gz Win32-SerialPort-0.22-PPM56.tar.gz Win32-SerialPort-0.22-PPM58.tar.gz Win32-SerialPort.ppd
Open a cmd and cd c:\perl, run
ppm install Win32-SerialPort.ppd
- Teraterm on Windows machine.
Boot Over UART Procedure
Loading 1st state(MLO) over UART
1. Set boot mode switch SW2 and SW5.5 as per Boot_Switch_Settings
2. Switch ON EVM with UART boot mode.
3. Open Teraterm on Windows machine and set serial port to 115.2 Kbps, 8 bits, even parity, 1 stop-bit, no flow control
4. Ensure that “VA!” characters appear on TeraTerm window continuously
5. Close the teraterm window
6. Open cmd and execute the serial-boot.pl script as follows:
./serial-boot.pl -p <serial-device> -s <path>/u-boot-spl.bin
For example: ./serial-boot.pl -p com26 -s c:\temp\u-boot-spl.bin You can add debug option to see debug messages when running this script ./serial-boot.pl -p com26 -s c:\temp\u-boot-spl.bin -d 1
Note:- If the serial-boot.pl doesn't wait for you to reset the board and if it continues saying "Board Detected" let it continue (dont reset the board here) once done rerun the script
with the same paramaeters now it should actually wait for you to reset.
Note: serial-boot.pl script, after opening the COM port takes care of setting it to 115.2 Kbps, 8 bits, even parity, 1 stop-bit
7. The script will ask you to reset the EVM
8. Press "Reset button" on EVM to initiate image download
9. The download is completed when you see "Second file download completed" message.
10.After image is successfully downloaded, the ROM code will boot it.
11.MLO will then be waiting to receive u-boot over ymodem.
Note: You will NOT be able to see the MLO logs on console as teraterm is closed.
Loading 2nd stage(u-boot) over UART
The moment the serial script execution is over,
1. Open Teraterm
2. Choose File -> Transfer -> YModem -> Send
3. Select the 2nd stage u-boot image “u-boot.img” built earlier and click “OPEN” button
4. Wait for download to complete
5. u-boot will start its execution once download is completed
6. Interrupt the boot to get 2nd Stage u-boot prompt
DRA752 EVM#
Note: MLO waits to receive u-boot for maximum timeout period of 20sec. So do not fail to start u-boot transfer within 20 sec. The actual transfer of u-boot starts after ~4-5 secs of opening the u-boot.img file.
Loading dra7-evm.dtb over UART
1. Run following command on u-boot prompt
DRA752 EVM# loadb 0x825f0000
2. Choose File -> Transfer -> Kermit -> Send
3. Select "dra7-evm.dtb" click “OPEN” button
4. Wait for download to complete
Loading uImage over UART
1. Run following command on u-boot prompt
DRA752 EVM# loadb 0x80300000
2. Choose File -> Transfer -> Kermit -> Send
3. Select "uImage" click “OPEN” button
4. Wait for download to complete
5. You can check whether uImage is downloaded properly using
iminfo
Booting uImage
Run following command on u-boot prompt
setenv bootargs 'elevator=noop console=ttyO0,115200n8 root=/dev/mmcblk0p2 rw rootwait earlyprintk fixrtc' setenv fdt_high 0x84000000 bootm 0x80300000 - 0x825f0000
Note: Linux Kernel by default uses UART1 for console logs. In order to switch to UART3 as a default console use 'console=ttyO2' in the bootargs. e.g. setenv bootargs 'elevator=noop console=ttyO2,115200n8 root=/dev/mmcblk0p2 rw rootwait earlyprintk fixrtc' The final console where login prompt gets displayed is decided by the filesystem. Some filesystems read the default console being used while booting up(as in bootargs) and activate that as the final console. Some filesystems do not have this flexibility and will have a fixed final console, e.g. ttyO0. Based on the filesystem you use to boot the kernel, the login prompt will either get displayed directly or you will have to slide SW5.5=ON to see it.
Booting Secure DRA7xx Devices SD/eMMC
Note: This feature is applicable only for GLSDK 6.03 release onwards
The GLSDK u-boot supports booting the secure devices. In order to boot the secure DRA7xx devices, at minimum, the MLO binary must be signed and formatted properly with the necessary keys and certificates. If extended boot authentication is used, a special u-boot build is required and the u-boot.img, kernel and DTB files must also be signed. Signing is done using the IFT tools (contact local sales representative to get M-Shield-Dk/IFT tools). This process can be used with test secure (HS) devices with the TI dummey key. The sequence of authentication of images for HS devices as follows. The initial authentication is done by RM code and is required. The last 2 steps are optional and constitute extended secure boot authentication.
- ROM -> PKC – ROM code authenticates Public Key Certificate against Root eFuse key
- ROM -> PPA – ROM code authenticates Primary Protected Application and loads to secure RAM and executes
- ROM->MLO - ROM code loads and authenticates MLO
- MLO->u-boot - The MLO authenticate u-boot
- u-boot->kernel & dtb - The u-boot authenticates kernel and dtb file
In any stage if authentication fails, then device will enter a deadloop.
Install Mshield-DK
Install Mshield-DK tool and set the path to "MSHIELD_DK_DIR" environment variable corresponding to the version you installed (LITE, STD, for FULL).
#export MSHIELD_DK_DIR="${HOME}/omap-mshield-lite"
Signing MLO
Use the ift-sign-image.sh shell script to sign the MLO. This step is mandatory for secure devices and adds the Table of Contents (ToC), Signed Public Key Certificate (PKC) and signed PPA and formats the image as required. Note: you may have to edit this shell script to include appropriate key files(.pem) to sign the image.
#${GLSDK}/bin/ift-sign-image.sh -mlo -dra7xx
This command will use spl/u-boot-spl.bin and create signed MLO.
Copy MLO to SD boot partition.
#cp MLO /media/boot/
Building u-boot for extended authentication of secure devices
The defconfig "dra7xx_evm_hs" is used to compile the u-boot. Use below command to compile u-boot binaries
#make ARCH=arm CROSS_COMPILE=arm-arago-linux-gnueabihf- distclean #make ARCH=arm CROSS_COMPILE=arm-arago-linux-gnueabihf- dra7xx_evm_hs
When using the instructions above, a modified version of u-boot(u-boot.img.signed)is build that will authenticate the kernel and dtb and, in addition, the u-boot.img.that is created will be signed. By default, the key with ISW signing rights will also be used to sign the uboot image as well as the kernel and dtb. If you want to use a different key from the PKC, please modify the makefile and scripts accordingly.
Copy u-boot.img.signed (rename to u-boot.img) to SD boot partition.
#cp u-boot.img.signed /media/boot/u-boot.img
Signing kernel images & dtb for secure devices
After the kernel is built, issue the below command to sign the kernel image (zImage) and dra7-evm.dtb file. The shell script will use zImage to create signed uImage.
#${GLSDK}/bin/ift-sign-image.sh -kernel arch/arm/boot/zImage
The uImage.signed will be created in the current directory.
#${GLSDK}/bin/ift-sign-image.sh -dtb arch/arm/boot/dts/dra7-evm.dtb
The arch/arm/boot/dts/dra7-evm.dtb.signed will be created.
copy the signed images to SD boot partition
#cp uImage.signed /media/boot/uImage #cp dra7-evm.dtb.signed /media/boot/dra7-evm.dtb
booting the HS device
Insert the sd card to secure dra7xx(HS) EVM and reset the board. If the board is not booting then check signing procedure and make sure right keys (.pem) for the HS device is used
USB DRD (Dual Role Device) Support
The GLSDK kernel (6.04.x onwards) supports DRD feature, Where USB ports has capable of switching between device mode or host mode dynamically based on the usb cable type connected.
- If host-type (A-type) usb cable is connected, the port switched to host mode.
- If device-type (B-type) usb cable is connected, the port switched to device mode.
Refer DRD support for more information.
Using the Late attach functionality
This feature is supported from 6.04 release onwards. For some specific use cases, one would need the remote core booted up early enough at the boot loader itself and then kernel attaches with the already booted remote core for further communication. This functionality is added at u-boot and kernel and is defined under the config which is disabled by default.
By default the config is for IPU2, enable the configs at the u-boot and kernel to use the functionality. For information on how to enable the functionality for IPU2 or IPU1 and more information regarding the late attach, kindly refer to the link Early Boot and Late attach
Note: - Please make sure that you have the enabled the functionality of the for the same remotecore at both kernel and u-boot. - Please make sure the elf binary for the remote core in the specific media i.e MMC or QSPI in the current code base for the u-boot and in the filesystem at location /lib/firmware for the kernel to late attach to the core.
Running a MessageQ example to use the late attach functionality:
To run the MessageQ example using the late attach functionality, follow the following steps:
- Enable the late attach for core that you want to use i.e IPU1 or IPU2. Follow the steps as mentioned in the link above to build the u-boot and kernel imaged with the late attach configuration enabled for one of the core.
- Build the messageq binaries by:
host $ make ipc_ipu
- Copy the messageq single binary from the location "$GLSDK/component-sources/ipc_3_21_00_07/packages/ti/ipc/tests/bin/ti_platforms_evmDRA7XX_ipuX/messageq_single.xem4 (X=1 or 2) to the boot partition and rootfs partition (/lib/firmware) as dra7-ipuX-fw.xem4 (X = 1 or 2) depending upon the core.
- Boot the board with these images and run the following command to test the communication:
target # lad_dra7xx target # MessageQApp <num_loops> <core-id> (core-id = 1 (for IPU2) and 2 (for IPU1))
eg: MessageQApp 10 2
Using the Early video decode example
The early video decode example is an IPU based application that would do a video decode and display as soon as the boot loader loads the IPU. This is for demo purpose and patches could be downloaded here.
The package contains patches over the u-boot and ipumm multimedia binary. The patches are over the 6_04_00_02 release.
- u-boot patches: Apply the patch in the u-boot folder of the package over the boot loader directory in $GLSDK/board-support/u-boot. Build the u-boot from the GLSDK release package:
host $ make u-boot
Please make sure, the corresponding flag for enabling the IPU2 late attach feature at the kernel as described in the link Early Boot and Late attach is done and build the kernel image.
- ipumm patches: Apply the patch in the ipumm_3_00_03_04 folder of the package over the boot loader directory in $GLSDK/component-sources/ipumm_3_00_03_04. Build the ipumm from the GLSDK release package:
host $ make ipumm
Copy the elf binary dra7xx-m4-ipu2.xem4 and copy it the boot partition of the SD card and rename it to dra7-ipu2-fw.xem4 and /lib/firmware directory of the filesystem.
Once the boot corresponding images for u-boot, uImage and ipumm are copied, boot the board. There would be a color bar frame that would be displayed on the LCD attached to the board for some time, until the kernel comes up and reinitialize the DSS to be used by it.
The app currently starts the decoding and displays a single frame of resolution 800x480. The DSS initialization is done currently for this resolution.
Note: Currently, there is an issue that is there with the multimedia image when booted in the manner as described above, where once the full system is up and you are running multiple iterations of multimedia decode, there is a corruption happening due to which IPU2 becomes unresponsive.
Changing MPU Frequency (DVFS)
DRA7xx supports running MPU (CPU0/1) at more than one frequency.
User may chose to run at different frequencies based on performance requirements for the application/use-case targeted.
The Data Manual contains all the frequencies supported by the Hardware and the GLSDK Datasheet available with current release contains details of supported frequencies in the Software.
Please refer to the following wiki for details on how to change CPU frequency and voltage DVFS UserGuide
Additional Procedures
Build Environment Setup
NOTE: From this release, each component i.e kernel, u-boot or any userspace application should be cross-compiled
Cross Compiler setup
The cross compiler setup for the Rules.make is done as a part of the setup.sh script in the GLSDK folder. The script for cross compiler ensures that the linaro cross compiler toolchain is installed in the ${HOME} (or user specified) folder of the host machine.
Note:Please ensure that the PATH variable is set in your machine to point to the cross compiler setup.
To compile the code (if not using the top level Makefile to build kernel and u-boot), please ensure the environment variables ARCH and CROSS_COMPILE is set to arm and to the linaro cross compiler path respectively.
Rebuilding the GLSDK components
The GLSDK has provided a top level Makefile to allow the re-building of the various components within the GLSDK.
Rebuild the GLSDK components by first entering the GLSDK directory using:
host $ cd ${GLSDK}
The GLSDK makefile has a number of build targets which allows you to rebuild the GLSDK components. For a complete list execute:
host $ make help
After that, each of the build targets listed by 'make help' can then be executed using:
host $ make <target>_clean host $ make <target> host $ make <target>_install
For example, to compile the Linux Kernel, you can use the following commands
host $ make linux_clean host $ make linux host $ make linux_install
In order to install the resulting binaries on your target, execute one of the "install" targets. Where the binaries are copied is controlled by the EXEC_DIR variable in ${GLSDK}/Rules.make. By default, this variable is set up to point to your NFS mounted target file system when you execute the GLSDK setup (setup.sh) script, but can be manually changed to fit your needs.
You can remove all components generated files at any time using:
host $ make clean
And you can rebuild all components using:
host $ make all
You can then install all the resulting target files using:
host $ make install
Creating your own Linux kernel image
The pre-built Linux kernel image (uImage) provided with the GLSDK is compiled with a default configuration. You may want to change this configuration for your application, or even alter the kernel source itself. This section shows you how to recompile the Linux kernel provided with the GLSDK, and shows you how to boot it instead of the default Linux kernel image.
1. If you haven't already done so, follow the instructions in #Setting_up_the_GLSDK to setup your build environment.
2. Recompile the kernel provided with the GLSDK by executing the following:
host $ cd ${GLSDK}
host $ make linux_clean
host $ make linux
host $ make linux_install
3. You will need a way for the boot loader (u-boot) to be able to reach your new uImage. Copy the new uImage that is generated in arch/arm/boot/ directory to the boot filesystem
4. Copy the exported Linux kernel modules from the EXEC_DIR to the /lib/modules directory to the root file system
Setting up Tera Term
Tera Term is a commonly used terminal program on Windows. If you prefer to use it instead of Minicom, you can follow these steps to set it up.
1. Download Tera Term from this location, and start the application.
2. In the menu select Setup->General... and set:
Default port: COM1
3. In the menu select Setup->Serial Port... and set the following:
Port: COM1 Baud rate: 115200 Data: 8 bits Parity: none Stop: 1 bit Flow control: none
NOTE: Kernel Bootargs can be generated by running the setup script. See the section #Setting_up_the_GLSDK for details on running the setup script.
Download the Latest GLSDK
The latest GLSDK is available for download from https://software-dl.ti.com/dsps/dsps_public_sw/glsdk/latest/index_FDS.html.
The current version is 6_10_00_02.
|
For technical support please post your questions at http://e2e.ti.com. Please post only comments about the article DRA7xx GLSDK Software Developers Guide here. |
