This thread has been locked.

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.

VPSS Module Fails to Load if "make modules" is Only Run Once

Guru 10675 points
Other Parts Discussed in Thread: PCF8575, THS7360, THS7375

I am building the kernel outside of the EZSDK using the official Code Sourcery 2009-q1 toolchain.

Something very strange is happening in that the first time I build the kernel and modules, the resulting vpss.ko that is loaded on the target gives this error:

modprobe vpss.ko

vpss: no symbol for module layout

This version of vpss.ko is 61584 bytes big.

If I rebuild the modules I find that vpss.ko increases to 64528 bytes in size and now loads perfectly on the target without any problems.

I have done a diff on the vpss directory after the first time I build the modules and see that the vpss.mod.c file is as below:

#include <linux/module.h>
#include <linux/vermagic.h>
#include <linux/compiler.h>

MODULE_INFO(vermagic, VERMAGIC_STRING);

struct module __this_module
__attribute__((section(".gnu.linkonce.this_module"))) = {
 .name = KBUILD_MODNAME,
 .init = init_module,
#ifdef CONFIG_MODULE_UNLOAD
 .exit = cleanup_module,
#endif
 .arch = MODULE_ARCH_INIT,
};

static const struct modversion_info ____versions[]
__used
__attribute__((section("__versions"))) = {
        { 0x6f252e4, "Notify_unregisterEvent" },
        { 0x7b0dac11, "Notify_registerEvent" },
        { 0xe179b20d, "Notify_sendEvent" },
        { 0x7261d27a, "MultiProc_getId" },
};

static const char __module_depends[]
__used
__attribute__((section(".modinfo"))) =
"depends=syslink";

However the same file when the module is rebuilt is much bigger as below:

#include <linux/module.h>
#include <linux/vermagic.h>
#include <linux/compiler.h>

MODULE_INFO(vermagic, VERMAGIC_STRING);

struct module __this_module
__attribute__((section(".gnu.linkonce.this_module"))) = {
 .name = KBUILD_MODNAME,
 .init = init_module,
#ifdef CONFIG_MODULE_UNLOAD
 .exit = cleanup_module,
#endif
 .arch = MODULE_ARCH_INIT,
};

static const struct modversion_info ____versions[]
__used
__attribute__((section("__versions"))) = {
        { 0x7a6f846a, "module_layout" },
        { 0x401c3662, "kobject_put" },
        { 0xacd3aab0, "kmalloc_caches" },
        { 0x12da5bb2, "__kmalloc" },
        { 0x27864d57, "memparse" },
        { 0x349cba85, "strchr" },
        { 0x6980fe91, "param_get_int" },
        { 0x97255bdf, "strlen" },
        { 0xe48e0268, "pcf8575_ths7360_hd_enable" },
        { 0x20000329, "simple_strtoul" },
        { 0xa58bc07b, "mutex_unlock" },
        { 0x85df9b6c, "strsep" },
        { 0xb3aa7379, "kobject_del" },
        { 0xff964b25, "param_set_int" },
        { 0xe2d5255a, "strcmp" },
        { 0x41344088, "param_get_charp" },
        { 0xfa2a45e, "__memzero" },
        { 0x5f754e5a, "memset" },
        { 0x3b7e1f29, "pcf8575_ths7360_sd_enable" },
        { 0x1d891463, "__mutex_init" },
        { 0xea147363, "printk" },
        { 0x6652cc07, "kobject_init_and_add" },
        { 0x9f2d613e, "param_set_bool" },
        { 0xe48f9695, "mutex_lock" },
        { 0xc1668501, "platform_driver_register" },
        { 0x2196324, "__aeabi_idiv" },
        { 0xe9601b97, "kmem_cache_alloc" },

        { 0x6f252e4, "Notify_unregisterEvent" },
        { 0x3bd1b1f6, "msecs_to_jiffies" },
        { 0x108e8985, "param_get_uint" },
        { 0x1000e51, "schedule" },
        { 0xe9ce8b95, "omap_ioremap" },
        { 0x15331242, "omap_iounmap" },
        { 0x586818d2, "wait_for_completion_interruptible_timeout" },
        { 0xc27487dd, "__bug" },
        { 0x8f068b9b, "pcf8575_ths7375_enable" },

        { 0x7b0dac11, "Notify_registerEvent" },
        { 0x6ad065f4, "param_set_charp" },
        { 0x1d2e87c6, "do_gettimeofday" },
        { 0x37a0cba, "kfree" },
        { 0x9d669763, "memcpy" },
        { 0x3285cc48, "param_set_uint" },

        { 0xe179b20d, "Notify_sendEvent" },
        { 0x7261d27a, "MultiProc_getId" },
        { 0x9214ed8a, "param_get_bool" },
        { 0xb742fd7, "simple_strtol" },
        { 0x60f71cfa, "complete" },
        { 0x701d0ebd, "snprintf" },
        { 0xd6ece25b, "platform_driver_unregister" },
        { 0xe914e41e, "strcpy" },

};

