am new in linux and kernel compiling. I would like to add SPI support in my device - its stm32f429-disco evaluation board with LCD. I have found whole project here: https://github.com/jserv/stm32f429-linux-builder, compiled it and it works ( kernel source is https://github.com/robutest/uclinux ), but I don't know how to set CONFIG_STM32_SPI1 flag ( https://github.com/robutest/uclinux/blob/master/arch/arm/mach-stm32/spi.c line:45 ) in https://github.com/jserv/stm32f429-linux-builder/blob/master/configs/kernel_config.
I've checked https://github.com/robutest/uclinux/blob/master/arch/arm/mach-stm32/Kconfig and https://github.com/robutest/uclinux/blob/master/arch/arm/mach-stm32/Makefile and config flags looks ok. Adding manually CONFIG_SPI_STM32 and CONFIG_STM32_SPI1 to "kernel_config" doesn't work. Compiler removes both flags from this file.
Why CONFIG_STM32_SPIx and CONFIG_SPI_STM32 entries are not even visible like other entries "# CONFIG_STM32_USART1 is not set" in the original "kernel_config" file ( I also can't find STM32-SPI in 'make menuconfig' )?
From what you provide I suggest to add to your defconfig, namely kernel_config file from project you are using:
CONFIG_SPI=y
CONFIG_SPI_STM32=y
CONFIG_STM32_SPI1=y
Related
I had a question about adding a new machine in Yocto.
I am trying to add both a new layer in Yocto, and a new machine. The machine is based on Atmels SAMA5D27-SOM1-EK-SD evaluation board. I want to enable another UART for this board.
I cloned the kernel source for this board (linux-at91) and added another DTS file based off of at91sama5d27-som1-ek-sd.dts file. I made the changes to enable UART0. I then added this new DTS file to the Makefile in linux-at91/arch/arm/boot/dts . I made a patch to save these changes.
I'm using meta-atmel layer and was following instructions outlined here to build the image for this board.
I have defined another layer that will act as the new Yocto layer that defines my custom machine. I have added some .bbappend files in recipes-kernel to add a patch (which adds a new dts file to the linux at91 kernel source) and to add our custom machine as a compatible machine. My understanding was that we could continue to use the definitions in the meta-atmel layer, but add .bbappend files in the meta-axon layer in the same path, and that would apply the changes that we want.
I have done the same for the recipes-bsp directory. In the meta-axon layer, all the .bbappend files in recipes-bsp only add our custom machine to the list of compatible machines.
However, when I go ahead and build, I get this error:
NOTE: Resolving any missing task queue dependencies
ERROR: Nothing PROVIDES 'at91bootstrap-sam-ba'
at91bootstrap-sam-ba was skipped: incompatible with machine axon-ft3-sp-machine (not in COMPATIBLE_MACHINE)
I'm confused because the recipe file that defines at91bootstrap-sam-ba in meta-atmel does not mention any compatible machines, so I would want to use it from the meta-atmel layer without changing it at all. (edited)
It actually does mention compatible machines.
In at91bootstrap-sam-ba recipe[1], you can find the following line:
require at91bootstrap_${PV}.bb
Let's check out in this recipe then[2]:
COMPATIBLE_MACHINE = '(sama5d3xek|sama5d3-xplained|sama5d3-xplained-sd|at91sam9x5ek|at91sam9rlek|at91sam9m10g45ek|sama5d4ek|sama5d4-xplained|sama5d4-xplained-sd|sama5d2-xplained|sama5d2-xplained-sd|sama5d2-xplained-emmc|sama5d2-ptc-ek|sama5d2-ptc-ek-sd|sama5d27-som1-ek|sama5d27-som1-ek-sd|sama5d2-icp-sd|sam9x60ek|sam9x60ek-sd|sama5d27-wlsom1-ek-sd)'
Using bitbake at91bootstrap-sam-ba -e would show you that, indeed, COMPATIBLE_MACHINE is set and would even tell you where it was set.
P.S.: In some cases, it might actually be a good idea for your custom machine to require the original machine on which it is based (e.g. sama5d27-som1-ek-sd) and make the name of the original machine part of MACHINE_OVERRIDES so that you don't have to add a bbappend for each recipe with a COMPATIBLE_MACHINE. Be careful with the order in MACHINE_OVERRIDES, it is evaluated from right to left with rightmost OVERRIDES being of the highest priority. (Use bitbake -e <recipe> to be sure it's correctly set).
[1] https://github.com/linux4sam/meta-atmel/blob/master/recipes-bsp/at91bootstrap/at91bootstrap-sam-ba_3.9.2.bb#L1
[2] https://github.com/linux4sam/meta-atmel/blob/master/recipes-bsp/at91bootstrap/at91bootstrap_3.9.2.bb#L5
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.
OK, so I have this embedded kernel whose network card used to work fine with the LLTEMAC option. The new one with LL_TEMAC doesn't. I still see the code with LLTEMAC in the source, but not in the available option in the .config file:
$ ack-grep LLTEMAC
drivers/net/ethernet/xilinx/xilinx_lltemac/Makefile:10:obj-$(CONFIG_XILINX_LLTEMAC) := xilinx_temac.o
drivers/net/ethernet/xilinx/xilinx_lltemac/xlltemac_main.c:2: * Xilinx Ethernet: Linux driver for the XPS_LLTEMAC core.
drivers/net/ethernet/xilinx/xilinx_lltemac/xlltemac_main.c:452:#ifdef CONFIG_XILINX_LLTEMAC_MARVELL_88E1111_RGMII
...
include/linux/xilinx_devices.h:83:/* LLTEMAC platform data */
Is there a way to compile the kernel with this removed option ?
Simply adding CONFIG_XILINX_LLTEMAC=y CONFIG_XILINX_LLTEMAC_MARVELL_88E1111_GMII=y to the .config file does not do anything as the dislaimer states: # Automatically generated file; DO NOT EDIT.
Thanks.
Why not just update this individual driver to understand the new configuration option?
I'm developing a device driver for embedded linux(ARM).
How can I compile the KO file generated as a part of the kernel,
in a way that the module will be loaded in boot ?
this is the first time I need to compile the driver into the kernel and not as a loadable module. so I'm not sure how to do it.
Thanks,
Ramon.
For your first question, I assume that you want to build your driver statically into the kernel image(not as a module). First, you select a directory in drivers directory where you want to put your driver files. Assume you want to put your files in drivers/char/. Copy your files into this directory. There will be a Kconfig file in the drivers/char/ directory, open it and add an entry like this in the before the endmenu.
config MYDRIVER
bool "This is a driver for something"
default n
help
This is a test driver.
Save the file and open Makefile in the same directory. Goto end of the file and add the following entry.
obj-$(CONFIG_MYDRIVER) += mydriver.o
That's it you have added the file to the kernel tree. Now, as usual, do make menuconfig and select MYDRIVER.
See this Kernel Compilation article for more info.
You need to build your device driver as a built-in. You can either edit your kernel .config file manually and change "=m" to "=y" for the CONFIG option that belongs to your module, or use make menuconfig to change <M> to <*> for your device driver.
before -> <M> Your Device Driver Name Here
after -> <*> Your Device Driver Name Here