Introduction

On this page you are going to find all the necessary information to start from scratch to use the RidgeRun SDK on your DM8168 Z3 module. In the following sections we assume that you have already downloaded the EZSDK version 5.05.02.00 and that you have installed the toolchain 2009q1-203 from codesourcery.

The first section of this guide shows you how to install the EZSDK for DM8168 on your computer and how to configure a TFTP and 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 Z3 hardware. Using this SD card in the third and fourth section of this guide, you will be able to install on NAND images created by the SDK for kernel, uboot as well as your filesystem (JFFS2, UBI, NFS are available). Using the SD card created on the second section to flash the SDK in your module is just an option because you could try to use the installer of the RidgeRun's SDK with the uboot version that is running by default in a new Z3 module, however, we cannot guaranty that it will work as we expect, hence, we recommend to use the SD card instead. Furthermore we describe how to enable the Graphics SDK support on the Professional SDK. Additionally, how to run opemax demos to encode and decode 1080p/h264 videos and some usefult pipelines using gstreamer + openMax to do live view, take snapshots and RTSP streaming are shown. The last section of this page contains useful information about two new commands added by RidgeRun in uboot in order to handle tarballs and do copies from NAND to NAND.

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 DM8168 Z3 RPS 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 DM8168 Z3 RPS is installed.

Installing the EZSDK

1. Set the ezsdk binary as executable and set correct permissions, by default the EZSDK is used in its default patch (your home directory), optionally you can install it /usr/local/

 sudo chmod 777 ezsdk_dm816x-evm_5_05_02_00_setuplinux

2. Install EZSDK. For ubuntu versions different than Ubuntu 11.04 64-bit you will need to add the --forcehost argument to install it:

 ./ezsdk_dm816x-evm_5_05_02_00_setuplinux --forcehost

OR You can try the installation under console mode

 ./ezsdk_dm816x-evm_5_05_02_00_setuplinux --forcehost --mode console

note: 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/

Configuring the bsp/mach symbolic link for Eval-SDK

The evaluation SDK for DM8168 supports Z3 and EVM platforms into the same SDK, so for choose one of them is necessary to run the next lines.

 # For an totally clean SDK #
    make config
    make coreconfig
    make

The coreconfig target will show the following option where you have to choice the mach-dm8168-z3:

   Selecting machine/board:
   1. mach-dm8168-z3
   2. mach-dm8168-tievm

OPTIONAL: Installing AAC encoder and MP3 Decoder

The DM81xx platforms have the ability to encode AAC-LC and decode MP3 on the DSP using openMax+gstreamer, however, these codecs are not in the EZSDK by default. The Ridgerun SDK for the DM8148/DM8168 has internal logic to integrate these codecs and generate a new DSP firmware if these codecs are installed properly in your host computer. This new DSP firmware will be automatically loaded by into the DSP during boot time.

1. Download the AAC-LC encoder from TI Web page, this is called AAC LC Encoder, Version 01.00.01.00

2. Download the MP3 decoder from TI Web page, this is called MP3 Decoder, Version 1.41.00.00

3. Install the AAC-LC encoder inside of your EZSDK directory, i.e, your destination directory MUST be /home/<user>/ti-ezsdk_dm816x-evm_5_05_02_00/component-sources/c674x_aaclcenc_01_00_01_00_elf. Please be sure that c674x_aaclcenc_01_00_01_00_elf is in your destination path.

 sudo chmod 777 c674x_aaclcenc_01_00_01_00_elf.bin
./c674x_aaclcenc_01_00_01_00_elf.bin

4. Install the MP3 decoder inside of your EZSDK directory, i.e, your destination directory must be something like /home/<user>/ti-ezsdk_dm816x-evm_5_05_02_00/component-sources/c674x_mp3dec_01_41_00_00_elf

 sudo chmod 777 c674x_mp3dec_01_41_00_00_elf.bin
./c674x_mp3dec_01_41_00_00_elf.bin

5. Open a make config menu and select the Support external AAC and MP3 audio codecs option over the Proprietary software category.

 cd <pathOfYourDevdir>
`make env`
 make config

Optional selection of external AAC and MP3 audio codecs support

note: If you built your SDK before to enable the audio support you need to remove the EZSDK tarball that were generated by the SDK in /opt/ridgerun/downloads thus the SDK will generate a new one including the audio codecs.

