I see that in the directory kernel/arch/arm there are a lot of board files, which I am using as reference for my i2c driver. I have the following code in a directory I made called ./mach-foo and I want to add it to the make file so my driver will work.
Here are the contents:
./mach-foo/foo-dummy.c has module init and exit and a basic i2c struct and probe, does printk's to confirm calls
$ cat ./mach-foo/Makefile
obj-m += foo_dummy.c
Now I need to know how mach-foo will get compiled or built or what ever (my understanding is limited). Looking at the makefile already in place in kernel/arch/arm/Makefile I see that other folders are added via a line similar to
machine-$(CONFIG_FOO_BAR) := foobar
I am familiar with the operation of Kconfig, and that it decideds what come with CONFIG_FOO_BAR
I was hoping that I could just hard-code a line like
machine-m :=foo does this work?
I saw that the Makefile automatically appends mach- to the name here, so are machine-m or machine-y valid?
Also, do I need := or +=?
Related
I wanted to call a C function defined in arm-tf (arm trusted firmware) from a u-boot assembly code. That assembly code of u-boot is arch/arm/lib/gic_64.S. The build process for this doesn't work out as I wanted so I ask it here with simple example.
In u-boot build tree, there is the directory arch/arm/lib. I added a directory arch/arm/lib/testd and put testf.c there. testf.c is just printing a string. In arch/arm/lib/Makefile, I added
libs-y += arch/arm/lib/testd
and in arch/arm/lib/testd/Makefile, I added
obj-y += testf.o
When I do make in u-boot root directory, I find nothing is made under arch/arm/lib/testd. But if I do make arch/arm/lib/testd/testf.o, that file is made. I saw this question but it doesn't help. Actually I guess I should see spl/arch/arm/lib/testd/{built-in.o, testf.o} if it was successful(because I'm building u-boot-spl).
I will be very grateful if anyone could tell me how I should do it. Thanks!
It looks like, if I add in arch/arm/lib/Makefile only
obj-y += testd/
Then by doing make I see arch/arm/lib/testd/testf.o and spl/arch/arm/lib/testd/{build-in.o,testf.o} generated.
The key part was the testd/ not testd.
I want to add custom syscall to freebsd(school work). I google hundreds of time. there is no right solution for it.
my homework is: "Add custom syscall to freebsd kernel and recompile the kernel and use it".
finally I find that I should follow instructions in these two pages:
1 : http://www.onlamp.com/pub/a/bsd/2003/10/09/adding_system_calls.html
then
2: https://www.freebsd.org/doc/en/books/handbook/kernelconfig-building.html
will it shows errors in compile time:
<sys/parma.h> no such file or directory
<sys/kern.h> no such file or directory
<sys/syscallargs.h> no such file or directory
I removed these three header include form my file then recompile it. now shows other errors like: MAXCPU undeclered in pcpu.h file.
what I missed? how can I do my school work?
NOTE: I use freebsd8 in vbox
Look at what the error messages say; the files don't exist.
The first include file is a typo; it's param.h, not parma.h!
There is no kern.h. Maybe you mean sys/kernel.h?
Idem for syscallargs.h. Do you perhaps mean syscall.h?
You can find header files with e.g:
find /usr/src/sys/ -type f -name '*.h'|grep 'sys/.*kern.*\.h'
/usr/src/sys/ofed/include/linux/kernel.h
/usr/src/sys/dev/netmap/netmap_kern.h
...
Update: More important is determining which includes you actually need.
FreeBSD has pretty good documentation. If you want to use a kernel function or data-structure, it is probably covered in section 9 of the manual pages.
You can list all the manual pages in that section with ls /usr/share/man/man9/ | less. Or you can use the apropos command.
Since you want to implement a syscall, start with e.g.
apropos syscall
It will return:
SYSCALL_MODULE(9) - syscall kernel module declaration macro
syscall(2), __syscall(2) - indirect system call
It seems to me that the first one could be relevant to your assignment. (The second one is how to call a system call from user space.) So read it with man SYSCALL_MODULE. Or read it online.
Note that:
A minimal example for a syscall module can be found in
/usr/share/examples/kld/syscall/module/syscall.c.
That example should be enough to get you started on writing your own system call module...
Well take a look at share/examples/kld/syscall for a complete implementation as a module.
Adding a new file to teh kernel is left as an exercise for the reader.
Here is a hint: find the newest added file within kern/* subdir AND CHECK WHAT COMMITS WERE DONE TO MAKE IT COMPILE.
In fact you could have done exactly the same with syscall: FIND THE NEWEST ADDED SYSCALL AND CHECK HOW IT WAS ACHIEVED.
All this is available in svn/git repository history.
I wrote a basic character driver for beagle-bone which prints two message in 1 second interval via a workqueue and a tasklet using printk.
At first i build it as module driver, generated .ko file, load it using insmod command and the print is coming when viewed via dmesg.
Then i built as inbuilt driver and load the uImage and after bootup i checked the dmesg prints. But there is no prints.
In the .config file
CONFIG_MY_DRIVER=y
So its taken as built in driver i think.
How can i confirm whether its actually built in the final image. No error was reported while building.
Is there any additional steps to be done for loading the build in driver.
Please pardon me if i went wrong on any basics. I am really new to linux.
This means that you added it probably somewhere to Kconfig file:
"CONFIG_MY_DRIVER=y"
but, Have you added it to Makefile? It works like that, then kernel during a building an Image, takes all of this directives "CONFIG_*" and use it to build particular source files from Makefile.
Example:
cat fs/ext2/Makefile
ext2-$(CONFIG_EXT2_FS_SECURITY) += xattr_security.o
cat fs/ext2/Kconfig
config EXT2_FS_SECURITY
bool "Ext2 Security Labels"
depends on EXT2_FS_XATTR
so in this example above if your source file is xattr_security.c then you should get xattr_security.o file in fs/ext2 dir, when this is build. You should also see it if your file is build, during a compilation process.
So I'm working with ucLinux under the NXP LPC1788 processor (ARM-CortexM3, no MMU). The ucLinux port was orignally done by Emcraft Systems.
The 1788 has 512KiB of onboard flash (called eNVM) which is faster to access than the rest of memory connected via the external memory controller. Emcraft's linker script has a portion where you can relocate critical parts of the kernel to this eNVM area. I'm using 80K for the bootloader so I have 432K free to stuff with as much kernel as I can.
So the linker script, vmlinux.lds.S, has a portion that begins like this:
#ifdef CONFIG_KERNEL_IN_ENVM
_envm_loc = .;
.envm ENVM_PHYS_OFFSET + CONFIG_KERNEL_IN_ENVM_OFFSET * 1024 : {
_envm_start = .;
#if CONFIG_KERNEL_IN_ENVM_SIZE>0
__exception_text_start = .;
*(.exception.text*)
*(.exception.rodata*)
__exception_text_end = .;
SCHED_TEXT
LOCK_TEXT
KPROBES_TEXT
usr/built-in.o(.text)
usr/built-in.o(.rodata*)
init/built-in.o(.text)
init/built-in.o(.rodata*)
mm/built-in.o(.text)
mm/built-in.o(.rodata*)
...and so on. As you can see, entire subdirectories are being pulled in via their built-in.o object file.
As I get closer and closer to the end of the flash space, I'd like to have a bit more control over what gets linked here. drivers/built-in.o, for example, won't fit in the free space but if I could get drivers/usb and drivers/input here, that would help a lot.
If I modify the linker script to have just those portions, like this:
drivers/usb/built-in.o(.text)
drivers/usb/built-in.o(.rodata*)
drivers/input/built-in.o(.text)
drivers/input/built-in.o(.rodata*)
then I get duplicate symbol errors when drivers/built-in.o gets linked. I can't see where that happens exactly, so that's part of the problem I think.
So the question: Is there a way to link individual built-in.o files to different regions without linking the master .o built at the top of the directory?
I've put the whole linker file at http://pastebin.com/qcj6rHme if anyone wants to take a look.
Thanks!
If you're going to link usb and input directly, drivers/built-in.o should not include them. Modifying Kbuild to build the subdirs but not include them is a bit tricky; those two elements will have to filtered out of obj-y where drivers/built-in.o is generated -- if they aren't included in obj-y they won't get built at all.
I am using a command in the proc file system which is the following
echo 0 > /proc/sys/net/ipv4/ip_forward
Note: I don't want to know the basic of the command written above, I want what all happens when it goes inside the kernel. As, I want to implement one of the /proc file.
Now if I want to trace the code right from when the 0 is echoed in the file-system then how to go about it. I mean if I want to trace what happens when I do this.
I want to see where in the kernel code this 0 is accepted and in which value does it get stored inorder to make the changes. Please, can somebody tell what all happens when you call this command. I want in detail explain. I don't want the description of the command.
Any related article on how it changes the kernel parameters is also fine.
I have read this but, not explained there. http://www.linuxjournal.com/article/8381
Thanks
search through linux tree (especially network stack) for create_proc_entry function. Figure out what file creates ip_forward (it must be in ip4v drivers) from name passed to create_proc_entry.
When you find the file, look at where proc_dir_entry structure is created and what functions are assigned to its read_proc, write_proc members.