Linux kernel config android

Android Kernel Configs

How are kernel config settings typically stored?

When building the Linux kernel for a particular platform one usually begins by basing the kernel configuration off of a particular defconfig. The platform’s defconfig contains all of the Linux kconfig settings required to properly configure the kernel build (features, default system parameters, etc) for that platform. Defconfig files are typically stored in the kernel tree at arch/*/configs/ .

It may be desirable to modify the kernel configuration beyond what the hardware platform requires in order to support a particular hardware or software feature. Storing these kernel configuration changes is often done using fragments. These are files which have the same format as a defconfig but are typically much smaller, as they only contain the kernel configuration settings needed to support the hardware or software feature/behavior in question. Maintainers of hardware extensions or software features can use fragments to compactly express their kernel requirements. The fragments can be combined with a platform defconfig using the kernel’s make rules or using the scripts/kconfig/merge_config.sh script in the kernel tree.

How are Android’s kernel configs stored?

The kernel configs are stored in the kernel/configs repo.

Kernel configuration settings that must be present for Android to function are located in the base config fragment, android-base.config . Configuration settings that enhance Android’s functionality in some way but are not required for it to run are located in the recommended config fragment, android-recommended.config .

Some kernel config requirements only apply on certain architectures. Other requirements only apply if some other kernel config option has a particular value. The platform owner may also have a choice between several config options. These types of constraints cannot be expressed with a simple kernel config fragment. In releases up to and including Android P, kernel config requirements that are specific to a particular architecture are contained in architecture-specific base config fragments, such as android-base-arm64.config . If an architecture-specific base config fragment does not exist for a particular architecture in Android P or an earlier release, it means there are no required kernel config options for Android specific to that architecture. Note that the architecture-agnostic kernel config requirements from android-base.config still apply in that case.

In releases after Android P the architecture-specific base config fragments are removed, and conditional kernel config requirements are stored in android-base-conditional.xml .

In Android R or above, additional config fragments are added conditionally on build variants. In particular, non_debuggable.config contains additional requirements for user builds.

Kernel configs vary by kernel version, so there are sets of kernel configs for each version of the kernel that Android supports.

How can I easily combine platform and required Android configs?

Assuming you already have a minimalist defconfig for your platform, a possible way to enable these options would be to use the aforementioned merge_config.sh script in the kernel tree. From the root of the kernel tree:

This will generate a .config that can then be used to save a new defconfig or compile a new kernel with Android features enabled.

The kernel build system also supports merging in config fragments directly. The fragments must be located in the kernel/configs directory of the kernel tree and they must have filenames that end with the extension “.config”. The platform defconfig must also be located in arch//configs/ . Once these requirements are satisfied, the full defconfig can be prepared with:

If there is an android-base-conditional.xml file for your release/kernel version combination, it is necessary to review it and manually edit your defconfig to satisfy any applicable requirements.

Are the config requirements tested?

Starting with Android O the base kernel configs are not just advisory. They are tested as part of VTS (specifically the SystemVendorTest.KernelCompatibility subtest of CtsOnGsiTrebleFrameworkVintfTest), and also during device boot when the vendor interface (which includes the kernel configuration) and framework compatibility matrix are compared.

Ensuring Device Upgradability

Devices launched with prior releases of Android must be able to upgrade to later releases of Android. This means that AOSP must function not only with device kernels that adhere to the Android kernel configs of the current release, but also with those device kernels that adhere to the configs of past releases. To facilitate that in the VtsKernelConfig test and in the framework compatibility matrix, past versions of the Android kernel config requirements are stored in the kernel/configs repo. During tests the appropriate versions of the configs are accessed depending on the launch level of the device.

If you are adding a new feature to AOSP which depends on a particular kernel configuration value, either that kernel configuration value must already be present in the base android config fragments of past releases still on the supported upgrade path, or the feature must be designed in a way to degrade gracefully when the required kernel configuration is not present (and not be essential to AOSP’s overall functionality). All configs on the supported upgrade path are in the kernel/configs repo.

Support for kernel configs from previous dessert releases is dropped from AOSP when the upgrade path from that dessert release is no longer supported.

Organization and Maintenance of the Kernel Config Repo

The top level of the kernel configs repo contains directories for each supported kernel version. These contain the kernel config requirements (and recommendations) for the next release. There are also directories at the top level for previous releases. These directories contain the final kernel config requirements (for all supported kernel versions) for those releases and must not be changed once those releases have been published. AOSP must support all kernel configurations in this repo.

For release branches the structure is similar, except there are no configs at the top level. When a release is branched from master the top-level configs are copied into a new directory for the release (this change is propagated to master) and the top-level configs are removed (this change is not propagated to master) since no development beyond that release is done in that branch.

I want to add/modify/remove a kernel config requirement. What do I do?

Modify the top level kernel configs in AOSP. Make sure to modify the configs for all applicable kernel versions. Do not modify the config fragments in release directories.

Because there is no tool to consistently generate these config fragments, please keep them alphabetically (not randomly) sorted.

android-x.y/android-base.config

This file lists all common kernel configuration requirements on kernel version x.y .

android-x.y/android-base-conditional.xml

Contains the following:

• Minimum LTS required
• Conditional requirements.

android-x.y/Android.bp

Build rules from the aforementioned files to a framework compatibility matrix . See this link for details of the output format.

I want to freeze/release the current kernel requirements. What do I do?

Prior to a FCM Version release (often accompanied with a dessert release as well), the kernel requirements must be frozen. Follow the following steps

• Copy the top-level android-* directories to a release directory, preferably with the dessert name (for example, q ).
  • Remove top-level android-* directories. This change is not propagated to master.
• Edit the new /android-*/Android.bp files and rename the modules. For example, change kernel_config_current_4.9 in q/android-4.9/Android.bp to kernel_config_q_4.9
• Under hardware/interfaces/compatibility_matrices/Android.bp , edit kernel_configs field for the framework_compatibility_matrix.current.xml to use the new modules.
  • framework_compatibility_matrix.current.xml will be renamed to framework_compatibility_matrix. .xml as part of the FCM Version release, which is a separate process.