Please be sure that AAC encoder is correctly installed by checking it inside the default EZSDK installation folder:

ls /home/<user>/ti-ezsdk_dm816x-evm_5_05_02_00/component_sources/

c674x_aaclcenc_01_00_01_00_elf/ folder should be there with that exact name containing the encoder files. Then, be sure that EXTERNAL_AUDIO_CODECS_SUPPORT option is selected.

Please refer this FAQ section

** IMPORTANT:

We have also added a new option to the SDK configuration (under Professional SDK) that allows the user to load a pre-built DSP firmware which already contains the AAC encoder, so no building of the firmware is required.

To enable this feature, go to the config menu:

cd $DEVDIR
make config

Propietay software -->

(Unselect  EXTERNAL_AUDIO_CODECS_SUPPORT if it its selected)

Select EXTERNAL_PREBUILT_DSP_FIRMWARE

And then rebuild the SDK again:

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 Picocom - Ubuntu

Setting up a TFTP server

If you are planning to use the SDK's installer to install images generated by the SDK in NAND, installing a TFTP server you will speed up downloads to the target hardware by using TFTP.

Setting Up A Tftp Service

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.

Setting Up A NFS Service

Setting Up a termnet for telnet protocol

Setting up termnet - Ubuntu

Booting from a SD card

Setting up your Z3 module to boot from SD card

In order to boot from a SD card you need to set the MMC as the first boot device to try in the DM8168 boot sequence, this can be done configuring a correct BTMODE through the header called J20 in your Z3 module (see Fig. 1)

Figure 1. Header to control boot mode (SD card)

|  1   |   2  |  3   |  4   |  5   |  6   |  7   |  8   |
|short | open | open | open | open | open | open | open |

Note: Some micro SD cards used with adapters may not work, we advise to use a regular SD card instead.

Configuring SDK to deploy firmware to a SD card

This section describes how to configure the DM8168's SDK to deploy all basic firmware components (kernel, uboot and MLO) into a bootable SD card. The RidgeRun SDK support several filesystem types (JFFS2, UBIFS, NFS, etc) however in this case we are going to use it on the SD card as well.

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.

note: If your SDK has problems downloading some package please email to support@ridgerun.com

3. Go to Installer Configuration submenu and configure your installer as is shown in Fig.2

Figure 2. Installer configuration to deploy firmware to an SD card

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 your NAND from the SD card.

4. Go to File System Configuration submenu and configure your filesystem as is shown in Fig.3

Figure 3. File system configuration to use it on the SD‎

5. Compile your SDK

 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, 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 NAND

This section describes how to configure the DM8168's SDK to install the SDK's firmware in NAND as well as how to set up your Z3 module to boot from NAND. First, we are going to start flashing uboot in NAND using the SD card created in the above section, once uboot is running properly from NAND, we can start installing the kernel and finally your filesystem.

Configuring SDK to install firmware in NAND

1. Set your environment variables

 cd $(DEVDIR)
 `make env`

2. Open a make config menu

 make config

3. Go to Installer Configuration submenu and configure your installer as is shown in Fig.4

Figure 4. Installer configuration to deploy firmware in NAND

In this case, you must use the Attached board on communication port method, this will allow you to install all your firmware directly in nand by means of a serial port or by ethernet using a TFTP server. Here we are going to use a TFTP server and telnet as our communication method with the target board.

3.1 Go to the Communication method with the target board and select Telnet-serial adaptor

3.2 Configure the protocol to transfer images as TFTP

3.3 Set the IP address of your host machine in IP address of telnet-serial adaptor

3.4 Set the port number that you assigned in the telnet configuration file to the serial port where your Z3 module is connected in Network port of telnet-serial adaptor

4. Close the make config menu and save your changes.

Configuring your Filesystem type

The RidgeRun SDK for DM8168 Z3 RPS supports different filesystem types: UBIFS, JFFS, NFS and also as we mentioned before you can use it in your SD card as well. In this tutorial we are going to use UBI as our default filesystem.

1. Set your environment variables

 cd $(DEVDIR)
 `make env`

2. Open a make config menu

 make config

3. Go to the File System Configuration->File system image target and choose UBIFS volume. Please be sure that UBIFS sub-page size is set to 512.

4. Save your changes and compile your SDK

 make

Flashing uboot, kernel and filesystem in NAND

