All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Mack <daniel@caiaq.de>
To: buildroot@busybox.net
Subject: [Buildroot] building kernel modules
Date: Mon, 9 Nov 2009 07:58:15 +0100	[thread overview]
Message-ID: <20091109065815.GZ14091@buzzloop.caiaq.de> (raw)
In-Reply-To: <4AF7A886.8000703@cs.ucsb.edu>

On Sun, Nov 08, 2009 at 09:28:38PM -0800, Roman Chertov wrote:
> So I figured out how to get the external kernel module compilation
> going.  The cross compilation works fine, but the linking fails as there
> are two undefined symbols.  Also, there is a strange error regarding
> /usr/local/src/mv-kernel/arm-none-linux-gnueabi/bin/arm-none-linux-gnueabi-gcc
> 
> However, the compilation proceeds even with that error.
> 
> [rchertov at number2 src]$ sh make.sh
> make:
> /usr/local/src/mv-kernel/arm-none-linux-gnueabi/bin/arm-none-linux-gnueabi-gcc:
> Command not found
> make: Entering directory
> `/proj/tools/buildroot-2009.08/project_build_arm/uclibc/linux-2.6.29'
>   LD [M]  /proj/tools/can_driver/musec_can/src/musec_can.o
>   Building modules, stage 2.
>   MODPOST 1 modules
> WARNING: "__bad_udelay"

This error is due to an illegal usage of udelay() in the module code.
Calling this function at all is frowned upon, and calling it with too
big values fail[*] the kernel compilation for very good reasons. You
should rather use schedule_timeout() or timer functions to give CPU time
to do something useful while waiting for so long. But, without knowing
the sources, it's impossible to give any further hints.

([*] the way they implemented that depending on compile-time constraints
     is very nice, btw. Dig through the headers if your curious ;))

> [/proj/tools/can_driver/musec_can/src/musec_can.ko] undefined!
> WARNING: "__aeabi_uldivmod"
> [/proj/tools/can_driver/musec_can/src/musec_can.ko] undefined!
>   LD [M]  /proj/tools/can_driver/musec_can/src/musec_can.ko
> make: Leaving directory
> `/proj/tools/buildroot-2009.08/project_build_arm/uclibc/linux-2.6.29'
> 
> 
> I believe that the linker uses libc instead of uclibc which was compiled
> for ARM, and hence the linking step is failing.  I would appreciate it
> if somebody could point out which linker setting I am missing.  Below, I
> listed all of the variables that I redefined for the build.
> 
> ARCH=arm
> CROSS_COMPILE=/<br_dir>/build_arm/staging_dir/usr/bin/arm-linux-uclibcgnueabi-

These two look sane.

> AS      =$(CROSS_COMPILE)as
> LD      =$(CROSS_COMPILE)ld
> CC      =$(CROSS_COMPILE)gcc
> CPP     =$(CC) -E
> AR      =$(CROSS_COMPILE)ar
> NM      =$(CROSS_COMPILE)nm
> STRIP   =$(CROSS_COMPILE)strip
> OBJCOPY =$(CROSS_COMPILE)objcopy
> OBJDUMP =$(CROSS_COMPILE)objdump
> 
> 
> EXTRA_CFLAGS=-I /<br_dir>/project_build_arm/uclibc/linux-2.6.29/include\
> -I<br_dir>/build_arm/staging_dir/usr/lib/gcc/arm-linux-uclibcgnueabi/4.3.3/include
> 
> LDFLAGS=-L/<br_dir>/build_arm/staging_dir/lib
> 
> ...

But don't need all the rest. All you need to provide is ARCH=arm and
CROSS_COMPILE=..., the rest is done automatically. The kernel's build
system is very self-contained and the sources come with all kind of
headers and libraries. No need to point it to any external resources.

Following that should make the 2nd error go away.

Daniel

  reply	other threads:[~2009-11-09  6:58 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-05 21:59 [Buildroot] building kernel modules Roman Chertov
2009-11-09  5:28 ` Roman Chertov
2009-11-09  6:58   ` Daniel Mack [this message]
2009-11-09 22:38     ` Roman Chertov
2009-11-09 22:59       ` Daniel Mack
2009-11-10 17:18         ` Roman Chertov
2009-11-11  0:58           ` Daniel Mack
2009-11-11 19:52             ` Roman Chertov
  -- strict thread matches above, loose matches on Subject: below --
2008-06-24 17:00 Brian Beattie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20091109065815.GZ14091@buzzloop.caiaq.de \
    --to=daniel@caiaq.de \
    --cc=buildroot@busybox.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.