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.
Related
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.
I am currently facing a problem in locating the syscall_table.S file in my arch/x86/kernel/ directory. In the online tutorail that i am following, it is gievn that i will find the file in this location. I am using linux-3.11.10. Please tell me how to locate this file. However, I have found this file in some other folders. If i were to modify one of these,which one should I modify ?
The following folders have syscall_table.S :
arch/microblaze/kernel
arch/m32r/kernel
arch/avr32/kernel
arch/parisc/kernel
Your question isn't very specific about what exactly you are trying to do.
sys_call_table is defined in arch/x86/kernel/syscall_64.c
The syscall entry is located in arch/x86/kernel/entry_64.S
routines are associated with their syscall number in include/uapi/asm-generic/unistd.h and arch/x86/syscalls/syscall_64.tbl
You might also want to look at include/linux/syscalls.h.
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 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 +=?
In qemu, when we are giving instructions it gets converted to the machine code for the particular architecture. I would like to write this code to a file. For that I think in cpu-exec.c the generated code is obtained (it is returned for execution). How will i copy it to a file?
/qemu-0.14.0/cpu-exec.c
find cpu_gen_code() # translate-all.c:57,
-to->
# line104: log_disas(tb->tc_ptr, *gen_code_size_ptr);
try to hack it.