"Disagrees about version of symbol struct module"

I believe you need to go back and re-check your .ko builds.  I have seen the "disagrees about version of symbol struct_module" many times, and *always* it is printed because I was booting a kernel (uImage) that was from a Linux tree different from the one to which I pointed the .ko build.

It's possible that your "vermagic" is the same as the 'uname -r' output while the two kernels (booted kernel and built-against kernel) are indeed different.  I have a DM8168 kernel tree that has the same vermagic as a DM8148 kernel but they are different kernels.

Please re-check your .ko builds, and also ensure your uImage comes from the tree to which you're pointing your .ko builds.  If you still believe they match and yet there is still a problem during insmod, reply here with more than just your description above (it's always a good idea to include more info with your post), such as the output from the 'uname -r' command and the output from your .ko file build

Regards,

- Rob

Robert,

I made sure that the tree I am using was the source for the run time files. I took the tree from the original developers which is PSP SDK 02.01.02.09 (there is no way to download from the Internet). The string I received via uname -r and via the vermagic string embedded in the ko files is 2.6.29-rc3-omap1. Also I have noticed that on my target there is /lib/modules/2.6.22.18-omap3 but again the tree I was using was the source for building the traget run time firmware. HOWEVER my verification regarding the matching trees on the target is only  by information delivered by the developers - that is not via other mean such as command etc.

I am using unixutils version 2.26.01.2 to build cmemk.ko and using local_power_manager_linux_1_24_02_09 to build lpm_omap3530.ko and using dsplin_linux_1_65_00_03 to build dsplinkk.ko I was following the instructions carefully of how to build these drivers including building the Linux kernel

Please tell what other information might be usefull

Thanks Ofer

Robert,

It might be related to insmod or modeprobe or depmod coammnds that I need to excute correctly somehow?

Ofer

Ofer Zimmerman said:

It might be related to insmod or modeprobe or depmod coammnds that I need to excute correctly somehow?

No, I don't think so.  modprobe is a fancier version of insmod, allowing the .ko file to be "found" even if it's not in the present directory.  Your problem relates to inserting the .ko into the kernel, so you've already gotten past the "found" part.

- Rob

Rob,

So assuming the info I provided above what else can I do ? maybe I can build the .ko/kernel without the symbol mechanisem check?

Help.....

Ofer

As I said previously, I don't know of any other reason that you would receive that message - in my experience, you receive that message when you built the .ko against a kernel different than the one you are booting.

The /lib/modules/2.6.22.18-omap3 directory will not be used unless you are running a kernel of that exact release.  You can create a kernel-specific modules directory by doing something similar to the following:
    % make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- modules
    % make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- INSTALL_MOD_PATH=/data/exports/rt/android_fs modules_install
where you replace /data/exports/rt/android_fs with your filesystem path.

Give that a shot and maybe we'll learn something new about the problem.

Regards,

- Rob

Ofer Zimmerman said:

So assuming the info I provided above what else can I do ? maybe I can build the .ko/kernel without the symbol mechanisem check?

You could try some sort of:
    % modprobe --force cmemk.ko ...

Do "% man modprobe" for further info.

- Rob

Rob,

OK I will try the build you suggested just to understand - you mean to execute these commands from the PSP tree where I build the linux kernel: the make install to fs as you say is to a directory on my PC host right? and then I copy the files to the target?

regarding the --force I tried this before - the problem that it keep saing that it can not find the file (the .ko driver) 

Ofer

and I am not sure I understand what is modules stand for ? the .ko files? can you clarify? are you refering to do so on the traget ?

Ofer

Robert,

Can you expalin the commands you proposed above ? where do I execute them on the target ? on the PSP SDK? can you clarify more I did not understand.

Thanks Ofer

Ofer Zimmerman said:

Robert,

Can you expalin the commands you proposed above ? where do I execute them on the target ? on the PSP SDK? can you clarify more I did not understand.

Thanks Ofer

I wish I could spend the time needed to answer all your questions, but I cannot.  I have provided guidance in this thread, and can continue to answer carefully crafted questions, but I just don't have the time to put in the effort that you're asking for.

Please try to research my guidance in the general marketplace.  If you run across something that you are not familiar with, please at least try to Google it or search the TI e2e Forums for further info.  And when you do post to this forum, please take the effort to paste relevant output relating to the issue (such as build output, etc., oftentimes there is something in that output that you would otherwise consider useless that can at least inform us to the issue or steer further questions).  We all communicate differently, even within the same language, but computer output is the common language that is unambiguous and never misinterpreted.

Regards,

- Rob

Robert,

I would like to thank you for your great support and help. Just want to say that while I am asking many questions I do search the google extensively and read many docs/readme guides of TI along the (long) process I am doing. While asking I am making alot of effort to understand and read information and follow. I feel that I am close (but unfortunately it is not enough). And i do not know  where else I can get help other than this forum. Again thanks alot for your help and time.

best regards Ofer

Ofer,