1.Boot the RidgeRun SDK using the SD card created in the first section of this guide and stop the uboot countdown. Close your Picocom, minicom or telnet session.

U-Boot 2010.06-dirty (Nov 20 2012 - 15:57:54)

DRAM:  1 GiB
Using default environment

Hit any key to stop autoboot:  0 
mmc0 is available
reading u-boot.bin

181500 bytes read
## Starting application at 0x80800000 ...


U-Boot 2010.06-dirty (Nov 20 2012 - 16:14:20)

TI8168-GP rev 2.0

ARM clk: 987MHz
DDR clk: 675MHz

I2C:   ready
DRAM:  1 GiB
NAND:  HW ECC BCH8 Selected
256 MiB
*** Warning - booting from SD, using default environment

Net:   <ethaddr> not set. Reading from E-fuse
Detected MACID:40:5f:c2:69:c7:5c
Ethernet PHY: GENERIC (x001cc914) @ 0x01
DaVinci EMAC
Hit any key to stop autoboot:  0 
Z3-DM8168-MOD#

2.Run make installbootloader to install uboot in NAND

 make installbootloader

There is a known issue running the make installbootloader command when your Z3 module is initially running uboot from a SD card, in this case you will see the following error once the installer has flashed your uboot in NAND:

  Ridgerun Linux SDK
  Board configuration: DM8168 Z3 Module
  Multi-core machine, using 6 out of 8 cores for building
 
  Installation system of uboot images over TFTP for host <yourIPaddress>
  Be sure u-boot is running on <yourIpAddress>:<yourTelnetPort> and no process (like termnet) is using it
  Press return to continue...

  Performing handshake with u-boot...

  Trying to identify NAND block size... detected 0x20000
  Trying to identify NAND Page size... detected 2048

  Loading upgrade bootloader...
    Uboot <= setenv bootcmd
    Uboot <= saveenv
  Configuring the network...
    Uboot <= setenv autoload no
    Uboot <= dhcp
    Uboot <= setenv serverip <yourTFTPServerIP>
    Uboot <= setenv autostart no
     cp -f $(DEVDIR)/images/bootloader /srv/tftp/bootloader.$(USER).$(DEVDIRNAME).dm8168
    Uboot <= tftp 0x82000000 bootloader.$(USER).$(DEVDIRNAME).dm8168
  Running upgrade bootloader...
    Uboot <= icache off
    Uboot => go 0x82000000

  Performing handshake with u-boot...

  Restoring previous bootcmd value
    Uboot <= setenv bootcmd 'if mmc init 0; then if run loadbootenv ; then run importbootenv ; if test -n ${uenvcmd} ; then run uenvcmd; fi ;fi ;else run nandboot;fi'
    Uboot <= saveenv
  Building UBOOT_MIN image for flash...
  Building U-boot image for flash...
  Loading UBOOT_MIN
  Configuring the network...
    Uboot <= setenv autoload no
    Uboot <= dhcp
    Uboot <= setenv serverip <yourTFTPServerIP>
    Uboot <= setenv autostart no
     cp -f $(DEVDIR)/images/u-boot.noxip.bin /srv/tftp/u-boot.noxip.bin.$(USER).$(DEVDIRNAME).dm8168
    Uboot <= tftp 0x82000000 u-boot.noxip.bin.$(USER).$(DEVDIRNAME).dm8168
  Erasing UBOOT_MIN flash space...
    Uboot <= nand erase 0x0 0x40000
    Uboot <= nandecc hw 2
    Uboot <= nand write 0x82000000 0x0 0x40000
    Uboot <= nandecc sw
  Loading U-Boot
  Configuring the network...
    Uboot <= setenv autoload no
    Uboot <= dhcp
    Uboot <= setenv serverip <yourTFTPServerIP>
    Uboot <= setenv autostart no
     cp -f $(DEVDIR)/images/bootloader.nandbin /srv/tftp/bootloader.nandbin.$(USER).$(DEVDIRNAME).dm8168
    Uboot <= tftp 0x82000000 bootloader.nandbin.$(USER).$(DEVDIRNAME).dm8168
  Erasing U-Boot flash space...
    Uboot <= nand erase 0x40000 0x40000
    Uboot <= nand write 0x82000000 0x40000 0x40000
  Restarting u-boot

  Error: failed to detect u-boot restarting.                                                             

