i want to compile a custom linux kernel for myself. because i dont know every option of kernel therefore i am looking for a good default config for start.
You should check out KernelCheck. It's basically an app that will help you figure out what kernel options are worth tweaking for your particular system. It will also automatically download, compile and install the selected kernel for you.
If you have a good running kernel that has builtin support for stored configuration (i.e. /proc/config.gz exists), then you could copy that kernel configuration and use it as a starting point:
zcat /proc/config.gz > /path/to/kernel/source/.config
Look in the repository of the Linux distribution you are using, they often have a generic or a huge kernel .config, those are the "best choices".
From the Linux kernel source tree, type make help and look for the lines that include defconfig. Default configurations for various platforms are typically included here. Once you find the one that matches your platform, type, for example make defconfig to get your default .config file. For example, to build on a Nexus S, I use make herring_defconfig. (herring is, I guess, the code name for the Nexus S hardware, which can incidentally be found if you look at /proc/cpuinfo on the Nexus S)
If you are not building for x86 (for example, like in my case, if you are building for Android) be sure to remember to export ARCH (for example, export ARCH=arm before running make). Otherwise, make help will not show the correct defconfig targets for the architecture you want to build.
I haven't done this in a while but aren't there sane defaults in the config dialogs?
This question is old, but I feel compelled to add http://kernel-seeds.org/ as a very viable option for a starting point to compile a fitting custom kernel -- as there are seeds for the vanilla sources, even if you are not on gentoo.
Related
I have tried develop Linux kernel module on vim with LSP(clangd)
But bunch of warning and errors are appeared.
It may caused by lack of clangd some configurations.
What header files and compiler parameters are required to use clangd with kernel module sources?
My compile_flags.txt is just one line but I know it's not enough:
-I/usr/lib/modules/5.19.3-arch1-1/build/include
The general recommendations around configuring projects for use with clangd are:
Prefer compile_commands.json to compile_flags.txt.
compile_flags.txt has many limitations (for example, it does not allow clangd to index the project) and is really only suitable for toy projects.
Do not hand-write your compile_commands.json, generate it automatically from build system metadata.
The way to do this is somewhat specific to your build system, but a
common and versatile approach is to use
bear, which wraps your build
command (e.g. if you build with make, you'd run bear make), and
generates compile_commands.json based on the compiler invocations
made by the build command.
See https://clangd.llvm.org/installation#project-setup for more details and more options.
I don't have specific advice for the Linux kernel; maybe others can chime in on that.
Context
Lately I've had trouble including an adis driver in my Yocto build. I've asked the question on the adis forum but found the solution before anyone answered it. The adis forum not being very user friendly and the answer being quiet long, I've decided to answer my question here and link it in the forum.
The question
I'm building my OS with yocto and I'd like to add a driver for IMU ADIS1607 (anything but the ease of use is a plus) as part of this build.
I'm building a prototype on a raspberryPi4. My application uses an ADIS IMU (ADIS16507). Since the board for the final product is not fixed I'm building my OS with Yocto.
I'm currently trying to add a driver for ADIS16507. Ideally I'd like to add ADIS16475, but I could do with something else provided it works nicely.
First off I have checked that I'm able to build the whole ADIS linux kernel for RaspberryPi as specified in the doc. With that kernel the driver works nicely.
However the ADIS linux kernel is too heavy for what I intend to do. Hence I'm trying to build a lighter OS with yocto (also, as aforementioned, I'll likely need to port my work on different platforms).
I have a few ideas on how to do it, however none of them worked easily and I'm not sure which one to pursue.
I assumed the simplest way would be to compile the ADIS16475 on its own and add it to the Yocto build. However I'm struggling a little with Yocto and haven't been able to compile sucessfully
Alternatively I did find the libiio layer for yocto but it seems to require quiet a lot of code to on top of it to be able to read the IMU values.
I am aware of the python bindings of libiio layer and of Pyadi-iio and it seems easy to use (although I did not try adding it with yocto) but computational speed is an issue for me and I'd rather use C/C++ instead of python.
Finally I also found the meta-adi layer. I think that in my case it is not relevant but the documentation I found is rather sparse and I'm not certain what this layer is supposed to do.
Any pointer on which method I should use (maybe I've missed an obvious easy one) is welcome.
So here is the solution I found. We will use the ADIS16475 which is a part of the standard libc since version 5.10. Then we'll get the corresponding device tree overlay from ADIS and add the relevant variables to have it compiled with the other device tree overlays.
Getting the correct versions
For this to work we need libc 5.10 or later since earlier version do not include the adis16475.c source file. However only the latest yocto release, Hardknott, uses the 5.10 version. So simplest thing to do is to switch to the Hardknott branch of Yocto. Keep in mind that if you use other layers, you might also have to change release for compatibility reasons.
Configuring the kernel to compile ADIS16475 drivers as built in
Here we're gonna dab into kernel compilation so there are a few things to know
Short and approximate theory
If you don't know much about kernel compilation don't worry, neither do I. But here is an approximate quick explanation in order for you to understand what we're doing: Kernel makefiles hold list of files the have to compile. For drivers there are 2 important lists. obj-y that holds the files that will be compiled and built in the kernel and obj-m that holds the files that will be compiled as loadable modules. In order to make these list configurable, they are defined in makefiles with statements such as:
obj-${CONFIG_MYDRIVER} += my_driver.o
The idea is that you can set CONFIG_MYDRIVER in an external file to 'm' or 'y'. If you set it to anything else the line in the makefile will be ignored and your file won't be compiled. So basically all we have to do is to set the right variables to the right values in order for yocto to compile our drivers.
Custom kernel configuration
Basically what we want to do is to create our own configuration fragment file. To do this you will need to set your yocto layer (I'll assume if you're reading this post you know how to do it). In your layer you should add the following folders:
meta-my-layer
|
- recipe-kernel
|
- linux
|
- linux-raspberrypi_5.10.bbappend
|
-linux-raspberrypi
|
-adis16475.cfg
(Note that we are appending linux-raspberrypi_5.10 because it's the one in meta-raspberrypi that is responsible for libc compilation. If you're compiling for another machine look what files are in recipe-kernel/linux. Your BSP might even actually use the ones in poky/meta/recipe-kernel/linux)
Now all that is left to do is to add adis16475.cfg to our sources by adding the following lines in linux-raspberrypi_5.10.bbappend:
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
SRC_URI += "file://adis16475.cfg"
And to actually setup your configuration in adis16475.cfg by adding to the file:
CONFIG_SPI_MASTER=y
CONFIG_IIO=y
CONFIG_ADIS16475=y
CONFIG_IIO_KFIFO_BUF=y
CONFIG_SPI_BCM2835=y
To the best of my knowledge and experience, this is the minimal amount of drivers you have to build for it to work.
Once this is done you will have your drivers built in but you won't see any effect on the Pi. That's because we're lacking the correct overlay.
Building adis16475-overlay.dts
To solve this problem I've been widely inspired by this post, so if you're having trouble you might want to check it out.
The issue here is that to my knowledge, the overlay corresponding to the driver is not provided by libc, at least not the 5.10 version. So we will have to be a little crafty. First off get the overlay from adis and copy it into recipe-kernel/linux/linux-raspberrypi.
Once this is done we will source it for yocto to find by modifying recipe-kernel/linux/linux-raspberrypi_5.10.bbappend to look like this:
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
SRC_URI += "file://adis16475.cfg \
file://adis16475-overlay.dts;subdir=git/arch/${ARCH}/boot/dts/overlays"
The last line we added tells yocto where to get our .dts file and where to put it (with the others overlays).
Finally what we have to do is to add our overlay to the list of overlays and device trees to be compiled. To do so we will use the machine configuration file raspberrypi4-64.conf. More details about it here.
First in your layer conf folder, create machine/raspberrypi4-64-extra.conf. This file will hold all the additional configuration we want to make for this driver. In it first add:
# Create the device trees and overlay list with necessary drivers
KERNEL_DEVICETREE = " \
${RPI_KERNEL_DEVICETREE} \
${RPI_KERNEL_DEVICETREE_OVERLAYS} \
overlays/adis16475.dtbo \
"
This sets the list of device trees to compile. It add the RPI device trees and overlays necessary for the pi (two first variables) and our adis16475 overlay.
Then we'll take advantage of this file to enable a few necessary raspberrypi specific configuration options. Add:
# Enable RPI specific options in config.txt
ENABLE_SPI_BUS = "1"
RPI_EXTRA_CONFIG = '\ndtoverlay=adis16475\n'
Finally you need to tell yocto to use this extra config. The most verstile way is to add the following line in your local/local.conf:
# Enables the DIP hardware support
require conf/machine/${MACHINE}-dip-extra.conf
Once this is done, provided you did add your layer to your bblayers.conf file, and your machine is set to raspberrypi4-64 in your local.con file, then everything else should work nicely.
Notes on the machine type
Here I worked with the machine set as raspberrypi4-64 for it was the one I had. There is no reasons for this procedure not to work with any other machine from the meta-raspberrypi layer. Just remember to replace the name of your machine everywhere I put raspberrypi4-64 and you should be fine.
Hope this will help some other people lost in the Yoctoverse
Cheers
I am using petalinux from Xilinx which builds around yocto.
I have one yocto that works fine, but is for the wrong Embedded Hardware (wrong board), and another which does not work but is for the correct board.
Therefore I would like to compare the settings in the two. The simplest but slowest way would be to iterative other Settings in the GUI, but it just seems tedious. So I am wondering if there is any way to somehow compare them by line or the config files etc.
Any help is appreciated
You can look into each kernel recipe's WORKDIR and compare the .config files. This is exactly what is set up for the kernel to build. To make it easier to compare, running bitbake -c savedefconfig <kernel recipe> and then comparing the defconfig in WORKDIR could highlight missing "top" drivers/configurations by omitting to show their dependencies.
I am doing Linux development on a few machines, mainly Slackware 13.37 and Ubuntu 12.04. I am testing and validating the results of a few simple makefiles, and want to confirm the output of make install. However, before I go ahead testing this, I want to know if there is a portable means of changing the default output destination for make install for any makefile.
I would prefer if I could somehow stage my output, so all output goes to, for example:
/test/bin
/test/lib
/test/usr/bin
instead of:
/bin
/lib
/usr/bin
I know that in QNX development environments, for example, I can set environment variables like QCONF_OVERRIDE and INSTALL_ROOT_nto, and guarantee that no makefile is able to install anywhere other than a subdirectory of /test for example. Is there a similar mechanism for GCC on Ubuntu that just requires setting some environment variables in my ~/.bashrc file? I do all my work via command-line and VIM anyways, so I'm not worried about the case where a pretty IDE doesn't understand these environment variables due to them not being in a .kderc, .gnomerc, or equivalent.
Thank you.
Short answer: no.
Long answer:
There isn't a way to set the output destination for any Makefile; the Makefile or some other part of the build system has to be designed to make it possible. make is a very simple tool because it's intended to function identically across a wide variety of platforms. Consequently, it doesn't really use environment variables that aren't present in the Makefile itself. This is good in terms of environment pollution and for keeping things less magic, but bad for achieving your desired goal.
A bit of context: things are a bit more complicated in part because, unlike the QNX development environment (a largely homogeneous cross-compilation environment), a large portion of software that uses make (I'm assuming GNU make but this applies to other versions as well) to build is written for a heterogeneous build and run environment—it may be designed to be able to build for different distributions, operating systems (Linux, MS Windows, Mac OS X, FreeBSD, etc.), and even hardware architecture (x86, arm, mips, power, sparc, sh, etc.). Sometimes you're building for the same system and sometimes for a different one. Unsurprisingly, there isn't really a standard way to define an install path across such a variety of systems.
Basile mentioned in his answer that for programs that use the GNU build system, you can use ./configure --prefix=/test. This will typically work for simple programs that use Autotools. For more complicated programs using GNU Autotools, there are usually complications if more diverse options are available:
cross-compiling? You might want your prefix to be set to where it's going to be installed on the target system (maybe /usr/local), and to use make install DESTDIR=/test.
Does your build system expect dependencies in the prefix directory, but you want to find them elsewhere? Better run ./configure --help to see what other options there are for providing alternate paths (often --with-foo=/prefix/of/foo)
I'm sure there's more that I'm forgetting right now, but I think you get the picture.
Keep in mind that only applies to projects that use Autotools. Other projects may have other systems (perhaps naming a variable or editing a configuration file), so ultimately your best bet is to read the project documentation, and failing that, the Makefile. Fun, eh?
P.S. Having variables defined in the environment is different than passing them as a command argument to make, i.e. SPAM="alot" make target is different from make target SPAM="alot"—the latter will override makefile variables. See the GNU make docs on Variables from the Environment.
Just change prefix variable in makefile
prefix=/test
then run
make install
also you can run following command for installing binaries
make prefix=/test install
Refer http://www.gnu.org/prep/standards/html_node/Directory-Variables.html
At least for GNU software (using autotools) you should configure your software with
./configure --prefix=/test
just using (without a specific --prefix to configure before)
make prefix=/test install
usually won't work correctly, because some of the files are builtin for the program so their path becomes a constant inside it.
You could also use make install DESTDIR=/tmp/dest and then copy /tmp/dest to /test but it won't work correctly neither
For example, my /usr/local/bin/emacs binary has /usr/local/share/emacs/24.3.50/lisp as some string (checked with strings /usr/local/bin/emacs command) and the /usr/local/ part of that path is the configure-d prefix.
BTW, you could have a chroot-ed environment to test your applications for various distributions.
I would like to generalize a build system to compile on several (somewhat similar) platforms. What is a good method for determining the type of host that the shell script or Makefile is running on. I would like to distinguish between mac and linux, but also different specific distributions of linux (e.g. RHEL, Ubuntu). Cygwin is not important for me, but if you include it in your response I am sure others will find it valuable.
The rationale may include using the host type to fetch and install the correct versions of binary packages when it is more convenient to do so than compile from source. In addition, some commercial software is binary-packaged for specific distros, so part of the motivation is to grab the right binary.
Thanks,
SetJmp
Autotools to the rescue. It has tons of macros that help you do this kind of stuff.
http://www.lrde.epita.fr/~adl/autotools.html
uname -a to distinguish major *nix variants
Not so sure what the best way to distinguish red hat from ubuntu would be - could look for package managing tools and query installed packages, eventually helping you narrow down different debian derivatives, etc. There's probably something more obvious and up front though.
linux variants generally store distro information in /etc/issue.
most kernels will put info in /proc/version
It's not completely straightforward. You can use uname to find out the general parameters but to differentiate between distributions is a harder task. Maybe you should consider using something like autoconf to generalise your build system?
Just in case you're using Qt, there's this really nice set of defines, Q_OS_*, that guide you to the Operating System you're compiling on:
Q_OS_AIX
Q_OS_BSD4
Q_OS_BSDI
Q_OS_CYGWIN
Q_OS_DARWIN
Q_OS_DGUX
Q_OS_DYNIX
Q_OS_FREEBSD
Q_OS_HPUX
Q_OS_HURD
Q_OS_IRIX
Q_OS_LINUX
Q_OS_LYNX
Q_OS_MAC
Q_OS_MSDOS
Q_OS_NETBSD
Q_OS_OS2
Q_OS_OPENBSD
Q_OS_OS2EMX
Q_OS_OSF
...
They are defined in QtGlobal. There are even defines that help you figure out the compiler used Q_CC_* or the target Windowing System Q_WS_*.
But if you're not using Qt and want to go for a generic method, you most likely have to fall back to the Autotools package or CMake.
Determining Linux distributions is pretty tricky, but not hard. You first have to figure out what distributions you care about and then make all kinds of distribution specific file/configuration checks like in this example for the ones you've chosen, since you can't really support all of the myriad of Linux distros available out the. :-)
As for the Mac side i'll let the Mac experts answer, but it shouldn't be that hard, since at least the diversity issue is out of the question.