Building DSPLink: missing CFG_system.c

Did you run the configuration step before the make?  For example (from the OMAP3530 DspLink Linux Installation Guide), it would be something like this:

perl dsplinkcfg.pl --platform=OMAP3530 --nodsp=1 --dspcfg_0=OMAP3530SHMEM --dspos_0=DSPBIOS5XX --gppos=OMAPLSP --comps=ponslrmc

That BUILD directory is generated, so it looks like it may not have been generated yet.

Best regards,

    Janet

Hi Janet,

Yes, I followed all the steps in the installation guide with the exception of the step immediately before 'make -s', and the BUILD directory was generated. I got also messages that some CC paths were not set correctly, so I adjusted those. Then I ran 'make -s' and got the error. Is there anything in that .MK file in BUILD that should be changed to avoid this error ?

Regards

Hi,

I tried this out but could not reproduce the problem.  Here are the steps I ran:

1.  Set the DSPLINK environment variable:

  setenv  DSPLINK  /db/vtree/jeh/dsplink_linux_1_65_02_09/dsplink

2. Run the perl script:

  cd $DSPLINK/config/bin
  perl dsplinkcfg.pl --platform=OMAP3530 --nodsp=1 --dspcfg_0=OMAP3530SHMEM --dspos_0=DSPBIOS5XX --gppos=OMAPLSP --comps=ponslrmc

    (Your --comps may be different, depending on what DSPLink components you want).

3.  Edit $DSPLINK/make/Linux/omap3530_2.6.mk and set these variables to the paths to your Linux kernel and tools (this is what I set mine to):

  BASE_BUILDOS := $(VENDORS)/kernel_org/arm/KERNEL_03.00.00.02/OMAP35x-PSP-SDK-03.00.00.02/OMAP35x/linux-03.00.00.02
  BASE_TOOLCHAIN $(VENDORS)/cs/arm/arm-2009q1-203

4. Edit $DSPLINK/gpp/src/Rules.mk and set these two variables to the kernel and tools locations (these are my specific paths):

  KERNEL_DIR := $(VENDORS)/kernel_org/arm/KERNEL_03.00.00.02/OMAP35x-PSP-SDK-03.00.00.02/OMAP35x/linux-03.00.00.02
  TOOL_PATH := $(VENDORS)/cs/arm/arm-2009q1-203/bin

5. Build the dsplink user library and kernel module:

  cd $DSPLINK/gpp/src/api
  make -s
  cd $DSPLINK/gpp/src
  make -s

I can't think of what would cause the files in $DSPLINK/config/BUILD to not be found, other than that they weren't generated, or the path to them ($DSPLINK) is not correct.

Best regards,

    Janet

Hi,

Thank you for your clear response. It went a lot better now, but I'm still not there. First I got this error and warning:

Building kernel side code using kbuild

  ERROR: Kernel configuration is invalid.
         include/generated/autoconf.h or include/config/auto.conf are missing.
         Run 'make oldconfig && make prepare' on kernel src to fix it.


  WARNING: Symbol version dump /home/huub/AM35x-OMAP35x-LINUX-PSP-04.02.00.07/src/kernel/linux-04.02.00.07/Module.symvers
           is missing; modules will have no dependencies and modversions.