make: *** [installbootloader] Error 255

However, uboot is flashed in nand properly. Please ignore this error, this will be fixed in the next release.

3.Turn off your Z3 module and configure it to boot from NAND (please see Setting up your Z3 module to boot from NAND). Turn on your module and repeat step 1.

4. Now, to install your kernel and filesytem run make install

 make install

Now you have installed all the SDK components in your DM8168 Z3 module and you should be able to boot to Linux shell and see the logo of RigeRun on the HDMI output. The RidgeRun SDK for DM8168 Z3 module loads automatically all the firmware and kernel modules needed to use the video processor subsystem.

Setting up your Z3 module to boot from NAND

In order to boot from a NAND you need to set it as the first boot device to try in the DM8168 boot sequence, this can be done configuring a correct BTMODE through the header called J20 in your Z3 module (see Fig. 5)

Figure 5. Header to control boot mode (NAND)

|  1   |   2  |   3   |  4   |   5   |  6   |  7   |   8   |
| open | open | short | open | short | open | open | short |

Introduction to NAND memories

If you are more interested on NAND concepts and what is supported on the DM816x please read Introduction to NAND memories

BOOTP Protocol Recovery Procedure

There is likely the case where the developer finds itself with a Z3 module with no carrier board or custom hardware part with a SD card slot available to perform a regular recovery procedure through SD card booting. In such case, it is possible to perform a recovery procedure through the Bootstrap Protocol (BOOTP) which is the basis for a more advanced network manager protocol, the Dynamic Host Configuration Protocol (DHCP).

For further information, please read DM8168_Z3_BOOTP_recovery_procedure

Graphics SDK - OpenGL - Qt

The Professional Ridgerun SDK includes Graphics SDK 4.04.00.02 completely integrated, supporting the SGX530 3D Graphics Engine through the PowerVR driver. It also includes support to use Qt to render through the PowerVR kernel module.

1. In order to enable the Graphics SDK in your SDK, please download and install in your home directory the Graphics SDK 4.04.00.02 from the TI web page

sudo chmod 777 Graphics_SDK_setuplinux_4_04_00_02.bin
./Graphics_SDK_setuplinux_4_04_00_02.bin

2.Then open a make config menu

cd $DEVDIR
make config

3. Go to the Proprietary software and enable the graphics SDK.

Figure 6. SDK boot log after enable the Graphics SDK

4. Go to File System Configuration -> Select target's file system software -> qt-4.7.2 and select Support openGL and its demo. Finally disable the option called Make QT as compact as possible.

5. Close the menu, save your configuration and build your SDK.

cd $DEVDIR
make

6. Install your SDK in your board

make install

7. Boot your board, you will see the following message

Starting System
done.
Welcome to
__________ .__     .___               __________                
\______   \|__|  __| _/  ____    ____ \______   \ __ __   ____  
 |       _/|  | / __ |  / ___\ _/ __ \ |       _/|  |  \ /    \ 
 |    |   \|  |/ /_/ | / /_/  >\  ___/ |    |   \|  |  /|   |  \
 |____|_  /|__|\____ | \___  /  \___  >|____|_  /|____/ |___|  /
        \/          \//_____/       \/        \/             \/ 
           
    Embedded Linux Solutions
 
For further information see:
http://www.ridgerun.com
Build host: dsoto-Latitude-E5430-non-vPro
Built by: dsoto
Build date: Thu, 02 May 2013 16:47:40 -0600
Build tag: dm8168-z3
Configuring network interfaces
SGX revision:  0x10205
Build type:  release6.x
Loaded PowerVR consumer services.

Please press Enter to activate this console.

8. Finally run one of the openGL demos or one of the qt + openGL demos

export LD_LIBRARY_PATH=/lib:/usr/lib:/usr/local/lib
export QWS_DISPLAY="powervr" 
export QT_PLUGIN_PATH=/usr/plugins 
export QT_QWS_FONTDIR=/usr/lib/fonts

cd /opt/gxzsdkdemos/ogles2/
/opt/gfxsdkdemos/ogles2 # ./OGLES2Skybox2 
PVRShell: EGL 1.4 initialized


cd /examples/opengl/hellogl_es2
./hellogl_es2

OpenMax Demos

To run the openMax's demos that are located by default in your filesystem in a directory called omx you need to run first the following commands in your Z3 module

Video initialization

