OMAP4 GLP1.6.1 kernel/DDK mismatch

Steve,

Are you using pandaboard for your testing or custom board? When you say there is a mismatch between kernel and SGX DDK, is there any visible artifacts on TV? Or any error log?

Regards,

Chintan

Hi Chintan.

The target is a custom board.  I have already ported the GLP1.6.1 Linux kernel to it and am now trying to port the GLP1.6.1 DDK.

The problem is a compile problem, not a runtime problem.

Because of the above mentioned problem, I can't compile the SGX kernel module so I haven't gotten to be able to run it yet.

Regards,

    Steve

Are you doing cross-compilation or native-compilation for kernel and module?

Hi Chintan.

I am doing cross-compilation.  Although the problem of missing and inconsistent DRM functions would be the same for native-compilation.

Regards,

    Steve

Steve,

Needed some more information:

1)       Is this first time you are doing this porting on any GLP release? Or have you done similar activity on earlier releases?

2)       Are you seeing kernel compilation failure or module compilation failure? Please give us some failure logs.

3)       Also provide us the steps/procedure you are using for kernel and module build.

We would like to reproduce this issue at our side. The above information will be very helpful for it.

Regards,

Chintan

Hi Chintan.

<blockquote>1) Is this first time you are doing this porting on any GLP release? Or have you done similar activity on earlier releases?</blockquote>

I've worked with TI's Android and Linux code from their git trees and was on the team that ported Gingerbread and 2.6.35 (including the SGX kernel module) to OMAP3 for TI.  But this is the first time I've used a GLP release tarball.

<blockquote>2) Are you seeing kernel compilation failure or module compilation failure? Please give us some failure logs.</blockquote>

As stated earlier, I've ported the kernel to the board.  No problem there.  It is with the SGX kernel module that there's a problem.

<blockquote>3) Also provide us the steps/procedure you are using for kernel and module build.</blockquote>

The easiest way to see the problem is to read the code.

From the earlier mentioned example of omap_framebuffer_init() in omaplfb_displayclass.c:

In the kernel (drivers/staging/omapdrm/omap_drv.h:

    struct drm_framebuffer *omap_framebuffer_init(struct drm_device *dev,
                struct drm_mode_fb_cmd2 *mode_cmd, struct drm_gem_object **bos);

The call in the SGX kernel module (eurasia_km/services4/3rdparty/dc_omapdrm/omaplfb_displayclass.c):

    struct drm_mode_fb_cmd mode_cmd

     ...

    psBuffer[i].fb = omap_framebuffer_init(psDevInfo->dev, &mode_cmd);

Note that the number of parameters passed to omap_framebuffer_init() is incorrect and the second parameter is a pointer to struct drm_mode_fb_cmd when it should be a pointer to struct drm_mode_fb_cmd2.

Another example (same omaplfb_displayclass.c):

     omap_framebuffer_get_buffer(psBuffer[i].fb, 0, 0, &vaddr, &paddr, &screen_width);

If you grep the entire kernel source, you will find that there is no function omap_framebuffer_get_buffer.  According to the git history, this function was removed from the kernel file drivers/staging/omapdrm/omap_fb.c on Jan 16 2012.

If you wish to see the error with a compile instead of reading the source, that is a problem because there are other issues with the SGX kernel module source which I have already made code changes to get around.  For example, source files try to include linux/omap_drv.h which is not the proper location of that file in the kernel source.  After fixing those items, I compile the code using:

export DISCIMAGE=/

export KERNELDIR=<kernel location>

cd eurasia_km/eurasiacon/build/linux2/omap4430_linux

make ARCH=arm CROSS_COMPILE=arm-cortexa9-linux-gnueabi-

Regards,

    Steve

Here is the output of make.

Hi Steve,

If you unpack the OPBU_GFX_DDK_1.6.1.zip, you would find there are several other files apart from sgx-lib_1.7.15.0.1.orig.tar.gz. I do not want to go in detail about these files since this is an open forum, however these files may need to be patched on top of the source file zip you have mentioned. My recommendation is to try a native compile as described in the release notes before doing a cross compile on the PC. If you still see issues like mismatch, please report the same.

Thanks,Satheesh.

Hi Steve,

As per the build instructions for the DDK source code summarized in TI_Linux_OMAP_SGX_DDK.txt (see attachment), the officially supported
kernel is as follows:

git tree: dev.omapzoom.org/pub/scm/integration/kernel-ubuntu.git
git branch: ti-ubuntu-3.1-1282
git tag: ti-ubuntu-3.1-1282.10
commit id: 24e61cacc02cf3bd4825a4ca5c43c22633d7a308

If you look at the kernel source code corresponding to above mentioned git branch and git tag, the definition for the omap_framebuffer_init is defined in the following file namely include/linux/omap_drm.h with 2 parameters as arguments. (This is in alignment with the SGX DDK kernel module source namely OPBU_GFX_DDK_GLP1.6.1.zip)

In the case of latest kernel source with git branch: ti-ubuntu-3.3-1482, the include/linux/omap_drm.h is a symbolic link to drivers/staging/omapdrm/omap_drm.h. Moreover the definition for the omap_framebuffer_init is defined in the drivers/staging/omapdrm/omap_drv.h with 3 arguments. (This is not in alignment with the kernel module source namely OPBU_GFX_DDK_GLP1.6.1.zip).

The best solution is to use the officially supported kernel version (ti-ubuntu-3.1-1282.10) as mentioned above in order to be able to successfully compile the kernel module source of DDK package.

Please provide your feedback after trying the above suggestion.

0486.TI_Linux_OMAP_SGX_DDK.txt

Thanks & Best Regards,
Venkat

Thanks Venkat.

I have used method number 1.  When first reporting this problem, I was not aware of the need to use sgx-lib_1.7.15.0.1-1glp57.diff.gz to patch the source.  It isn't mentioned in TI_Linux_OMAP_SGX_DDK.txt.  Apparently there are further DDK docs on opbuwiki.dal.design.ti.com which describe the process, but those are only accessible from within TI.

There are still issues with cross compiling the DDK rather than doing a native build, but those I can work with now that I have compatible DDK source.

Regards,

    Steve

Hi Steve,

Thanks a lot for the feedback. I will pass this information to GFX DDK team to update the TI_Linux_OMAP_SGX_DDK.txt with the correct build steps so that for customers outside TI, it would be easy to follow the steps for native build.

Please let us know about your findings w.r.t cross compiling so that it would be useful for others in future.

Best Regards,

Venkat