[AM3715] Porting SGX to Kernel 3.2

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.

- What is the issue faced ?

Mike,

Can you provide more details with error logs on the issue you are facing?

As mentioned by Prabindh, we have not tried kernels beyond 3.2. Did you try 3.2 & what are your observations with that?

Also please ensure that you are trying the latest graphics SDK release -

http://tigraphics.blogspot.in/2012/12/4q-2012-update-of-linux-graphics-sdk.html

Thanks,

Prathap.

Hi Mike,

Did you try the latest 04.08.00.02 graphics SDK release for 3.2 kernel & what are your observations with that?

Can you please share the build/error logs if you are facing issues with 04.08.00.02 as well?

If not, can you please close this thread.

Thanks,

Prathap.

Hi,

I tried 3 combinations (all with the 4.08 SGX)

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.

Ash,

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?

I haven't fully exercised options #2 but based on the success reported here (https://github.com/Pansenti/sgx-qt-build), I think this may be a good approach.

Hey Ash,

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.

Hi,

Glad to know that your release build went through.

We are using arago toolchain which is part of SDK & devmem2 compilation goes through fine. See build log below -

mkdir -p ./Obj
arm-arago-linux-gnueabi-g++ -o ./Obj/devmem2 ./Obj/devmem2.o    -lm -ldl -Wl
make[1]: Leaving directory `/home1/prathap/gfxsdkrelease/04_08_00_02/tools/devmem2'
make[1]: Entering directory `/home1/prathap/gfxsdkrelease/04_08_00_02/tools/devmem2'
cp ./Obj/devmem2 ../../targetfs/

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 -

http://patches.linaro.org/1462/

Thanks,

Prathap.

Hi Prathap,

Does the makefile change for devmem2 break on the arago toolchain?  The '-wl,' syntax looks to be standard for gcc so maybe this is a good way to go?

Paul's patch works nicely to get the debug build rolling.

--Ash

Hi Ash,

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.

arm-arago-linux-gnueabi-g++ -o ./Obj/devmem2 ./Obj/devmem2.o    -Wl,-lm -ldl
make[1]: Leaving directory `/home1/prathap/gfxsdkrelease/Graphics_SDK_4_08_00_02/tools/devmem2'
make[1]: Entering directory `/home1/prathap/gfxsdkrelease/Graphics_SDK_4_08_00_02/tools/devmem2'
cp ./Obj/devmem2 ../../targetfs/

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 -

http://processors.wiki.ti.com/index.php/SGXDbg

For any other usage related details, you can see our user guide -

http://processors.wiki.ti.com/index.php/Graphics_SDK_Quick_installation_and_user_guide

Please close this thread by marking the verified answer so that it helps other users as well when they face similar problem.

Thanks,

Prathap.

Hi Prathap.

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.

--Ash

Hi ,

Can any one post the links foe AUDIO porting , 

installing mp3 codec 

Regards,

Dibin

Did you have any success getting the Graphics SDK to work with a 3.2 kernel?

Hi Prathap

I complie ti-sdk-pvr-4.09.00.1, but get error:

  LD [M]  /home/jane/graphics/Graphics_SDK_4_09_00_01/GFX_Linux_KM/services4/3rdparty/bufferclass_ti/bufferclass_ti.ko
  CC      /home/jane/graphics/Graphics_SDK_4_09_00_01/GFX_Linux_KM/services4/3rdparty/dc_ti335x_linux/omaplfb.mod.o
  LD [M]  /home/jane/graphics/Graphics_SDK_4_09_00_01/GFX_Linux_KM/services4/3rdparty/dc_ti335x_linux/omaplfb.ko
make[2]: Leaving directory `/home/jane/linux-3.2.0-psp05.06.00.00'
make[1]: Leaving directory `/home/jane/graphics/Graphics_SDK_4_09_00_01/GFX_Linux_KM'
copying the sgx kernel modules to appropriate folder...
building devmem2...
make: *** /home/jane/graphics/Graphics_SDK_4_09_00_01/tools/devmem2: No such file or directory.  Stop.
make: *** [builddevmem2] Error 2

Have you met this problem?

Hi Kemal，

Thanks for your kindly reply. I have solved this problem.

Best Regards

xixiguo