GLSDK FAQs

General

Rebuilding linux kernel with out of tree SGX module

In the recent DRA7xx GLSDK 6.02.01.02 there is a known issue when running graphics applications from the custom built kernel.
When using a kernel built from the installer Makefile (make linux && make linux_install), pvrsrvinit will fail.

There is an updated procedure available to fix this problem, please contact your local FAE for the detailed instructions to fix this issue.

Yocto Build Questions

What proxies do I need to set for a successful build?

During Yocto builds, sources are downloaded from various sources. So ensure that the proxies for git, svn are set correctly. This document talks at length about the proxy settings : https://wiki.yoctoproject.org/wiki/Working_Behind_a_Network_Proxy

Important points to note are http/https/ftp, git and svn setup.

My build gives a fetcher failure, what should I do?

Bitbake will generally give you a verbose log for the fetcher failure. Confirm that your proxies were set correctly in the log.

If everything is correct, and the fetch is failing because of timeout, especially in the case of wget, you can increase the timeout. Add your desired timeout for wget in oe-core/meta/conf/bitbake.conf in the FETCHCMD_wget variable.

How to fix the pseudo compile failure on 64-bit machines?

The 64-bit host system might have some 32-bit libraries but no 32-bit version of libgcc installed. This causes the pseudo-native compilation to fail with error message as follows:

In file included from /usr/include/string.h:27:0,
|                  from pseudo_tables.h:24,
|                  from pseudo_tables.c:23:
| /usr/include/features.h:324:26: fatal error: bits/predefs.h: No such file or directoryChecking for old/new clone mechanics...
| compilation terminated.
.
.
.
.
| ERROR: oe_runmake failed
| ERROR: Function failed: do_compile (see /home/a0875119lx1/GLSDK/ti-glsdk_dra7xx-evm_6_03_00_01/yocto-layers/build/arago-tmp-external-linaro-toolchain/work/x86_64-linux/pseudo-native/1.5.1-  r3/temp/log.do_compile.16582 for further information)
ERROR: Task 7 (virtual:native:/home/a0875119lx1/GLSDK/ti-glsdk_dra7xx-evm_6_03_00_01/yocto-layers/sources/oe-core/meta/recipes-devtools/pseudo/pseudo_1.5.1.bb, do_compile) failed with exit code '1'
NOTE: Tasks Summary: Attempted 70 tasks of which 0 didn't need to be rerun and 1 failed.
No currently running tasks (70 of 72)

A hack to prevent the build of 32-bit libpseudo.so is to set the variable NO32LIBS to 1 in sources/meta-arago/meta-arago-distro/conf/distro/arago.conf

NO32LIBS = "1"

How to fix the openssl build failure on a 64-bit machine?

Failures for openssl are observed on 64-bit machines where the header files provided by ocf-linux package conflict with the ones provided by cryptodev, that results in following build error:

| eng_cryptodev.c:151:4: error: 'CRYPTO_AES_ECB' undeclared here (not in a function)
| eng_cryptodev.c:154:4: error: 'CRYPTO_AES_CTR' undeclared here (not in a function)
| eng_cryptodev.c:179:4: error: 'CRYPTO_SHA2_224' undeclared here (not in a function)
| eng_cryptodev.c:179:2: error: initializer element is not constant
| eng_cryptodev.c:179:2: error: (near initialization for 'digests[2].id')
| eng_cryptodev.c: In function 'get_cryptodev_ciphers':
| eng_cryptodev.c:260:25: error: 'CRYPTO_CIPHER_MAX_KEY_LEN' undeclared (first use in this function)
| eng_cryptodev.c:260:25: note: each undeclared identifier is reported only once for each function it appears in
| eng_cryptodev.c:260:16: warning: unused variable 'fake_key' [-Wunused-variable]
| eng_cryptodev.c: In function 'get_cryptodev_digests':
| eng_cryptodev.c:299:25: error: 'CRYPTO_CIPHER_MAX_KEY_LEN' undeclared (first use in this function)
| eng_cryptodev.c:308:14: warning: assignment from incompatible pointer type [enabled by default]
| eng_cryptodev.c:299:16: warning: unused variable 'fake_key' [-Wunused-variable]
| eng_cryptodev.c: In function 'cryptodev_digest_final':
| eng_cryptodev.c:860:21: warning: unused variable 'sess' [-Wunused-variable]
| eng_cryptodev.c:858:18: warning: unused variable 'cryp' [-Wunused-variable]
| make[2]: *** [eng_cryptodev.o] Error 1
| make[2]: Leaving directory `/home/a0875119lx1/GLSDK/ti-glsdk_dra7xx-evm_6_03_00_01/yocto-layers/build/arago-tmp-external-linaro-toolchain/work/dra7xx_evm-oe-linux-gnueabi/openssl/1.0.1e-r15.0-arago8/openssl- 1.0.1e/crypto/engine'
| make[1]: *** [subdirs] Error 1
| make[1]: Leaving directory `/home/a0875119lx1/GLSDK/ti-glsdk_dra7xx-evm_6_03_00_01/yocto-layers/build/arago-tmp-external-linaro-toolchain/work/dra7xx_evm-oe-linux-gnueabi/openssl/1.0.1e-r15.0-arago8/openssl-1.0.1e/crypto'
| make: *** [build_crypto] Error 1
| ERROR: oe_runmake failed
| ERROR: Function failed: do_compile