I want to edit a released kernel requirement. What do I do?

Don’t edit a released kernel requirement unless necessary. If you have to make such a change, after discussing the change with maintainers, keep in mind that you CANNOT make a requirement more restrictive. Specifically,

Источник

Android-x86

Run Android on your PC

Customize Kernel

The Android build system doesn’t compile kernel on-fly. It just contains a prebuilt kernel binary which will be added to the target image. This approach may be good enough for the arm emulator target, but not suitable for x86 platforms. The x86 platforms have various hardware. The kernel binary and its modules may need to be adjusted at compile time or runtime.

This article explains an extra feature of the android-x86 build system. That is, the ability to build kernel and modules by a predefined or customized config during the building process.

Prepare the source tree

We have modified the Android build system to compile a kernel image on-fly. You need to use our repository to get this feature. Read the article for details.

Build the target default kernel

We put default configs of supported targets of android-x86 in kernel/arch/x86/configs/. The corresponding defconfig of a selected target will be used automatically. For example,

By specifying the TARGET_PRODUCT to android_x86_64, the build system automatically selects the config android-x86_64_defconfig to compile the kernel binary and its modules. The binary will be generated in out/target/product/x86_64/kernel, and the modules is put under out/target/product/x86_64/system/lib/modules/. The final target out/target/product/x86_64/android_x86_64.iso will contain the kernel binary and its modules.

Build and update kernel solely

To build the kernel and its modules solely, change the goal iso_img to kernel:

Then you can copy $OUT/kernel and $OUT/system/lib/modules/ to the target device. Put the former to the android-x86 installation directory, and the latter to /system/lib/modules. Note the /system must be installed as read-write mode.

Specify kernel architecture

