Getting Started Guide for AM572X EVM
Contents
Introduction
On this page you are going to find all the necessary information to start from scratch to use the RidgeRun SDK on your AM572X evaluation module (EVM). In the following sections we assume that you have already downloaded the Processor SDK version 02.00.02.11 and that you have installed the Linaro Toolchain 5.2-2015-2 version from Linaro.
The first section of this guide shows you how to install the Processor SDK for AM572X on your computer and how to configure a NFS server. Subsequently, the second section contains instructions about how to configure the RidgeRun's SDK to create a SD card with all software components (uboot, kernel and filesystem) needed to boot to Linux Shell in your EVM. Using this board with SD card booting mode in the third section of this guide, you will be able to deploy images created by the SDK for kernel, uboot as well as your filesystem (SD card and NFS File systems are available). Deploying the SD-card with the built images is so easy and automated, thanks to RidgeRun's OpendFD based installer.
Features Supported by the SDK
- U-boot-2015.07 supported
- Linux kernel 4.1.18
- Linaro Toolchain 5.2-2015-2 version
- Processor SDK integrated in a user friendly build system:
- Video Decode: H264, MPEG4, MPEG2, and VC1
- Video Encode: H264, and MPEG4
- Image Decode: JPEG
- Image Encode: JPEG (IPU custom firmware and ducatijpegenc element)
- Video decoding on ARM: H.265
- Audio encoding and decoding on ARM: AAC, MPEG2 (leveraging open source codecs)
- VPE (supports video operations such as scaling, color space conversion, and de-interlacing)
- Supported Input formats: NV12, YUYV, YUY2
- Supported Output formats: NV12, YUYV, YUY2
- Generic Linux SDK (GLSDK) 7.04.00.03 for DRA7XX integration:
- PRU-ICSS Build Enviroment support for developing
- DSP Build Environment support for developing
- IPU Firmware Build Environment support for developing
- GStreamer 1.8.1 version support
- SD, NFS filesystem support
- Boot methods: SD card and EMMC
- Many open source applications available like: QT, net-snmp, GStreamer, Busybox, etc
- RidgeRun services for integration of graphic acceleration technology with open source software stacks
- Ubuntu 14.04 and 15.04
Basic preliminary work
Please skip below two steps (2.1 and 2.2) and jump to 2.3 if you purchased a Professional SDK.
Getting the RidgeRun's EVAL SDK Irazu
If you want to get the RidgeRun's EVAL SDK Irazu you need to go to our Evaluation SDK Download Link and select the Evaluation SDK you need. You will be asked for your email address and some information. Once you have submitted the required information you will receive an email with the following information:
Sequence of evaluation sdk download events:
You have to follow the steps below :
When you select and click on the name of evaluation sdk you want to download, shopping cart page will display with the price $0.00 (for eval sdk's)
-> click on 'Go to Checkout'. It will display 'Your Shopping Bag' page
-> click on 'Checkout'. You will get a form to enter your email id and other info
-> click on 'Continue'. It will display a 'Place Order' page
-> click on 'Place Order'. And then Please check your email with a link to download the tar file for the evaluation SDK you have selected.
Installing the EVAL SDK version
RidgeRun delivers the SDK in either two ways: a tar file for x86 platforms, or for customers with a established development relationship through a custom SCM (typically GIT) repository. If you are using a shared SCM repository, please contact RidgeRun for a detailed instructions.
System Requirements
Listed below are the minimum recommended requirements for installing and using the RidgeRun SDK:
- A host computer with a 686 or better family processor
- 1 GB free hard disk space
- A Linux distribution configured on the host computer.
- Target hardware for the SDK
- Optional: a network card installed and configured on the host computer
- Optional: Internet connection for SDK updates
Once you have downloaded the tar file of the evaluation SDK you can untar it by running the following command:
tar -xvzf <name of the tar file downloaded>.tar.gz
You may find it convenient to untar the evaluation SDK more than once. For example, you might want one version to be unmodified and another version to be your working development directory. RidgeRun suggests you untar the SDK development directories in your $HOME/work/ directory. When you have more than one development directory installed, just remember to have the DEVDIR shell variable set properly. To set the DEVDIR shell variable use the `make env` command specified at RidgeRun_Irazu_SDK_User_Guide#Build_SDK
On the rest of this document, we refer as $DEVDIR to the path where the RidgeRun Eval SDK for TI AM572X is installed.
Installing the Professional SDK version
When all the purchase process is done, RidgeRun will provide you a GitHub repository access. For that, the GitHub user ID and other information might be requested. Once you provide that information, you must clone the given repository URL, using the next command:
git clone git@github.com:RidgeRun/<customer>.git
This would have the proper <customer> space modified. With this, you will have the SDK installed on the directory you were when executed the clone command.
RidgeRun suggests you install the SDK development directories in your $HOME/work/ directory. When you have more than one development directory installed, just remember to have the DEVDIR shell variable set properly. To set the DEVDIR shell variable use the `make env` command specified at RidgeRun_Irazu_SDK_User_Guide#Build_SDK
On the rest of this document, we refer as $DEVDIR to the path where the RidgeRun Professional SDK for TI AM572X is installed.
Installing the Processor SDK
1. Set the Processor SDK binary as executable and set correct permissions
sudo chmod 777 ti-processor-sdk-linux-am57xx-evm-02.00.02.11-Linux-x86-Install.bin
2. Install the Processor SDK:
You need to install it in your HOME directory ./ti-processor-sdk-linux-am57xx-evm-02.00.02.11-Linux-x86-Install.bin
The TI Product SDK uses an older custom version of Linaro Toolchain (4.9) if you want to build something using their own build system. RidgeRun SDK for AM572X uses a newer available version (5.2-2015-2).
Setting up serial access to the Linux console
You use the serial port to control u-boot and Linux. The picocom terminal emulator work well for this purpose.
Setting up an NFS server
For application development, it is convenient to use root NFS mount file system for the target hardware. This allows you to rebuild your application on the host and immediately run the application on the target hardware with no interveining steps. You host PC needs to be configured as a NFS server for this in order to work properly.
Booting from SD card
Setting up your EVM to boot from SD card
The AM572x boot mode sequence is selected via three jumpers on the board (J3, J4, J6).
There are three boot mode options (described below) supported by this board.
OPTION 1 Boot Order:
- SD Boot: This mode will boot from the microSD slot. It can be used to override what is on the eMMC device or to program the eMMC when used in the manufacturing process or for field updates.
- eMMC Boot: This is the default boot mode, if the microSD is NOT inserted, and will allow for the fastest boot time.
OPTION 2 Boot Order:
- UART Boot: The EVM is hardwired to boot from UART3 in this mode. Note the Linux debug serial boot also uses this same UART port and pinmuxing.
OPTION 3 Boot Order:
- SATA Boot: This mode will boot from the eSATA connector. This mode can be used to override what is on the microSD.
- SD Boot: This mode will boot from the microSD slot.
For the moment the RR-SDK for AM572X only supports OPTION 1 (SD card and eMMC boot). In order to boot from a SD card or eMMC you need to set the 3 jumpers as close as possible to the edge of the board, as shown on Fig.1.
Configuring SDK to deploy firmware to a SD card
This section describes how to configure the AM572X RR-SDK to deploy all basic firmware components (kernel, device tree "dtb", uboot and MLO) into a bootable SD card. The RidgeRun SDK support several filesystem types (SD card and NFS) however in this case we are going to show the example using it on the SD card as well. To use file system via NFS, you only need to change the option in the file system configuration option of the RidgeRun SDK configuration menu.
1. Set your environment variables
cd $DEVDIR `make env`
2. Open a make config menu
make config
running make config your SDK is going to download all basic packages needed by the SDK build 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. Please select Deploy all the firmware to an SD card.
- 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.
5. Compile your SDK
On your $DEVDIR run: make
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 to issue this command you need to unmount your SD card, otherwise the SDK won't let you install it (in order to avoid to erase information in some of your hard disks). Let's suppose that the environment variable called $SDNAME contains your mount point's 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, device tree "dtb", uboot and MLO image and the rootfs partition with your 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.
Booting from eMMC
Setting up your EVM to boot from eMMC
To set your AM5728 EVM to boot from eMMC, you have to select boot jumper configuration option number 1 (as described in the previous section). The jumper configuration to boot from eMMC is the same as SD card boot. The eMMC memory works exactly as an SD Card, the only difference is that this memory is on board, that is the reason why the configuration of both boot methods is so similar.
In the booting process the board will first check if there is an SD card, and tries to boot from it. If no SD card is detected or it hasn't a bootable image, the board will check the eMMC memory in search of a bootable image and boots from it.
Configuring and installing SDK to deploy firmware to eMMC
This section describes how to configure the AM572X RR-SDK to deploy all basic firmware components (kernel, device tree "dtb", uboot and MLO) into a bootable SD card image to flash the eMMC. The RidgeRun SDK support several filesystem types (SD card and NFS) however in this case we are going to show the example using it on the SD card as well. To use file system via NFS, you only need to change the option in the file system configuration option of the RidgeRun SDK configuration menu.
The RidgeRun SDK generates an sdcard.img file that contains a complete bootable system image accordingly to the configurations you selected for the image going to be installed in the eMMC. Then the user has to manually copy the sdcard.img file in the File System directory. After doing that, the user should create a normal SDK image configured to boot from SD card. Finally, you boot the board with the SDK image burned to the SD card, wait until it finish to boot, load kernel and file system; and then run the usr/scripts/eMMC_flasher script. The detailed steps are going to be shown below.
1. Set your environment variables
cd $DEVDIR `make env`
2. Open a make config menu
make config
running make config your SDK is going to download all basic packages needed by the SDK build system.
3. Go to Installer Configuration submenu and configure your installer as is shown in Fig.4
Using the Firmware deployment mode submenu you can set how to deploy your kernel, uboot and filesystem image into your target board. Please select Deploy all the firmware to an SD card.
- 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
- Flash SD card image into loopback file instead of real SD: Be sure that this option is enabled. It generates the sdcard.img file with the image going to be installed in the eMMC.
- Flas SD card image to eMMC: Be sure that this option is enabled. It configures the sdcard.img file to support eMMC installation.
5. Compile and install your SDK for eMMC installation
On your $DEVDIR runs: make make install
6. Once you have built your SDK, you need to manually copy the $DEVDIR/images/sdcard.img file to $DEVDIR/fs/fs.
On your $DEVDIR runs: cp images/sdcard.img fs/fs
7. Creating an SDK image configured with SD card boot method. Follow the steps of the previous section (Booting from SD card)
8. Boot your board, wait until it finished to boot and load Kernel and File System. Then, as logged into the board, run the /usr/scripts/eMMC_flasher script and follow the steps it shows. The output of the script is shown bellow:
/ # cd usr/scripts/ /usr/scripts # ./eMMC_flasher eMMC Flasher Flashing sdcard.img to eMMC ... After the eMMC flash is done, the board will shutdown. Please remove the SDcard and turn on the board again to check if the board boots correctly from eMMC. 512+0 records in 512+0 records out 536870912 bytes (512.0MB) copied, 50.015676 seconds, 10.2MB/s eMMC image flashing is done! !!!! The board is going to shutdown !!!! The system is going down NOW! Sent SIGTERM to all processes Terminated Requesting system poweroffses [ 72.705804] reboot: Power down
Now you are ready to test your SDK booting from eMMC. Two partitions were created by the SDK: boot partition which contains the kernel, device tree "dtb", uboot and MLO image and the rootfs partition with your file system.
Booting the board
First you have to plug-in into power your board, connect the USB to serial converter cable (to see board console in your host machine), connect the LCD touchscreen or any Display via HDMI port. Then turn on the board. If you want to compare your boot log to discard errors and be sure that your board running a RR-SDK built image is fine, follow this link to our AM572X-boot-info-log.
Hardware co-processors enabling
The Ridgerun SDK includes support for different co-processors available in AM572X EVM. Those co-processor are: Video Processor Engine (VPE), Video Input Port (VIP), Image Processor Unit (IPU), Digital Signal Processor (DSP) and Programmable Real-Time Unit Subsystem and Industrial Communication SubSystem (PRU-ICSS).
In order to enable those Co-processors hardware modules you need to follow this steps:
1.Open a make config menu
cd $DEVDIR make config
2. Go to the Proprietary software and enable the following packages:
3. Close the menu, save your configuration and build your SDK.
cd $DEVDIR make
4. Install your SDK in your board
make install
Testing audio
Audio Recording
To test the audio recording, alsa has a tool named arecord.
arecord audio.wav
Audio Playback
Alsa has a tool named aplay to test the audio playback.
aplay inputFile.wav
Please use a .wav audio file to test playback with aplay.
Using Gstreamer
We are in develop process to give support to Gstreamer plugins that make use of the hardware co-processors available in AM572X EVM. Those plugins will take out the profit of the IPU, VPE, IPU, IVA and DSP hardware modules in tasks such as capturing, encoding, decoding, processing, and displaying audio and video. This is ideal for heavy multimedia applications, because the hardware co-processor make all the heavy multimedia tasks, freeing the load of the principal Cortex A-15 Processors, so they can be used in other tasks.
Some examples of use of GStreamer to implement basic multimedia pipelines, and new developed pipelines and plugins announcements can be found at Gstreamer pipelines for AM572x.
Multimedia Performance Testbench
On this section you are going to find the results of a multimedia performance test-bench for AM5728 EVM. The test-bench was executed using an SO image built by AM5728 RR-SDK, with GStreamer 1.6.1 version. This test-bench is based on GStreamer pipelines, and evaluates different video and audio tasks. Go to AM5728 Multimedia Performance Testbench
PRU-ICSS modules
This section contains the procedure needed to rebuild PRU firmwares using the PRU examples provided by TI into ti-processor-sdk-linux-am57xx-evm-02.00.02.11. It is assumed that ti-processor-sdk-linux-am57xx-evm-02.00.02.11 is already installed on the host. if ti-processor-sdk-linux-am57xx-evm-02.00.02.11 is not installed, go to http://processors.wiki.ti.com/index.php/Processor_SDK_Linux_Installer
This procedure also include how to load the PRU firmwares on target and how to run some examples using PRU coprocessors.
When the user boots the board it automatically loads the PRUSS rpmsg and remoteproc drivers, and PRU firmware. The AM5728 RR-SDK includes the Texas Instruments prebuilt PRU firmware files. If the user wants to load their own firmware, just need to change the symbolic links as describe in previous sections (Load PRU Firmware on target), and reboot the board. For more information about rebuild your own PRU firmware, please email to us at inquiries@ridgerun.com or submit your Inquiry at RidgeRun Contact Us Link.
PRU Firmware loading during boot process
Boot log output re;ated with PRU firmware:
[ 28.114147] pruss-rproc 4b200000.pruss: creating platform devices for PRU cores [ 28.123038] pruss-rproc 4b280000.pruss: creating platform devices for PRU cores [ 37.139945] remoteproc4: 4b234000.pru0 is available [ 37.144969] remoteproc4: Note: remoteproc is still under development and considered experimental. [ 37.153994] remoteproc4: THE BINARY FORMAT IS NOT YET FINALIZED, and backward compatibility isn't yet guaranteed. [ 37.168497] remoteproc4: registered virtio0 (type 7) [ 37.173658] pru-rproc 4b234000.pru0: PRU rproc node /ocp/pruss@4b200000/pru0@4b234000 probed successfully [ 37.183525] remoteproc5: 4b238000.pru1 is available [ 37.188566] remoteproc5: Note: remoteproc is still under development and considered experimental. [ 37.197616] remoteproc5: THE BINARY FORMAT IS NOT YET FINALIZED, and backward compatibility isn't yet guaranteed. [ 37.215059] remoteproc5: registered virtio1 (type 7) [ 37.220242] pru-rproc 4b238000.pru1: PRU rproc node /ocp/pruss@4b200000/pru1@4b238000 probed successfully [ 37.230194] remoteproc6: 4b2b4000.pru0 is available [ 37.231376] remoteproc4: powering up 4b234000.pru0 [ 37.240236] remoteproc6: Note: remoteproc is still under development and considered experimental. [ 37.240408] remoteproc4: Booting fw image am57xx-pru1_0-fw, size 79832 [ 37.240451] pruss-rproc 4b200000.pruss: configured system_events = 0x1000000000000000 intr_channels = 0x00000001 host_intr = 0x00000001 [ 37.240456] remoteproc4: remote processor 4b234000.pru0 is now up [ 37.240608] virtio_rpmsg_bus virtio0: rpmsg host is online [ 37.240742] remoteproc5: powering up 4b238000.pru1 [ 37.249460] remoteproc5: Booting fw image am57xx-pru1_1-fw, size 79840 [ 37.249497] pruss-rproc 4b200000.pruss: configured system_events = 0x0800000000000000 intr_channels = 0x00000002 host_intr = 0x00000002 [ 37.249501] remoteproc5: remote processor 4b238000.pru1 is now up [ 37.249626] virtio_rpmsg_bus virtio1: rpmsg host is online [ 37.315428] remoteproc6: THE BINARY FORMAT IS NOT YET FINALIZED, and backward compatibility isn't yet guaranteed. [ 37.325927] virtio_rpmsg_bus virtio0: creating channel rpmsg-pru addr 0x1e [ 37.333009] virtio_rpmsg_bus virtio1: creating channel rpmsg-pru addr 0x1f [ 37.344201] remoteproc6: powering up 4b2b4000.pru0 [ 37.349136] remoteproc6: Booting fw image am57xx-pru2_0-fw, size 79832 [ 37.355811] pruss-rproc 4b280000.pruss: configured system_events = 0x1000000000000000 intr_channels = 0x00000001 host_intr = 0x00000001 [ 37.368063] remoteproc6: remote processor 4b2b4000.pru0 is now up [ 37.374405] virtio_rpmsg_bus virtio2: rpmsg host is online [ 37.379954] remoteproc6: registered virtio2 (type 7) [ 37.385072] pru-rproc 4b2b4000.pru0: PRU rproc node /ocp/pruss@4b280000/pru0@4b2b4000 probed successfully [ 37.385095] virtio_rpmsg_bus virtio2: creating channel rpmsg-pru addr 0x20 [ 37.401860] remoteproc7: 4b2b8000.pru1 is available [ 37.406848] remoteproc7: Note: remoteproc is still under development and considered experimental. [ 37.415857] remoteproc7: THE BINARY FORMAT IS NOT YET FINALIZED, and backward compatibility isn't yet guaranteed. [ 37.429758] remoteproc7: powering up 4b2b8000.pru1 [ 37.434658] remoteproc7: Booting fw image am57xx-pru2_1-fw, size 79840 [ 37.441348] pruss-rproc 4b280000.pruss: configured system_events = 0x0800000000000000 intr_channels = 0x00000002 host_intr = 0x00000002 [ 37.453581] remoteproc7: remote processor 4b2b8000.pru1 is now up [ 37.459857] virtio_rpmsg_bus virtio3: rpmsg host is online [ 37.459880] virtio_rpmsg_bus virtio3: creating channel rpmsg-pru addr 0x21 [ 37.472286] remoteproc7: registered virtio3 (type 7) [ 37.477378] pru-rproc 4b2b8000.pru1: PRU rproc node /ocp/pruss@4b280000/pru1@4b2b8000 probed successfully [ 45.915847] rpmsg_pru rpmsg0: new rpmsg_pru device: /dev/rpmsg_pru30 [ 45.922498] rpmsg_pru rpmsg1: new rpmsg_pru device: /dev/rpmsg_pru31 [ 45.929086] rpmsg_pru rpmsg2: new rpmsg_pru device: /dev/rpmsg_pru32 [ 45.935641] rpmsg_pru rpmsg3: new rpmsg_pru device: /dev/rpmsg_pru33
PRU example on user-space
RidgeRun can provide a basic "Hello World" example in the AM5728 RR-SDK to test the functionality of the PRU-ICSS module. If you want more related information please contact us.
Run PRU example on target
You can run PRU example for each PRU individually:
PRU 0
rpmsg_pru_user_space_echo /dev/rpmsg_pru30
PRU 1
rpmsg_pru_user_space_echo /dev/rpmsg_pru31
PRU 2
rpmsg_pru_user_space_echo /dev/rpmsg_pru32
PRU 3
rpmsg_pru_user_space_echo /dev/rpmsg_pru33
Expected output:
Opened /dev/rpmsg_pru30, sending 100 messages Message 0: Sent to PRU Message 0 received from PRU:hello world! Message 1: Sent to PRU Message 1 received from PRU:hello world! Message 2: Sent to PRU Message 2 received from PRU:hello world! Message 3: Sent to PRU Message 3 received from PRU:hello world! ... Message 97: Sent to PRU Message 97 received from PRU:hello world! Message 98: Sent to PRU Message 98 received from PRU:hello world! Message 99: Sent to PRU Message 99 received from PRU:hello world! Received 100 messages, closing /dev/rpmsg_pru30