I'm glad to hear that you're trying to research answers on your own, as I was getting the impression that you just were relying on the Forum too much for your own good.  Since this Forum is staffed by regular engineer types and not a dedicated support staff, there can be delays in responding.  Oftentimes you will be able to find the answer on your own quicker than the time it takes someone to respond to the Forum.  And I understand that what you're doing involves lots of different components and there is no centralized documentation - in other words, it's hard.

Allow me also to repeat another suggestion that is "for your own good" (i.e., helps us in helping you), there is no such thing as "too much output".  Any and all information that is output by a step in your development process will help get to the bottom of the issue - build output, Linux command output, etc..  We like to "see" that you did the right thing, instead of hearing you just say that you did it.

A couple brief responses, since you're having trouble finding out where else to get the answers...

- "modules" are the .ko files.  The step in which I instructed you to do "make ... modules" and "make ... modules_install" is run from the top directory of your PSP Linux installation, on your development machine, in the same place where you build the Linux kernel uImage.  The "modules_install" needs to point to the location of your filesystem, and if you don't have direct access to it from your development machine, you will need to at least have a staging area in which they are installed on your development machine, then copied to your machine that houses the Linux filesystem.

- The "modprobe" command should be well documented.  You run this one on your target Linux machine.  For it to succeed, you need to have your .ko files in a well-known location, probably in /lib/modules/<linux_version_string> directory.  I would imagine that if you succeed in the "modules_install" step then the modprobe (along with --force, if you still need it) will succeed.

Regards,

- Rob

Robert,

I did as you instructed and created a /lib/modules/2.6.29-rc3-omap1 and indeed there are several files there and I copied them to the corresponding directory in the target (under /lib/modules/2.6.29-rc3-ompa1). When I run modprobe I got FATAL: file cmem not found. Now I run without the .ko (as I read in some of similar issues on the Internet). and I put both the modules in the current directory (where I run the modprobe) and also in /lib/modules/2.6.29-rc3-omap1) but same result. I have notices that the file modules.dep is empty and also /etc/modules.conf is empty (is that OK??). I read the modprobe carefully and I do not see any issue with my settings (other then the empty files). 

In addition to what you instructed me I did also make -C /lib/modules/'uname -r' /build M='pwd' (per the Kbuild readme file)

Ofer

If I may add info (...) the commands you provided are for kernel internal modules (I guess) and indeed it was OK but for my (external) drivers I did the followings (since there was no support to some of your commands such as modules_install): 

from cmem/src directory (part of linux-utils package):

make -C <path-to-kernel> M='pwd'

make -C /lib/modules/'uname -r' /build M='pwd"

make -C <path-to-kernel> M='pwd' modules_install

while doing your commands (in the PSP SDK Linux directory) I have noticed that modules.order, modules.symbols and modules.dep have meaning data regarding the internal kernel .ko BUT while doing the process above (3 stated commands) these files are totally empty - I believe this is the root cause for Module not found issue.

Ofer

Ofer,

I know just enough about this sort of thing to be dangerous.  At this point in this thread I doubt too many other folks besides me are paying attention to it, but hopefully for you someone else who knows about this stuff can respond.  This subject is fairly general in nature, and as such there is lots of stuff on the internet about it.

I'm not too familiar with modprobe.  My "standard operating procedure" is to have cmemk.ko/lpm_3530.ko/dsplinkk.ko in the present directory from where I run loadmodules.sh.  When a .ko file exists in the present directory, insmod is used instead of modprobe, and with insmod no /lib/modules/`uname -r` or modules.dep is required.  So, about the best I can recommend to you is to have all those 3 .ko files in the same dir as loadmodules.sh and just run "% ./loadmodules.sh" (the "./" [dot-slash, incase you can't see the dot] is important for ensuring the local loadmodules.sh is run instead of some other one in your $PATH).  insmod has the same issues with kernel version matching as does modprobe, and I don't know that insmod has a --force type parameter, maybe so maybe not.

FYI, your 3 'make' commands

Ofer Zimmerman said:

from cmem/src directory (part of linux-utils package):

make -C <path-to-kernel> M='pwd'

make -C /lib/modules/'uname -r' /build M='pwd"

make -C <path-to-kernel> M='pwd' modules_install

are not something I typically do when building linuxutils (or other .ko) modules.  There is a Makefile in <linuxutils>/cmem/src/module that should be used, and it supports the "empty target" "% make" to build cmemk.ko w/o debug, as well as building cmemk.ko with debug info "% make debug".  This Makefile includes ../../Rules.make, and ../../Rules.make needs to be edited with your codegen tools location (MVTOOL_PREFIX) and your Linux kernel source tree location (LINUXKERNEL_INSTALL_DIR setting).

Let me take this opportunity to again state that I believe you are not running a uImage that is built from the same Linux tree to which you point your .ko builds, as that is the only reason I know of that would cause your error.  It can be a challenge "connecting the dots" from the Linux kernel tree to the uImage being booted.

Regards,

- Rob

Sriram,

thanks. This is what I did and it solved the issue. How do I close this thread?

Ofer

Just click the green "Verify Answer" button for the reply(s) that solved your issue.  That will indicate the thread has been answered.

Chris