echo 0 > /sys/devices/platform/vpss/graphics0/enabled 
echo 0 > /sys/devices/platform/vpss/graphics1/enabled
echo 0 > /sys/devices/platform/vpss/graphics2/enabled

note: To run the decode display/encode demo with a 1080p video we recommend to use your filesystem by NFS due to the size of the input and output file.

Decode display demo

This demo is the decode-display demo included in the EZSDK. It takes an input file encoded in H264, decodes the stream and sends the output to the HDMI output

./omx/decode_display_a8host_debug.xv5T -i inputFile.h264 -w 1920 -h 1080 -f 60 -g 0

Using Gstreamer

Some examples of use of GStreamer to implement basic multimedia pipelines can be found at Gstreamer pipelines for DM816x and DM814x. Please be aware that in order to display video you need to do the Video initialization

note: If you are not using the Ridgerun SDK and you are trying to use the TAG 00_06_00_00 provided by TI you will need to apply the following patch to make V4L2src and omxbufferalloc work.

Index: gst-openmax-dm81xx/src/omx/gstomxbufferalloc.c
===================================================================
--- gst-openmax-dm81xx.orig/src/omx/gstomxbufferalloc.c	2012-11-14 16:15:41.392143697 -0600
+++ gst-openmax-dm81xx/src/omx/gstomxbufferalloc.c	2012-11-14 16:17:40.760145714 -0600
@@ -190,6 +190,7 @@
 
   gst_element_add_pad (GST_ELEMENT (filter), filter->sinkpad);
   gst_element_add_pad (GST_ELEMENT (filter), filter->srcpad);
+  filter->out_port.portptr = gst_omxportptr_new(&filter->out_port);
   filter->silent = FALSE;
   filter->out_port.num_buffers = 10;
   filter->out_port.always_copy = FALSE;

Additional uboot commands

These u-boot commands are not part of the evaluation or professional SDK, but can be added to the professional SDK if requested.

Description

RidgeRun extended uboot with additional commands for the DM816x platform. The new functionality includes:

1. Copy a block of data from NAND to NAND and decompress the data (gz or bz) on the fly if that is specified in the command. The size of the data being copied can be larger than the available RAM.

nand copy dest src size [gz|bz] - Read data from one section of flash, optionally decompress it, and write it to another section of flash
          dest - destination flash address, must be even sector boundary
          src  - source flash address, must be even sector boundary.  If data is compressed, then all header data will be stored here, as in the beginning of a bz2 archive
          size - number of source bytes to copy; does not have to be even sector boundary; destination size may be larger if source is compressed
          [gz|bz] - decompression algorithm
                    gz: MIME type application/x-gzip
                    bz: MIME type application/x-bzip2

Furthermore, RidgeRun added a nand md5sum command that can be used to verify the integrity of the data that was copied in nand.

nand md5sum src size [gz|bz] - Calculate the md5 sum for a region of flash, optionally decompressing the data

2. Add the ability to extract contents from tarballs, include: list the content of the tarball, cat a desired file that is contained in the tarball, computes the md5sum of the desired tarball or load the tarball from a SD or USB drive, decompress it, take the desired file and write it to NAND. Currently in these commands just gz decompression algorithm is supported and soon we are going to add bz.

tar - tar archive
   
    Usage:
    tar list fat <interface> <dev[:part]> <tarfilename> [<alg>]
    tar cat fat <interface> <dev[:part]> <tarfilename> <filename> [<alg>]
    tar md5sum fat <interface> <dev[:part]> <tarfilename> <filename> [<alg>]
    tar write_nand fat <interface> <dev[:part]> <tarfilename> <filename> <off> [<alg>]   
    Parameters:
            <interface>   :== file system interface name
            <dev[:part]>  :== file system device and partition number
            <tarfilename> :== name of tarball file on the specified storage media
            <filename>    :== name of file of interest which is contained in the tarball
            <off>         :== destination NAND address
            <alg>         :== [gz] - decompression algorithm
                              gz: MIME type application/x-gzip

Configuring SDK to use tar commands

Due to limitations in the DM8168, the size of uboot cannot exceed 255KB. When the tar commands is included in uboot, the executable increases to ~300KB. Due to the hardware limitation RidgeRun implemented a boot model based in two stages to handle a large uboot executable. First, the SDK creates a uboot.min (<255KB) which doesn't have the tar command The small uboot is loaded by the ROM code in the DM8186 as normal, initializating of the board. Subsequently, The small uboot.min loads a second uboot (~300KB) which contains all the logic to implement the tar command. The two stage boot process adds around one second to the overall boot time.