/home/huub/AM35x-OMAP35x-LINUX-PSP-04.02.00.07/src/kernel/linux-04.02.00.07/scripts/Makefile.modpost:42: include/config/auto.conf: No such file or directory
make[2]: *** No rule to make target `include/config/auto.conf'.  Stop.
make[1]: *** [modules] Error 2
make: *** [debug] Error 2
huub@Cross:~/dsplink_1_65_02_09/dsplink/gpp/src$ make -s

After I fixed the error I still have the warning.  From a forum: "Module.symvers is generated when the kernel itself is compiled and ought to be provided to the user as part of the kernel build environment package". Did you do that as well ?

It looks like your Linux kernel has not been built.  There should be instructions in your PSP User's Guide for configuring and building the kernel.  I had started with a Linux kernel that someone had configured and built awhile ago, so I did not need to do this step again.

Best regards,

    Janet

Ah ok. I started with "make -s" in dsp/src again, and this time I got the message that /opt/ti-tools/c6000 were not found. After downloading ti_cgt_c6000_7.4.5_setup_linux_x86.bin, installing and adjusting path settings, this error came:

Compiling failure.c...
"failure.c", line 45: fatal error #5: could not open source file "std.h"
  #include <std.h>

Looking in /opt/ti-tools/c6000/cgtools/include, there is no std.h, but there is stdio.h. So what should I do?

Have you installed DSP BIOS?  std.h is included with BIOS 5.x, so it looks like the BIOS installation cannot be found.  Here is something from the DSPLink OMAP3530 Linux Install Guide:

For Linux, the build system shipped with DSP/BIOS™ LINK assumes that the
standalone DSP/BIOS™ is installed in the /opt/‘ti-tools/’ directory on the
<ROOT-DRIVE> and CGTools is installed in the ‘ti-tools/c6000’ directory on
the <ROOT-DRIVE>.

Were you able to build the GPP side dsplinkk.ko and dsplink.lib ok?

Best regards,

    Janet

OK, there' s a missing point. I did download it but somehow forgot to install it.

Another thing is that when compiling the kernel in gpp/src, I get this: $ make ARCH=arm CROSS_COMPILE=/opt/arm-2013.05/bin/arm-none-linux-gnueabi- uImage
make: *** No rule to make target `uImage'.  Stop.

This instruction is from this forum in 2011 by Robert Tivy, but adapter to my CC installation.

These files are made: dsplink.a  dsplink.lib  dsplink.o, but the rest fails.

Just to clarify, when you run 'make' in $DSPLINK/gpp/src, you will be building the DSPLINK kernel module and library.  So it looks like that went ok for you.  You should run the step to build uImage in your kernel source directory, not the $DSPLINK/gpp/src directory.  Here are instructions in the DSPLink OMAP3530 Linux Install guide about uImage:

7.1.2 Kernel
1. Un tar the kernel that comes with the 03.00.00.05 release. Build the kernel
according to the PSP Linux User Guide document. Refer to the PSP u-boot
related documentation on how to build the mkimage utility which is needed
for creation of uImage. Along with the tool chain, location of mkimage
utility should also be there in the path.

Best regards,

    Janet

Now something is unclear to me. So dsplink.o, which is a kernel module, is built. But I'm expecting the kernel driver dsplinkk.ko. Where is that built then ? Or will the be built after I make that kernel ? BTW, my kernel release is 04.02.00.07 but I don't think that will make a difference. Or will it?

OK, I did build that kernel and got a dsplinkk.ko. The file command says it's ELF 32-bit LSB relocatable, ARM. So that sounds ok. But insmod gives "-1: Invalid module format". Further search says it most likely has to to with the difference in kernels.  The built kernel is 2.6.37 and the kernel on the board with DSP is 3.2.0. Can you tell me if my suspicion is correct ? Should both kernels be the exact same version ?

After installing the BIOS in /opt/ti-tools/bios and modifying the path, dsp/src compiled without error as well, but if it works I can't tell yet.

Yes, it sounds like your dsplink.ko is built with a different version of the kernel than the one running on your target.  From http://processors.wiki.ti.com/index.php/Troubleshooting_DSPLink_configuration_issues :

Symptom: I am getting errors when inserting DSPLink module on Linux:

$ insmod dsplinkk.ko dsplinkk: no version for "struct_module" found: kernel tainted.
dsplinkk: version magic '2.6.10_mvl401 preempt ARMv5 gcc-3.4' should be
'2.6.23-davinci1-g1220f74d-dirty mod_unload ARMv5 ' insmod: error inserting 'dsplinkk.ko':
-1 Invalid module format 

Explanation: The error in inserting the module indicates that the DSPLink kernel module was built with a different
kernel version than the version running on the target. In the above example, DSPLink was built with 2.6.10 kernel and the target is running 2.6.23 kernel.

Best regards,

    Janet

OK, I built my dsplinkk.ko against the kernel that came with AM35x-OMAP35x-LINUX-PSP-04.02.00.07 and my ARMv7 (Cortex-A8) is running 3.2.0.54. Is there anything TI offers that is similar to that ? I didn't find any.

Not as far as I know.  Is there any reason for not using the 2.6.37 kernel that you built?

Best regards,

    Janet

Yes, I have to use other software that is not just supported for that hardware/kernel combination but after building it, it won't run. So the way it looks, it's either this or that.

