Difference between revisions of "Bering-uClibc 7.x - Developer Guide - Adding a Kernel Architecture Variant"

From bering-uClibc
Jump to: navigation, search
(Add the Kernel .config Patch File)
m
 
(5 intermediate revisions by the same user not shown)
Line 1: Line 1:
 
{| summary="Navigation header" width="100%"
 
{| summary="Navigation header" width="100%"
! colspan="3" align="center" | [[Bering-uClibc 5.x - Developer Guide - Adding a Kernel Architecture Variant|Adding a Kernel Architecture Variant]]
+
! colspan="3" align="center" | [[Bering-uClibc 7.x - Developer Guide - Adding a Kernel Architecture Variant|Adding a Kernel Architecture Variant]]
 
|-
 
|-
| width="20%" align="left"  | [[Bering-uClibc 5.x - Developer Guide - Building an Image|Prev]]
+
| width="20%" align="left"  | [[Bering-uClibc 7.x - Developer Guide - Building an Image|Prev]]
! width="60%" align="center" | [[Bering-uClibc 5.x - Developer Guide]]
+
! width="60%" align="center" | [[Bering-uClibc 7.x - Developer Guide]]
| width="20%" align="right"  | [[Bering-uClibc 5.x - Developer Guide - Adding a Hardware Architecture Variant|Next]]
+
| width="20%" align="right"  | [[Bering-uClibc 7.x - Developer Guide - Adding a Hardware Architecture Variant|Next]]
 
|}
 
|}
 
----
 
----
Line 31: Line 31:
  
  
==Add the Kernel .config Patch File==
+
===Version 7.x and later===
Rather than separately maintaining a complete <code class="filename">.config</code> file each kernel variant a "baseline" plus "delta" approach has been adopted.
+
The previous approach using config diff files and release tagged config files has shown to be tedious and not well corresponding to modern release management tools. Therefore we have reintroduced the old naming convention for the config files which used to be created from the ''basic'' configuration files plus a ''.diff'' file. To easier maintain these Files in ''git'' the kernel release numbers are now omitted from the file names. Thus the config files now follow the convention ''Bering.config-<karch>''.
All of the standard, common settings for [[Bering-uClibc 5.x]] are in the "baseline" file and just the bare minimum of variant-specific changes are in a per-variant "delta" file implemented in the form of a patch.
+
  
===Versions 5.0 and 5.1===
+
'''ToDo: define the process maintaining these files in detail'''
All of these files are stored in directory <code class="filename">repo/linux/</code>:
+
* The "baseline" file is called <code class="filename">Bering-''kver''.config</code> where "<tt>''kver''</tt>"" is something like "<tt>3.4.50</tt>". For example <code class="filename">Bering-3.4.50.config</code>. The baseline kernel is based on the i686 variant.
+
* The "delta" file is called <code class="filename">Bering-''kver''.config-''karch''.patch</code>. For example <code class="filename">Bering-3.4.50.config-i486.patch</code>.
+
As part of the build process, each "delta" patch is applied to the "baseline" file to create file <code class="filename">source/linux/Bering-''kver''.config-''karch''</code> which is then copied to <code class="filename">source/linux/linux-''karch''/.config</code> and used to configure the kernel.
+
 
+
You need to create the new <code class="filename">Bering-''kver''.config-''karch''</code> file by some means and then create the patch as follows:
+
diff -c  Bering-''kver''.config  Bering-''kver''.config-''karch''  >  Bering-''kver''.config-''karch''.patch
+
 
+
The new <code class="filename">.patch</code> file name needs to be added to <code class="filename">repo/linux/buildtool.cfg</code>.
+
 
+
===Version 5.2 and 6.x===
+
With Bering-uClibc 5.2 <code class="filename">tools/confdiff.py</code> and <code class="filename">tools/confpatch.py</code> replaced the diff/patch utilities used earlier.
+
 
+
As before, all of these files are stored in directory <code class="filename">repo/linux/</code>:
+
* The "baseline" file is called <code class="filename">Bering-''kver''.config</code> where "<tt>''kver''</tt>"" is something like "<tt>4.1.4</tt>". For example <code class="filename">Bering-4.1.4.config</code>. The baseline kernel is based on the i486 variant.
+
* The "delta" file is called <code class="filename">Bering-''kver''.config-''karch''.patch</code>. For example <code class="filename">Bering-4.1.4.config-i486.patch</code>.
+
As part of the build process, each "delta" patch is applied to the "baseline" file to create file <code class="filename">source/linux/Bering-''kver''.config-''karch''</code> which is then copied to <code class="filename">source/linux/linux-''karch''/.config</code> and used to configure the kernel.
+
 
+
You need to create the new <code class="filename">Bering-''kver''.config-''karch''</code> file by some means and then create the patch as follows:
+
tools/confdiff.py repo/linux/Bering-''kver''.config  repo/linux/Bering-''kver''.config-''karch''  >  repo/linux/Bering-''kver''.config-''karch''.cdiff
+
 