To workaround this issue, add this line in sources/meta-arago/meta-arago-extras/recipes-kernel/cryptodev/cryptodev_1.6.bb:

RREPLACES_${PN}_append_dra7xx-evm = "ocf-linux"

If the ocf-linux header files are still overriding the cryptodev headers, and resulting in the same build error, kindly override the PR in sources/meta-arago/meta-arago-extras/recipes-kernel/cryptodev/cryptodev_1.6.bb:

PR = "r1"

How to fix build failures with x264 component?

Due to an upstream git repository rewrite, the x264 component builds and hence the GLSDK Yocto build has started failing since May 2014. In order to the fix the problem, users are requested to follow the below procedure:

• Pick up the patch http://arago-project.org/git/projects/meta-arago-glsdk.git?p=projects/meta-arago-glsdk.git;a=commit;h=a0c23900703dd66bf28760cbdaf6bdec97c9bd72
• This patch creates a x264.bbappend file and points to the right commit.
• Rebuild the GLSDK with the same command as earlier.

How to fix build failures on GLSDK 7.00.00.04 due to gitorious.org issues ?

We have seen some issues with accessing the gitorious.org repos recently. The issue is basically the inability to clone any of the hosted git repositories on gitorious.org over git protocol.
To solve this problem, it is advised that the customers should pick up the following patches and apply it to the meta-arago repository which is present under

$GLSDK/yocto-layers/sources/meta-arago

1. http://arago-project.org/git/?p=meta-arago.git;a=commit;h=1b511f8f9d6fcbcb6f69c3f1bccd10ba1276b190
2. http://arago-project.org/git/?p=meta-arago.git;a=commit;h=e9d72ec719bea12e440ad2c5c48f3559bb760c55
3. http://arago-project.org/git/?p=meta-arago.git;a=commit;h=7d1a03795e288565f4de856bf44233ac055d5ad1
4. http://arago-project.org/git/?p=meta-arago.git;a=commit;h=89201e4e26c9c91a7502c7db30af1e58c170be53
5. http://arago-project.org/git/?p=meta-arago.git;a=commit;h=cb011d7ab3bf0b13243c0a75f46ccddea1f31c8b

These patches make the required adaptation to allow cloning over http for all the dependent recipes/packages.

NOTE:
1. For patches #2, #3, #4 and #5 in the above list - the user should be able to cherry-pick/git am/git apply the patch directly on top of meta-arago
2. For patch #1, you will have to refer to the commitdiff and make the changes manually to the various files in the patch.

Download and Upgrade Questions

Where can I download the GLSDK release from?

The GLSDK releases are available for download from http://software-dl.ti.com/dsps/dsps_public_sw/glsdk/index.html. Choose the version that you are looking for from the table.

Feature Additions

How do I enable gst-ugly plugins of GStreamer?

Gst-ugly plugins contain a set of proprietary decoders that cannot be shipped as a part of filesystem. However the recipe for the gst-plugins-ugly is present on the meta-arago-glsdk external staging tree and one can build these plugins easily. By default the arago configuration prohibits the build of gst-ugly-plugins and some of its dependencies because of licensing limitations. To whitelist these componests, edit the LICENSE_FLAGS_WHITELIST varibale in meta-arago-distro/meta-arago-distro/conf/distro/arago.conf.

LICENSE_FLAGS_WHITELIST = "commercial_gst-ffmpeg \
                           commercial_gst-plugins-ugly \
                           commercial_mpeg2dec \
                           commercial_lame"

After this you can proceed with the build of gst-ugly plugins with the normal bitbake command.

Issues while running sample applications

Getting the error "ERROR:decoder_open:200: 0x1b070: could not open engine" when running the viddec3test

If you are getting the above error when running the viddec3test, kindly check the boot log if there is an error "remoteproc1: failed to load dra7-ipu2-fw.xem4". If you see this error, then the IPU has not been loaded successfully. Note: There is an issue in the release, when the Ethernet cable is not connected to the board, it takes long time to boot and the ipu firmware is not loaded successfully. Hence, kindly repeat the experiment with the ethernet cable attached to the board and check if load failure is still there for the IPU2 firmware.

Unable to run Weston on the GLSDK release

For a board that does not have the LCD, the connector ID's can be different from what is documented in the Software Developers Guide. So we have to follow a slightly different procedure to get weston working:

• Run "modetest" application, this will give you the connector id for the HDMI connection.

 target # modetest

• Use the connector id from the "modetest" command and pass that number as the input to weston.
• On a board with only the HDMI connected, you can use the following command:

 target # weston --connector=5 (if the connector id in the modetest is 5)

what is the thermal policy in GLSDK - DRA7xx Kernel?

Please refer to the page GLSDK Thermal Framework for detailed information.

Additional FAQs

Link to additional FAQs | Processor SDK LA FAQs