We haven't built or validated DSPLink with a 3.x Linux kernel, but you could try it and see if it works.  If not, you're welcome to post your findings here.  Maybe somebody has tried this and gotten it to work.  I did find this thread:

http://e2e.ti.com/support/embedded/linux/f/354/t/147374.aspx

although much of it may not apply to you since you have a newer version of DSPLink which has the patch to drv_pmgr.c that they refer to in the first few posts.

Best regards,

    Janet

What would you advise to do? Put that 3.2.0 kernel in the same place as the 04.02.00.07 kernel is and try ? I did try the 3.2.0 kernel into another directory and that didn't complete compilation.

I wouldn't necessarily put the 3.2.0 kernel in the same place as the 04.02.00.07.  I would just modify $DSPLINK/gpp/src/Rules.mk and $DSPLINK/make/Linux/omap3530_2.6.mk with the location of the 3.2.0 kernel.  That way you can go back to the 04.02.00.07 kernel if you need to.

When you say that compilation didn't complete when you tried the 3.2.0 kernel, are you referring to the kernel compilation or dsplink compilation?  Do you have the compile errors?

Best regards,

    Janet

OK, that sounds like a good suggestion, although that kernel doesn't work for me.

If referred to the kernel compilation and though I didn't write it down if had something to do with llc. (2 x small L). I tried twice and the compilation stopped at the same. I will do again and let you know.

OK, this is the last output of the kernel compilation:

  CC      init/version.o
  LD      init/built-in.o
  LD      .tmp_vmlinux1
net/built-in.o: In function `llc_sap_put':
/home/huub/linux-source-3.2.0/include/net/llc.h:125: undefined reference to `llc_sap_close'
net/built-in.o: In function `register_8022_client':
/home/huub/linux-source-3.2.0/net/802/p8022.c:49: undefined reference to `llc_sap_open'
net/built-in.o: In function `p8022_request':
/home/huub/linux-source-3.2.0/net/802/p8022.c:32: undefined reference to `llc_build_and_send_ui_pkt'
net/built-in.o: In function `snap_request':
/home/huub/linux-source-3.2.0/net/802/psnap.c:89: undefined reference to `llc_build_and_send_ui_pkt'
net/built-in.o: In function `snap_init':
/home/huub/linux-source-3.2.0/net/802/psnap.c:104: undefined reference to `llc_sap_open'
net/built-in.o: In function `llc_sap_put':
/home/huub/linux-source-3.2.0/include/net/llc.h:125: undefined reference to `llc_sap_close'
make: *** [.tmp_vmlinux1] Error 1
huub@Cross:~/linux-source-3.2.0$

Hopefully you can make something out of it.

We've moved this thread to the Linux Forum since this last error is a kernel build error.  I don't know what these undefined symbols are and why you're getting them, but hopefully someone monitoring this forum can answer.

One thing to consider, is that if you are already running a 3.2.0 kernel on the target, then you must have a built kernel somewhere.  You might ask the person who built this kernel how they did it.

Best regards,

    Janet

The main reason for me to cross-compile and not compile on the target is that it is low on memory. So compiling against a DSP toolkit will take time.

Also, that 3.2.0 kernel is Ubuntu12.04ARM. The toolset for DSPLink is only for x86, right ?

You should build your kernel on a Linux x86 machine, not on the target.  Wasn't the kernel that was loaded onto the target built on x86?  Where did you get your kernel?  Sorry for any misunderstanding.

Best regards,

    Janet

The kernel loaded on the target is not built by me. It's from the ARM version of Ubuntu12.04 so like any current Linux, it has frequent updates from repository.

I have another hardwaredriver on the target. That one was originally written for kernels up to 2.6.34 but I was able to change the sourcecode so it compiles for the 3.x kernel and can be used on ARM and x86. Disadvantage is that with each kernel update, the driver needs to be rebuilt, but since it comes with a Makefile that is hardly an issue and is done on the target in short time.

With the DSPLink driver, rebuilding will be an issue as well of course. It will be a bigger issue as well since, provided that the building errors are solved, the source kernel needs to be downloaded and compiled each time and the driver built. Unless when the DSPLink build succeeds, no more updates will be applied on the target.

I think the DSPLink driver should be built as your hardware driver is.  Each Linux driver needs to be built against the Linux kernel that runs on the target.  So can't you just edit DSPLink's Rules.mk and omap3530_2.6.mk to point to your 3.2.0 kernel?  Do you need to do something similar for your hardware driver?