+
The new <code class="filename">.cdiff</code> file name needs to be added to <code class="filename">repo/linux/buildtool.cfg</code>.
+
 
+
===Version 7.x and later===
+
The previous aproach using config diff files and release tagged config files has shown to be tedious and not well corresponding to modern release management systems. Therefore we have reintroduced the old naming convention for the config files which used to be created from the ''basic'' configuration files plus a ''.diff'' file. To easier maintain these Files in ''git'' we the kernel release numbers are now omitted from the file names.
+
  
 
==Add the <tt>kmodules</tt> Configuration==
 
==Add the <tt>kmodules</tt> Configuration==
Line 66: Line 40:
  
 
Edit <code class="filename">repo/kmodules/buildtool.cfg</code> and add a new block of lines for "<tt><moddb-''karch''></tt>".
 
Edit <code class="filename">repo/kmodules/buildtool.cfg</code> and add a new block of lines for "<tt><moddb-''karch''></tt>".
 
 
==Add the <tt>initrd</tt> Configuration==
 
Since the kernel Modules vary from one kernel architecture variant to another each variant needs its own <code class="filename">initrd-''karch''.lrp</code> which is generated from the <tt>initrd</tt> source.
 
 
Edit <code class="filename">repo/initrd/buildtool.cfg</code> and add a new block of lines for "<tt><initrd-''karch''></tt>".
 
  
  
Line 91: Line 59:
 
----
 
----
 
{| summary="Navigation footer" width="100%"
 
{| summary="Navigation footer" width="100%"
| width="40%" align="left"  | [[Bering-uClibc 5.x - Developer Guide - Building an Image|Prev]]
+
| width="40%" align="left"  | [[Bering-uClibc 7.x - Developer Guide - Building an Image|Prev]]
| width="20%" align="center" | [[Bering-uClibc 5.x - Developer Guide|Up]]
+
| width="20%" align="center" | [[Bering-uClibc 7.x - Developer Guide|Up]]
| width="40%" align="right"  | [[Bering-uClibc 5.x - Developer Guide - Adding a Hardware Architecture Variant|Next]]
+
| width="40%" align="right"  | [[Bering-uClibc 7.x - Developer Guide - Adding a Hardware Architecture Variant|Next]]
 
|}
 
|}
  
[[Category:Bering-uClibc 5.x]]
+
[[Category:Bering-uClibc 7.x]]
 
[[Category:Developer Guide]]
 
[[Category:Developer Guide]]

Latest revision as of 12:05, 6 October 2019

Adding a Kernel Architecture Variant
Prev Bering-uClibc 7.x - Developer Guide Next


Introduction

Bering-uClibc 3.x was built for a single "lowest common denominator" platform - a generic i486 CPU. This offered maximum flexibility but meant that it was not possible to include optimisations for more recent CPU models, which is becoming more of a problem as the i486 gets older and less common.

For Bering-uClibc 4.x and later this approach has changed and a small number of different CPU platform variants are supported as standard. Specific kernels and kernel Modules are built for all of the supported variants and distributed via disk Image variants for each platform.

This page outlines the procedure for adding a new CPU variant to the standard list.


Add the Kernel Architecture Name

Most of the build tools automatically process each of the entries in the kernel architecture list which is defined in one place.

In file make/toolchain/i486-unknown-linux-uclibc.mk edit the definition of variable "KARCHS" to add a new name to the space-separated list. Search for lines like:

# available kernel archs
export KARCHS:=i686 i486 geode

The new name should be short (ideally 4 characters) and should clearly refer to the new CPU architecture.

The new name will be referred to as "karch" in the remainder of this page.


Version 7.x and later

The previous approach using config diff files and release tagged config files has shown to be tedious and not well corresponding to modern release management tools. Therefore we have reintroduced the old naming convention for the config files which used to be created from the basic configuration files plus a .diff file. To easier maintain these Files in git the kernel release numbers are now omitted from the file names. Thus the config files now follow the convention Bering.config-<karch>.

ToDo: define the process maintaining these files in detail

Add the kmodules Configuration

Since the kernel Modules vary from one kernel architecture variant to another each variant needs its own moddb-karch.lrp which is generated from the kmodules source.

Edit repo/kmodules/buildtool.cfg and add a new block of lines for "<moddb-karch>".


Add the Image Configuration

Each kernel architecture variant needs its own disk Image variant(s).

Create a new directory under image/ and create file buildimage.cfg within that (best to copy and edit an existing file). Refer to the Building an Image page for details of the directory naming convention.

Repeat if multiple types (e.g. ISOLINUX versus SYSLINUX) of image are relevant for this kernel variant, but only create the minimum set likely to be required.


Add the Documentation

Usually, a new kernel architecture variant will be added because it is required for a specific hardware device which is particularly suitable for running Bering-uClibc 5.x.

Please therefore add some content to the Hardware-Specific Guides page of this Wiki to detail the hardware device and to specify which Image should be used for it.



Prev Up Next