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