Since Android 5.0 it supports both 32-bit and 64-bit images. Usually 32-bit userspace works with 32-bit kernel, while 64-bit userspace must work with 64-bit kernel. Android-x86 build system supports both since lollipop-x86.

Sometimes you may want to run 32-bit userspace with 64-bit kernel. In this case, you may specify kernel architecture by TARGET_KERNEL_ARCH:

Force recompilation of the kernel

Android and kernel use entirely different build systems. Though we combine them together, the integration doesn’t work very well. An example is if you modify the kernel tree, Android build system won’t notice the change. That means, the kernel won’t be rebuilt automatically if you rebuild the image.

There are several ways to overcome that. One is to touch the defconfig like:

Or remove the kernel config in the out/ directory:

Or remove the kernel image:

Replace the kernel

Since we build kernel with modules support, to replace the kernel of an installed system, you have to replace the corresponding modules as well. To do that, copy the kernel image to the android-x86 installation directory, and copy modules to /system/lib/modules. You can do that by booting to debug mode like:

Detecting Android-x86. found at /dev/sda1

Type ‘exit’ to continue booting.

Running MirBSD Korn Shell.
exit

Use Alt-F1/F2/F3 to switch between virtual consoles
Type ‘exit’ to enter Android.

Running MirBSD Korn Shell.
mount /dev/sdb1 /hd
cp /hd/kernel /src
rm -rf /system/lib/modules/*
cp -a /hd/modules/* /system/lib/modules
sync; umount /hd; reboot -f

Build a customized kernel

Suppose you already have a workable kernel config for you hardware, it’s easy to tell the build system to use your config to build the iso. Just put your config file to kernel/arch/x86/configs/, and run (suppose the name of your config is my_defconfig)

Customize the kernel configuration

It is never advisable to edit the kernel config file directly, as it may generate faulty configuration (dependencies not met etc.). The correct way to customize the kernel config is (on the top of android-x86 tree)

If you get an error message Unknown option: -C, change make to /usr/bin/make. That’s because since Android 8 the build system overrides the default make command of the system by its own make function (to invoke soong rules) which doesn’t recognize the -C option. To overcome that, just use the make command of the system.

The generated config is $OUT/obj/kernel/.config. Copy it to where you want it to be.

DO NOT issue make menuconfig in the kernel/ directory directly. If you do so, the build rules may be broken. In this case, try this way to recover it (on the top of android-x86 tree):

Use a prebuilt kernel

If you have a workable prebuilt kernel binary for your hardware, you can generate the iso with it:

Compile kernel for ARM (deprecated)

The kernel build system can also be used to compile kernel for ARM. For example, to compile kernel 2.6.29 for the goldfish CPU of the arm emulator, run

Источник

EduApps-CDG / Building Linux Kernel With Android.md

How to Build Linux Kernel with Android

This guide shows how to build Linux on a Android Device and was made for people that doesn’t have s Computer.

• 4GB of free space (2GB if delete the temp files)
• Android 5.0

Preparing the Environment

You need to install Termux from Google Play Store. Now we will download the Kernel so we need WGET:

The next step is decompress that tarball with UNXZ and TAR (integrated with Termux):

(Optional) Delete the Linux tarball:

Now we have the Linux Source on our Android, lets compile!

In Android, compile is a terror for Linux Kernel. First we need to create a config file.

The .config file dilemma

If you had an Linux PC you could simply do this:

But you dont have so we need to do this:

If you have a Rooted Potato Phone you can simply:

No Root mode (medium)

If else, first you need to download it from our repository:

No Root mode (hard)

If the file was not found, you must generate it. It has only one command, but this command is the worst! It’s the best choice if you are developing a new device. Complete the first command of Building and type:

Once solved the dilemma, you will not need to do it again. the next step is install the compilers:

This command will setup to build the Kernel with full power, if you have a single core device, it doesn’t help so much but works:

And finally, the Last Step is: Enjoy the building time and drink a coffee!

Источник