A related question is a question created from another question. When the related question is created, it will be automatically linked to the original question.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
We've already ported a 3.2 kernel to the AM37x. Since the AM335x uses kernel 3.2 and contains the same SGX530 core revision (1.2.5) as the AM37x. Will the quick installation procedure for the instructions for the AM335x now apply to the AM37x running the later kernel?
It appears that the only build dependency for the SGX libraries + modules is based on the SGX core revision. Are there any other dependencies (kernel/chiplevel/PSP) that must be considered to build these libraries?
Mike - as discussed, there are clock and power dependencies on the kernel framework. We have not tried moving to kernels beyond 3.2 as the APIs change.
1. A 2.6.37 close-to-mainline kernel + OMAPES=5.x on omap37xx and omap35xx; worked with perhaps a few trivial compile errors
2. A 3.2 close-to-mainline kernel with fixes as outlined here https://github.com/Pansenti/sgx-qt-build; compiled for OMAPES=5.x....it is a shame that both kernel patches and SGX patches are required to get this working.
3. Based on suggestions from Mike, who noted that the AM335x and DM3730 have the same SGX core at the same rev., tried build a 3.2 close-to-mainline kernel for a DM3730 system using OMAPES=8.x. This did not compile as a bunch of AM335x specific constructs in the kernel are needed. Then tried building against the arago AM335x 3.2 branch for the DM3730 platform; this compiled with few errors but the board did not boot. The delta on this tree compared to mainline is >10K commits so this is not backportable.
Sorry for the bust on option three. It seemed like a reasonable approach at the time. Can you expound a bit more on Option 2. Were you able to get that option working on the DM37x and the AM37x?
Can you double check that you are using the latest Linux GFX SDK 04.08.00.02 and NOT 04.08.00.01. There are some known compilation issues when compiling 4.08.00.01 against the 3.2 kernel for the AM37xx.
Also, can you please post the compilation errors that you are seeing.
This new package fixed some of the compilation issues for me when compiling as " make BUILD=release OMAPES=5.x FBDEV=yes" against a close-to-mainline 3.2 kernel. I do still get an error compiling devmem2 using the linaro gcc-4.7 toolchain:
arm-linux-gnueabi-gcc -Wall -DRELEASE -O2 -c devmem2.c -o Obj/devmem2.o devmem2.c: In function ‘main’: devmem2.c:104:5: warning: format ‘%X’ expects argument of type ‘unsigned int’, but argument 2 has type ‘off_t’ [-Wformat] devmem2.c:123:3: warning: format ‘%X’ expects argument of type ‘unsigned int’, but argument 2 has type ‘long unsigned int’ [-Wformat] mkdir -p ./Obj arm-linux-gnueabi-g++ -o ./Obj/devmem2 ./Obj/devmem2.o -lm -ldl -Wl arm-linux-gnueabi-g++: error: unrecognized command line option ‘-Wl’
I modified the devmem2 Makefile to use the standard linker syntax: "PLAT_LINK = -Wl,-lm -ldl", and it appeared to compile.
When I tried compiling as " make BUILD=debug OMAPES=5.x FBDEV=yes", I get errors from the RCU kernel include:
CC [M] /home/ash/Desktop/Graphics_SDK_4_08_00_02/GFX_Linux_KM/services4/srvkm/common/queue.o In file included from include/linux/tracepoint.h:19:0, from include/trace/events/kmem.h:8, from include/linux/slab_def.h:18, from include/linux/slab.h:189, from /home/ash/Desktop/Graphics_SDK_4_08_00_02/GFX_Linux_KM/services4/srvkm/env/linux/mm.h:54, from /home/ash/Desktop/Graphics_SDK_4_08_00_02/GFX_Linux_KM/services4/srvkm/env/linux/mmap.h:59, from /home/ash/Desktop/Graphics_SDK_4_08_00_02/GFX_Linux_KM/services4/srvkm/include/refcount.h:177, from /home/ash/Desktop/Graphics_SDK_4_08_00_02/GFX_Linux_KM/services4/srvkm/include/services_headers.h:65, from /home/ash/Desktop/Graphics_SDK_4_08_00_02/GFX_Linux_KM/services4/srvkm/common/queue.c:42: include/linux/rcupdate.h: In function ‘__kfree_rcu’: include/linux/rcupdate.h:808:2: error: size of unnamed array is negative
I'd suspect this is a kernel_versioning issue where something is not getting ifdef'ed into place (a la #if (LINUX_VERSION_CODE < KERNEL_VERSION(2,6,38)) ) but perhaps there is actually a kernel issue. The included headers match mainline.
Also for the debug build, as you suspected its a kernel issue. The initial definition of __kfree_rcu() checked a static inline function argument to see if it was a compile-time constant. Not all compilers can support this with third party kernel modules built with -O0 optimization level(ie what is used for debug builds). You can use the below kernel patch to solve that issue -
It works fine either ways with arago toolchain. Thanks for the input. We can change the syntax in our next release so that its compatible with other toolchains as well.
Glad to know that you have the debug build rolling nicely with the kernel patch.
Thatswhy, right from beginning of the thread we had been suggesting/checking that you are indeed using the latest graphics SDK release 04.08.00.02 in context of 3.2 kernels for AM35xx/37xx.
Glad to know that its going nice for you now. Also please note that debug build should be used judiciously, as the name suggests for debug purpose only. Release build is suggested by default.
You can visit the sgxdbg page for commonly encountered problems, it will provide you with suggestions/troubleshooting techniques -
Glad to hear the makefile patch can be queued for the next release.
I understand the recommendation to compile against an Arago kernel however it is important for me to use a close-to-mainline kernel to the greatest extent possible so the upgrade path is clear in the future. Thanks for identifying the necessary patch.