The Ridgerun SDK has logic to handle this approach based in two stages (including the installation process), in order to enabled the two stage model please follow this steps:

1. Open the make config menu

cd $DEVDIR
make config

2. Enable two stages model

Location: │

      -> Bootloader Configuration
    [*] Enable two stages model for uboot

3. Close the make config menu and save your changes

NAND layout

Before to start testing the uboot commands it is important to keep in mind the NAND layout used by your SDK. The following layout was detected using UBIFS ~61MB

  +------------+--->0x00000000-> U-Boot min start
 |		|
 |		|-->0x0003FFFF-> U-Boot min end
 |		|-->0x00040000-> U-Boot start 
 |		|
 |		|-->0x0025FFFF-> U-Boot end
 |		|-->0x00260000-> ENV start
 |		|
 |		|
 |		|-->0x0027FFFF-> ENV end
 |		|-->0x00280000-> Linux Kernel start
 |		|
 |		|
 |		|
 |		|
 |		|-->0x006BFFFF-> Linux Kernel end
 |		|-->0x006C0000-> Filesystem start
 |		|
 |		|
 |		|
 |		|
 |		|
 |		|
 |		|
 |		|
 |		|
 |		|-->0x0435FFFF-> Filesystem end
 |		|-->0x04360000-> Free start
 |		|
 |		|
 |		|
 +------------+-->0x10000000-> NAND end (Free end)

Examples

In this section you are going to find examples about how to use the additional commands provided by RidgeRun.

Please notice that the tar commands can be used to load files from a SD card or from a USB drive, it is important to mention that if you want to load the tarball from the SD card you need to initialize the SD card running the following command:

Z3-DM8168-MOD# mmc init 0
mmc0 is available

Moreover, if you want to use a USB drive you need to initialize it with:

Z3-DM8168-MOD# usb reset
(Re)start USB...
USB:   scanning bus for devices... 1 USB Device(s) found
       scanning bus for storage devices... 1 Storage Device(s) found

Nand copy and nand md5sum

Please create the following files to test the uboot commands

Create 16MB file

sudo dd count=1 bs=16M if=/dev/zero of=file.img
gzip file.img
bzip2 file.img

Compute md5sum

md5sum file.img 
2c7ab85a893283e98c931e9511add182  file.img

md5sum file.img.gz

79ec220244e0c90cfa03764d13a46634 file.img.gz

md5sum file.img.bz2

4119aca17186852b10fce74a2aad5fdf file.img.bz2

Please copy these files to your tftp server directory

cp file.img /srv/tftp/
cp file.tar.gz /srv/tftp/
cp file.img.bz2 /srv/tftp/

Create 32MB file

sudo dd count=1 bs=32M if=/dev/zero of=file32.img
gzip file32.img

Compute md5sum

md5sum file32.img 
58f06dd588d8ffb3beb46ada6309436b  file32.img

md5sum file32.img.gz

2da9ef91a744699aa483754bfefffaed file32.img.gz

Copy files to the tftp server directory

cp file32.img /srv/tftp/
cp file32.img.gz /srv/tftp/

1. nand copy command (without decompress)

In order to test if the nand copy command (without decompress) is working properly the following commands were run in uboot

#Erase the nand sectors where we are going to work
nand erase 0x6c0000 0x00020000

# Dump the memory content at 0x6c0000
nand dump 0x6c0000

#Write 0x1000 (4MB) of 0xaaaaaaaa starting at 0x82000000
mw.l 0x82000000 0xaaaaaaaa 0x1000

#Check that it was written properly in RAM
md 0x82000000

#Write 0x1000 (4MB) from RAM (0x82000000) to nand (0x6c0000)
nand write 0x82000000 0x6c0000 0x1000

#Dump the data just written 
nand dump 0x6c0000

#Now we are going to use the nand copy to move 4MB from 0x6c0000 to 6C1000
#Dump dest
nand dump 6C1000

#nand copy to move 4MB from 0x6c0000 to 6C1000
nand copy 0x6C1000 0x6c0000 0x1000

#Show the data written by nand copy
nand dump 0x6C1000