Best regards,

    Janet

I would like to do just that, but the building of  ../gpp/src is dependent on AM35x-OMAP35x-LINUX-PSP-04.02.00.07/src/kernel/linux-04.02.00.07, right ? This is what's in my Rules.mk:

ifeq ("$(TI_DSPLINK_PLATFORM)", "OMAP3530")
KERNEL_DIR    := ${HOME}/AM35x-OMAP35x-LINUX-PSP-04.02.00.07/src/kernel/linux-04.02.00.07
TOOL_PATH     := /opt/arm-2013.05/bin
endif #ifeq ("$(TI_DSPLINK_PLATFORM)", "OMAP3530")

What is so special about this that it has OMAP35x and PSP in its name?

There are drivers specific to AM35x and OMAP3.  You can check the AM35x-OMAP35x-PSP 04.02.00.07 UserGuide for more information.  But, like I mentioned earlier, you can change KERNEL_DIR to the path of your 3.2.0 and attempt to build DSPLink against it.  Your TI_DSPLINK_PLATFORM will be OMAP3530 if that's what you used for the platform when you ran the perl script, dsplinkcfg.pl.

Best regards,

    Janet

I understand that.  Unfortunately the kernel hasn't succeeded to finish building yet, ending with the same errors. And a successful build of the kernel is according to earlier failures necessary to build DSPLink.

OK, I managed to cross-compile the correct kernel version for arm, and after that build dsplinkk.ko and the examples. Unfortunately, I get the same error while loading dsplinkk.ko: -1: Invalid module format. the "file" command gives the same output for dsplinkk.ko as for the other hardware driver that loads without problem. Any other clues or ideas around ?

