For a lpc3250 board, we had to developer a Linux kernel module to control the PWM output. I've created a 'helper' module which contains methodes like PMW1_ENABLE which set the correct bit at 1.
Unfortunately I run into problems when I create multiple .c and .h files. When I put all the code in just 1 file, the solution works fine. When I split it nicely in additional .c and .h files, something weird is happening. Even just printk statements do not show up on the console.
Most weird part, during cross compiling, no errors are shown so it looks like the binary is ok but it isn't.
Does this sound familiair? Could it be an issue with my makefile?
ARCH := arm
CROSS_COMPILE := /usr/local/xtools/arm-unknown-linux-uclibcgnueabi/bin/arm-linux-
CC= $(CROSS_COMPILE)gcc
obj-m := pwmdriver.o
pwmdriver-objs := pwmhelper.o pwmdriver.o
KDIR := /home/student/felabs/sysdev/tinysystem/linux-2.6.34
WORKINGDIRFIXED := /home/student/PRT/5_AssigPWM
export
all:
$(MAKE) -C $(KDIR) M=$(WORKINGDIRFIXED) modules
clean:
$(MAKE) -C $(KDIR) M=$(WORKINGDIRFIXED) clean
Related
sorry if this is noob question.
In my c function, I use a macro defined in btrfs_inode.h file.
When I include the file directly to path:
#include "/data/kernel/linux-4.1.21-x86_64/fs/btrfs/btrfs_inode.h"
the project compiles with no errors, I dont want to use that direct path, I download the package kernel-source that contains this header file.
The location of the header file after installing the package is at: /usr/src/linux/fs/btrfs/
So I change the #include to :
#include "btrfs_inode.h"
and i wish to add "/usr/src/linux/fs/btrfs/" as a location that it will search for "btrfs_inode.h" and get: "/usr/src/linux/fs/btrfs/btrfs_inode.h"
I get error:
/bin/sh: 1: /usr/src/linux/fs/btrfs/: Permission denied
I am running make as root.
Makefile:
all:: user
obj-m += my-driver.o
# Make arguments
PWD := $(shell pwd)
INCLUDE := -I/usr/include/asm/mach-default/
KDIR := /lib/modules/$(KERNEL_HEADERS)/build;/usr/src/linux/fs/btrfs/
# Add flags to auto build
EXTRA_CFLAGS +=-D__Linux -std=gnu99
# extra warning flags
ccflags-y := -Wall -Wextra #-pedantic
# disable some warning flags
ccflags-y += -Wno-unused-parameter
# make all warnings into errors
ccflags-y += -Werror
# increase verbosity
KBUILD_VERBOSE := 1
all::
$(MAKE) -C $(KDIR) $(INCLUDE) SUBDIRS=$(PWD) modules
So first off, avoid making as root when possible. Next, you added your directory to KDIR, not to INCLUDE (and then you pass KDIR to the -C argument of make, so you would have a line that looks like:
make -C /lib/modules/$(KERNEL_HEADERS)/build;/usr/src/linux/fs/btrfs/ ...
Notice the semicolon, which bash will interperet as the end of a command, and beginning of the next command. So it tries to run make, and then tries to run /usr/src/linux/fs/btrfs/, and gives you your warning. What you should have is something like:
# Make arguments
PWD := $(shell pwd)
INCLUDE := -I/usr/include/asm/mach-default/
INCLUDE += -I/usr/src/linux/fs/btrfs/
KDIR := /lib/modules/$(KERNEL_HEADERS)/build
(you want a -I in front of the path to tell make to search for include files in that directory).
EDIT
You are also not passing the -I to your $(CC) or $(CXX) commands. To do this, you have a couple of options, though I'll suggest the least error prone one: First of all, you have to pass the flags to the sub make. To do this, first add the line:
export INCLUDE
to your main makefile. Your submake now has access to the variable $(INCLUDE). From there, if you have an explicit rule to compile the CC files, you can add $(INCLUDE) to the compile command. Something like
%.o: %.c
$(CC) $(CFLAGS) $(INCLUDE) -o $# $<
or, if you are using the built-in implicit rules, simply add $(INCLUDE) to CPP_FLAGS:
CPP_FLAGS += $(INCLUDE)
(note, CPP_FLAGS are used by default for both c and c++ compilation).
Finally, do not pass $(INCLUDE) to your make command. If you do, it tells make to look look for sub-makefiles in those directories (not gcc...).
From what I could understand via this question, you can add multiple -I flags to your Makefile.
I would like to compile a simple character device module depending on a custom header. The folder is thus organized,
+ mymod.c
| customized-header.h
| customized-header.c
| Makefile
In mymod.c, the header is thus used,
#include "customized-header.h"
In Makefile:
obj-m := mymod.o
mymod-objs := customized-header.o
KVERSION = $(shell uname -r)
PWD = $(shell pwd)
all:
make -C /lib/modules/$(KVERSION)/build M=$(PWD) modules
clean:
make -C /lib/modules/$(KVERSION)/build M=$(PWD) clean
Everything should work fine, the module gets compiled without problem, I can load the module through sudo insmod, but the module doesn't work properly. When I checked nm mymod.ko, there are a lot of vars and functions are missing. It looks as if it stopped after linking customized_header.o. If I remove this header and its function, say no header function calls from the module, it compiles perfectly with desired result.
Could you see what went wrong here?
The problem resides in the Makefile. Due to the link here, I changed it into
obj-m: mymodko.o
mymodko-obj: customized-header.o mymod.o
It now works fine. So the question was the naming of module object. We need to specify different names as in this case mymodko.o and mymod.o.
I am pretty familiar with Makefiles and kernel modules, but recently I got a problem in my Makefile that doesn't make any sense -- on using wildcards.
To demonstrate this, I am compiling a hello world kernel module from scratch.
The directory structure is like this:
hello_mod/
|
--- hello.c
|
--- Makefile
Here is the actual makefile :
CFILES := $(wildcard hello.c*)
#CFILES := hello.c
OBJS := $(CFILES:.c=.o)
KSRC := /lib/modules/$(shell uname -r)/build
obj-m += hello_world.o
hello_world-y := $(OBJS)
all:
#echo $(CFILES)
$(MAKE) -C $(KSRC) M=$$PWD modules
clean:
$(MAKE) -C $(KSRC) M=$$PWD clean
.PHONY: clean
The problem is that even though the commented $(CFILES) and the uncommented $(CFILES) are exactly the same, the build fails on using the first $(CFILES) with the following error:
*** No rule to make target `/home/test/hello_mod/hello_world.c', needed by
/home/test/hello_mod/hello_world.o'. Stop.
If the commented $(CFILES) is used, it works perfectly.
If someone wants to test this out, I'm including the source for the hello world source which is hello.c :
#include <linux/kernel.h>
#include <linux/module.h>
static int mod_init()
{
printk("Hello\n");
return 0;
}
static void mod_exit()
{
printk("Bye world\n");
}
module_init(mod_init);
module_exit(mod_exit);
Does anyone know why it is behaving as such? And I need to use wildcards in the makefile. Any help will be appreciated.
There are two makes happening here. The first really only relies on the KSRC variable and the recursive make call. The second make only needs the CFILES, OBJS, obj-m, and hello_world-y variables, and doesn't make use of the all: target. So your debug is showing that CFILES is set correctly for the first Make, where it's not being used, and is not showing it in the second make, where it is.
You're wildcard expanding from a different directory, and not picking up the right files. Try this for CFILES:
CFILES := $(notdir $(wildcard $M/hello.c*))
SRCDIRS := subdir1 subdir2
CFILES := $(strip $(foreach dir,$(SRCDIRS),$(wildcard $(dir)/*.c)))
should probably be (see foreach example in documentation)
SRCDIRS := subdir1 subdir2
CFILES := $(foreach dir,$(SRCDIRS),$(wildcard $(dir)/*.c))
(no need to $(strip), .... or perhaps
CFILES := $(wildcard {subdir1,subdir2}/*.c)
Use remake, probably as remake -x, to debug such issues.
I am writing a simple device driver in Linux. In the makefile we normally write first line as
obj-m += hello.o
where hello is the module written. I have seen in other makefiles the symbol += being replaced by := and some others. What is significant difference between the two and also what are the possible options?
Actually, Kbuild resets obj-m along with some other variables (see scripts/Makefile.build) before including user Makefile, so there is no difference between += and := assignments (assuming that there is the only hello.o line).
Personally I would prefer appending assignment (+=). This prevents some stupid errors like the following:
obj-m := hello.o
obj-m := world.o
If the last line is a copy-paste of the first one and you forget to change the assignment type to +=, then you'll get only world.o compiled (without hello.o).
I would also suggest you to read Kbuild documentation about how to write module makefiles.
I'm working on a Linux kernel module for a 2.6.x kernel and I need to view the assembly output, though it's currently being done as a temporary file an deleted afterwords. I'd like to have the assembly output mixed with my C source file so I can easily trace where my problem lies. This is for an ARMv6 core and apparently objdump doesn't support this architecture. I've included my makefile below.
ETREP=/xxSourceTreexx/
GNU_BIN=$(ETREP)/arm-none-linux-gnueabi/bin
CROSS_COMPILE := $(GNU_BIN)/arm-none-linux-gnueabi-
ARCH := arm
KDIR=$(ETREP)/linux-2.6.31/
MAKE= CROSS_COMPILE=$(CROSS_COMPILE) ARCH=$(ARCH) make
obj-m += xxfile1xx.o
all:
$(MAKE) -C $(KDIR) M=$(PWD) modules
clean:
$(MAKE) -C $(KDIR) M=$(PWD) clean
Objdump does support that architecture. Your executable will be called arm-none-linux-gnueabi-objdump
Assuming gcc and the gnu assembler a more readable output than objdump can be had. Tell the assembler to retain its intermediate code using flags to gcc:
-Wa,-alh=basename.s
And to get basename to be the actual source filename you need to tell make:
-Wa,-alh=$<.s
which will leave piles of foo.c.s files laying around your source directory. The big problem here is that the way gcc works it uses temporary files between code generation and assembly. I can't find a way to make gcc save its intermediates but the assembler is happy to stash a listing for you.
Getting that argument into the Makefile CFLAGS is left as an exercise for the reader (because I kinda hate "make" and hate "gnu info" even more.
To get an assembly language listing of my Linux kernel modules, I added the assembler switches to the kernel scripts/Makefile.build.
#cmd_cc_o_c = $(CC) $(c_flags) -c -o $(#D)/.tmp_$(#F) $<
cmd_cc_o_c = $(CC) $(c_flags) -c -Wa,-alh=$<.lst -o $(#D)/.tmp_$(#F) $<
You could try the flag "-save-temps" to gcc.
It works for me in my embedded project, I haven't tried it on kernel builds.
The proper way is likely to add target dependencies in your module makefile / Kbuild file:
always-m += basename.s
(As kbuild has the proper targets to generate the .s files)
If you are lazy as I am, this could look like:
MOD_NAME := some_module_name
myunits := file1 file2 file3 ... and many more... without .c extension
obj-m := $(MOD_NAME).o
$(MOD_NAME)-y := $(addsuffix .o,$(myunits))
# Comment/uncomment to generate assembly / preprocessor output
always-m += $(addsuffix .s,$(myunits)) $(MOD_NAME).mod.s
always-m += $(addsuffix .i,$(myunits)) $(MOD_NAME).mod.i
(2 bonuses here: assembly for the generated module meta-registration file, and the preprocessor output)