static const char __module_depends[]
__used
__attribute__((section(".modinfo"))) =
"depends=syslink";

I've highlighted the additional lines of code that have somehow been added during the second make.

I suppose this question is directed at TI in particular as I find it very strange how a second make of the modules can change the c file. Anyone know what's going on? I am using the current EZSDK (5_00_00_56).

Thanks,
Ralph

 

  • Okay, I have tried following the instructions in VPSS_Video_Driver_UserGuide.pdf which is in psp/docs in the EZSDK in order to rebuild the kernel within the EZSDK.

    I am sorry to say I have the same problem as when I was building the kernel outside of the EZSDK. If I do this sequence of commands in the psp/linux-2.6.34-psp04.00.00.07 directory I end up with a bad vpss.ko that is only 61584 bytes big:

    make clean

    make ARCH=arm CROSS_COMPILE=PATH_TO_TOOLCHAIN/bin/arm-none-linux-gnueabi- modules

    make ARCH=arm CROSS_COMPILE=PATH_TO_TOOLCHAIN/bin/arm-none-linux-gnueabi- uImage

    BUT, if I do the following sequence of commands (i.e. building the uImage first), there is no problem with vpss.ko (it enlarges to 64528 bytes):

    make clean

    make ARCH=arm CROSS_COMPILE=PATH_TO_TOOLCHAIN/bin/arm-none-linux-gnueabi- uImage

    make ARCH=arm CROSS_COMPILE=PATH_TO_TOOLCHAIN/bin/arm-none-linux-gnueabi- modules

     

    Every Linux kernel I have ever come across has allowed me to build the modules first without any problem. Why is it that when I come to using TI's "patched" kernel it works in such a weird way? Are there any plans to fix the kernel build system in the next EZSDK release? Is there a patch that will fix it for me now?

     

    Thanks,
    Ralph

  • Ralph

    In the old Linux release, vpss.ko has has a dependency over the uImage, which is set through menuconfig. so uImage must be built first before building modules. but we have fixed this and you should not face this issue anymore in next EZSDK release.

    Thank you for your post.

    yihe

  • Okay, thanks for confirming that. I now have another reason to really look forward to the next EZSDK release.

    Ralph

  • Hello. I'm now on EZSDK 5.01.01.80.

    That's 2 further revisions down the line.

    This problem is still present! Any plans to fix it in the _next_ version?

    Thanks,

    Ralph

  • Ralph

    This dependency is removed from the PSP level. But SDK is a big SW package and has lots of different SW components, it will take some time for them to integrate new component.

    Sorry for the inconvenience.

    Regards,

    yihe

     

  • Hi Yihe. I'll wait. I just wanted to check that the issue hadn't been forgotten about.

    Thanks,

    Ralph