Can you try running modinfo on dsplinkk.ko on your target board?  The Linux kernel is looking at a string called "vermagic" that is built into your dsplinkk.ko and comparing it to the kernel's vermagic.  You get this error when the vermagic strings don't match.  Here is example output of modinfo on the syslink.ko driver (I don't have a board set up with dsplink so I used syslink instead):

root@centaurus_fs_2:/jeh/sl-d20# modinfo syslink.ko
filename:       syslink.ko
license:        GPL v2
depends:
vermagic:       2.6.37 mod_unload modversions ARMv7 p2v8
parm:           TRACE:charp
parm:           TRACEENTER:charp
parm:           TRACEFAILURE:charp
parm:           TRACECLASS:charp

You can try this on any of your modules and compare the output.

Best regards,

    Janet

OK, modinfo explains why it doesn't work. For some reason dsplinkk.ko is compiled for ARMv6, while the Cortex-A8 is ARMv7. The other driver shows ARMv7, and is compiled on the target. So the question is where this goes wrong. I cross-compiled the kernel with "make ARCH=arm CROSS_COMPILE=/opt/arm-2013.05/bin/arm-none-linux-gnueabi- uImage". Then I ran "make -s". with the mk files pointed to the same CC directory.

Ok, that's good to know.  I just ran modinfo on my dsplinkk.ko built for OMAP3530, and this is the output I got:

sanbvnc01.sanc.design.ti.com{80}: /sbin/modinfo dsplinkk.ko
filename:       dsplinkk.ko
license:        GPL v2
srcversion:     533BB7E5866E52F63B9ACCB
depends:
vermagic:       2.6.31-rc7-omap1 mod_unload modversions ARMv7

I'll try to figure out where the ARMv7 is coming from.

Best regards,

    Janet

It looks like ARMv6 or ARMv7 in the vermagic string are coming from the kernel.  So this indicates that you are still not building dsplink against the same kernel that you are running on the target.  Did you check the Rules.mk and omap_2.6.mk files in dsplink to put in the correct path to the Linux kernel?

Best regards,

    Janet

Yes, and when configuring the kernel I noticed it had the exact same version as runs on the target: 3.2.0-55.85. The only difference is that "uname -a"  on the target mentions omap. I tried to attach my Rules.mk and omap_2.6.mk (after adding .txt) so you can check but somehow they don't insert well.

I've had problems inserting files before, but renaming with the .txt extension should work.  You can click on the "Preview" tab to view your post as it should appear, and see if the files are actually there.

Best regards,

    Janet

Ok, here's another try.

8662.omap3530_2.6.mk.txt

4111.Rules.mk.txt

These makefiles look ok.  Is the uImage you built in this kernel the same one on your target?  I'm not sure where the built uImage would be, but you could try looking in ${HOME}/linux-source-3.2.0/arch/arm/boot.  You may have built the kernel with a different configuration than the one running on the target.  Even though the kernels are built from the same source, if the configuration is different, a dsplinkk.ko built with a different configuration will not install.

Best regards,

    Janet

If the configuration of the kernel must be the same, then I should better use this kernel on the target and build the other driver against this kernel as well, although the ARMv6 issue must be solved first. Also, the kernel on the shows omap with "uname -a" and I haven't found out yet how to see the vermagic of the kernels.

Could you please give a follow-up on the reason why dsplinkk.ko was built for ARMv6 instead of ARMv7 ?

Thank you.

I believe dsplinkk.ko is built for ARMv6 because of the way the kernel it is being built against has been configured.  I'm not familiar with this kernel, but there must be some documentation there on how to configure it to build for ARMv7.

Best regards,

    Janet

Ok, I checked on that. Configuring the kernel itself doesn't lead to a specific ARM version but the use of compilers does. It turns out that gcc versions starting from 4.3 are ARMv7 compatible. Mine is 4.6.3. Then I also checked my toolchain and specifically CodeSourcery. This is 2013.05 arm-none-linux-gnueabi-gcc- 4.7.3. So as far as I can see all of this should be able to compile for ARMv7.

Another check learned that CodeSourcery Lite doesn't support armhf but I don't know if that matters in this case of ARMv6/ARMv7.  Will check after changing the mk files to the toolchain that comes with Ubuntu and try again.

I changed the toolchain to the one coming from the Ubuntu repository, and after adjusting the mk files accordingly, I rebuilt the kernel and dsplinkk.ko and ended up with ARMv6. I compiled first using arm-linux-gnueabi which gave ARMv6, then using arm-linux-gnueabihf which gave the same. I also checked for the gcc versions of the toolchain: 4.4, 4.5 and 4.6.

In a post somewhere I noticed the option -march=ARMv7. This is not in the mk files. Is it possible to add this somehow ?

I think the -march=ARMv7 should come out of the kernel configuration.  You could confirm that your kernel is not configured for ARMv7 by looking at the generated autoconf.h file.  I'm not sure where yours would be, but for the AM35x-OMAP PSP, it's in the directory:

AM35x-OMAP35x-LINUX-PSP-04.02.00.07/src/kernel/linux-04.02.00.07/include/generated

In our autoconf.h file we have #define CONFIG_CPU_V7 1

Can you check what is in your autoconf.h?  Don't modify this file directly since it's auto-generated.

Also, in the AM35x-OMAP PSP, there are a bunch of default kernel configurations for different platforms, in the directory AM35x-OMAP35x-LINUX-PSP-04.02.00.07/src/kernel/linux-04.02.00.07/arch/arm/configs

We have a script for building the kernel using the omap3530_evm_defconfig:

#!/bin/sh

set -x
cp mkimage linux-04.02.00.07
cd linux-04.02.00.07
PATH=$PATH:/db/toolsrc/library/vendors2005/cs/arm/arm-2009q1-203/bin:.
make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- omap3_evm_defconfig
make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- Image
make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- uImage
cp arch/arm/boot/uImage ..

Is this similar to how you are building your kernel?  You may also want to post general questions about building the Ubuntu kernel for OMAP3530 to the Ubuntu forum.

Best regards,

    Janet

In my autoconf.h I have: #define CONFIG_CPU_V7 1

In my /linux-source-3.2.0/arch/arm/configs, I don't have an omap3 defconfig, only omap1 and omap2plus.

What I read at http://omappedia.org/wiki/Building_Linux_OMAP_Kernel, the defconfig is not generated but should already be there. Since it is not in my source, I guess I will be unable to build it for omap3 with the kernel source I have now. Copying it from your source would take a lot of changes, if possible at all.

OK, I downloaded a new kernel, and this again only had defconfig for omap1 and omap2plus. So standard, dsplink will not build for ARMv7. If I use your omap3_beagle defconfig with this new 3.8 kernel, will this build dsplinkk.ko for beagleboard-xm with DM3730 as well, since this is the DM3730 ?