Changes between Version 4 and Version 5 of linux/kernel

07/02/2018 12:36:20 PM (3 weeks ago)
Tim Harvey

added more detail to generic instructions for various Gateworks targets


  • linux/kernel

    v4 v5  
    88== Kernel sources ==
    9 When choosing a kernel source you need to determine what support you are interested in. Gateworks recommends using our Gateworks downstream vendor kernel if you are needing full hardware support as the mainline Linux kernel is still lacking certain IMX6 support.
    11 == Newport Kernel ==
    13 It is highly recommended to visit the [wiki:newport/bsp#kernel Newport BSP page kernel section] for more information about the Newport kernel.
    15 === Gateworks downstream vendor kernel ===
    16 Gateworks maintains a downstream Linux kernel that contains patches from Freescale and Gateworks to add support for Ventana including some items that have not made it into mainline Linux yet.
     9When choosing a kernel source you need to determine what support you are interested in.
     11=== Mainline upstream Linux kernel
     12Gateworks usually recommends using the mainline or upstream Linux kernel because it has the most up-to-date features and bug-fixes that have been accepted and peer reviewed from the widest array of kernel developers around the world.
     14The 'mainline' Linux kernel is the one officially released by Linus Torvalds and has an approximate release cycle of every 6 months.
     17 * [ Linux git]
     18 *
     20See also:
     21 * [wiki:ventana/#mainline-linux Gateworks mainline linux details and patches]
     22 * - source
     23 * - source archives
     24 * - Linux version info
     27=== Stable Kernel
     28The Stable Kernel adds backported bugfixes on top of previous mainline Linux kernel releases. A variant of this is the Long Term Support (LTS) kernel versions that are supported by the community for typically 4 years.
     31 * [ Linux Stable Git]
     34=== Gateworks Newport kernel (OcteonTX)
     35Gateworks maintains a kernel for the OcteonTX tailored (Newport product family) based off a mainline Linux kernel with additional patches that may not be available in the mainline kernel yet.
     38 * [ linux-newport Git]
     39 * [ Newport Kernel wiki section]
     42=== Gateworks Ventana downstream vendor kernel (IMX6)
     43Gateworks maintains a downstream IMX6 Linux kernel that contains patches from Freescale and Gateworks to add support for Ventana including some items that have not made it into mainline Linux yet.
    1744 * [ source]
    1845 * [ gateworks-linux-imx6-3.14.48.tar.gz] - prebuilt tarball
    2754Our kernel source has a default config file (arch/arm/configs/gwventana_defconfig) which which we use but keep in mind that in general wireless drivers and subsystems are not defined there because those modules come from linux-backports instead.
    29 === Mainline upstream linux kernel ===
    30 The mainline Linux kernel is missing the following support (which is present in the Gateworks vendor kernel):
    31  * IMX6 video capture (this is slowly being worked on but not yet present as of 4.2)
    32  * adv7393 analog video output (GW54xx)
    33  * HW crypto support
    34  * IMX6 GPU driver (there is work ongoing on an open-source reverse engineered Vivante driver called [ etna_viv])
    35  * VPU support (technically, the upstream coda driver does support the chips-and-media VPU but not in a way that gstreamer can utilize it)
    37 See also:
    38  * [wiki:ventana/#mainline-linux Gateworks mainline linux details and patches]
    39  * - source
    40  * - source archives
    41  * - Linux version info
    98111- Linux development host: Gateworks uses and supports Ubuntu which is used here as an example, but other Linux variants can work as well
    99112- Toolchain for the CPU architecture of the boards you are working with:
    100  * Ventana uses the Freescale IMX6 SoC which has ARM Cortex-A9 cores with NEON SIMD support. You can download our pre-built OpenWrt toolchain [ here]
     113 * Newport uses the Cavium CN80xx OcteonTX SoC which has ARMv8 CPU cores. You can download the toolchain provided Cavium for their SDK [ here] or use one that you have pre-built from OpenWrt
     114 * Ventana uses the NXP/Freescale IMX6 SoC which has ARM Cortex-A9 cores with NEON SIMD support. You can download our pre-built OpenWrt toolchain [ here]
    101115 * Laguna uses the Cavium cns3xxx SoC which has ARM11 MP-Core cores
    103 Steps to build the Gateworks kernel for the Ventana family using the Gateworks OpenWrt toolchain:
     117Steps to build the Gateworks kernel using the Gateworks OpenWrt toolchain:
    1041181. Install pre-requisites:
    1131272. Obtain and install compiler toolchain:
     128 * For Newport, you can use the pre-built toolchain provided by Cavium for their SDK:
     131tar -xvf tools-gcc-6.2.tar.bz2
    114133 * For Ventana, you can use the pre-built Gateworks OpenWrt 14.08 BSP tailored to the ARM Cortex-A9 CPU used in the IMX6 SoC:
    1201393. Obtain Linux kernel source (see [#linuxsource above] to help you decide which kernel version you should use):
     140 * for mainline '''Linux v4.14''' for example:
     142git clone git://
     143cd linux
     144git checkout v4.14
     146 * for the Gateworks Newport kernel based on 4.14:
     148git clone
     149cd linux-newport
     150git checkout v4.14.4-newport
    121152 * for the '''Gateworks Linux 3.14.x''' based downstream vendor kernel (with full Ventana support including video capture which hasn't made it fully into mainline yet):
    125156git checkout gateworks_fslc_3.14_1.0.x_ga
    127  * for mainline '''Linux v4.1''' for example (which is missing video capture support for IMX6/Ventana):
    128 {{{#!bash
    129 git clone git://
    130 cd linux
    131 git checkout v4.1
    132 }}}
    134 4. Setup shell env for building:
    135  * Note that the paths here are dependent on the toolchain you installed. The following is for the pre-built Gateworks OpenWrt 14.08 BSP toolchain:
     1594. Setup shell environment for building which depends on the toolchain you are using. This includes the following env variables used by the kernel build system:
     160 * ARCH - the architecture to build (arm for 32bit ARM such as Ventana IMX6, arm64 for 64bit ARMv8 such as Newport CN80xx)
     161 * CROSS_COMPILE - the prefix the toolchain you are using has prior to the gcc executables (everything before the 'gcc').
     162 * PATH - make sure the directory where the toolchains compiler (${CROSS_COMPILE}gcc) executable exists. Typically you will prepend this to the default PATH
     163 * INSTALL_MOD_PATH - where to install kernel modules too if using the 'modules_install' build target (in our examples we install to ./install)
     164 * INSTALL_HDR_PATH - where to install header files if using the 'headers_install' build target (in our examples we install to ./install)
     165 * LOADADDR - where to relocate/uncompress the kernel to when using the uImage target
     166 * Examples:
     167  - using the pre-built Gateworks OpenWrt 14.08 BSP toolchain:
    137169export STAGING_DIR=../OpenWrt-Toolchain-imx6-for-arm_cortex-a9+neon-gcc-4.8-linaro_uClibc-
     172export ARCH=arm
     173export CROSS_COMPILE=arm-openwrt-linux-
    140174export INSTALL_MOD_PATH=install
    141175export INSTALL_HDR_PATH=install
    142 export ARCH=arm
    143 export CROSS_COMPILE=arm-openwrt-linux-
    144 }}}
    145  * Note that STAGING_DIR is something required by the OpenWrt toolchain... your toolchain may differ
    146  * The INSTALL_MOD_PATH env var is used by the modules_install and firmware_install make targets to specify the directory to install modules/firmware into
    147  * The ARCH and CROSS_COMPILE env args are required for proper cross-compilation using your toolchain
     176export LOADADDR=0x10008000
     178   * Note that STAGING_DIR is something required by the OpenWrt toolchain... your toolchain may differ
    148179 * Some troubleshooting steps:
    150 echo $ARCH #should return arm
     181echo $ARCH # make sure this is not empty and is set to your target CPU architecture
    159190echo $PATH #have you appended the appropriate parameters to your path. When in doubt start new shell
    161 5. Configure the kernel:
    162  * for the '''Gateworks Linux 3.14.x''' based downstream vendor kernel start with {{{gwventana_defconfig}}}
    163  *
    164 {{{#!bash
    165 make gwventana_defconfig
    166 }}}
    167  * for mainline '''Linux v4.1''' start with the {{{imx_v6_v7_defconfig}}}:
     1925. Configure the kernel. Often you will want to start with an existing defconfig file followed by doing a 'make kernel menuconfig' to change any options you desire to modify.
     193 * Examples:
     194  - for mainline start with either 'imx_v6_v7_defconfig' for Ventana/IMX6 or 'defconfig' for Newport/CN80XX:
    170 make imx_v6_v7_defconfig
    171 }}}
    172  * Optional, modify kernel:
    173 {{{#!bash
     197make imx_v6_v7_defconfig # Ventana/IMX6
     198make defconfig # Newport/CN80XX
     200  - for the Gateworks Newport kernel:
     202make newport_defconfig
    174203make menuconfig
     205  - for the Gateworks Linux 3.14.x based downstream vendor kernel:
     207make gwventana_defconfig
     208make menuconfig
    176210  * The menuconfig make target launches the ncurses based (serial console) Linux kernel menu configuration tool so that you can add or adjust the support to your needs. A common change to the default kernel configurations above would be to add  support for a USB based device, or wireless (802.11) support for example.
    178 6. Build kernel:
    179 {{{#!bash
    180 LOADADDR=0x10008000 make uImage modules dtbs modules_install
    181 }}}
    182  * the default make target will build zImage, modules, and dtbs - we want uImage, modules and dtbs
    183  * when building a multi-arch kernel, the build system needs to know the load address to put in the u-boot image header which you provide via the LOADADDR env var. For IMX6 its 0x10008000
    184  * the firmware_install make target can also be specified if you need specific firmware to be placed in $INSTALL_MOD_PATH/lib/firmware
    185  * The uImage make target builds a U-Boot image of the kernel
    186  * The dtbs make target builds the device-tree binaries needed to boot the Ventana kernel (not used for non device-tree kernels)
    187  * The modules_install make target installs the kernel modules to the INSTALL_MOD_PATH directory
    188  * After building and copying the uImage and dtbs to install/boot, you can copy or extract the contents of the install directory to your Linux root filesystem taking care to make the user and group root
    189  * headers will be in the install dir
    191 6. Copy additional artifacts:
    192 {{{#!bash
    193 mkdir $INSTALL_MOD_PATH/boot
    194 cp arch/arm/boot/uImage arch/arm/boot/dts/imx6*gw*.dtb $INSTALL_MOD_PATH/boot
    195 }}}
    197 If you wish to make a tarball of this kernel relative to the root fs:
    198 {{{#!bash
    199 tar -C $INSTALL_MOD_PATH --owner=0 --group=0 -cvzf linux-4.1.tar.gz .
    200 }}}
    202 If you need kernel headers for development you can build them via:
    203 {{{#!bash
    204 make headers_install
    205 }}}
    206  * headers will be in INSTALL_HDR_PATH which we set to the install subdir above
    208 If you wish to add additional drivers from a newer kernel (for example, you are using the 3.14.x Gateworks downstream vendor kernel but wish to have updated wireless drivers) see [#backports below].
     2126. Build kernel targets. What targets you build depends on the product family and the bootloader or boot method you are using. Some common examples are:
     213 * Image - uncompressed kernel (use this for Newport/CN80XX arm64 targets)
     214 * uImage - compressed kernel wrapped in a U-Boot image header (use this for Ventana/IMX6) which requires the $LOADADDR env variable to tell U-Boot where to uncompress the kernel to
     215 * modules - for building loadable kernel modules (*.ko)
     216 * modules_install - for installing the loadable kernel modules to $INSTALL_MOD_PATH
     217 * headers_install - for installing kernel header files to $INSTALL_HDR_PATH
     218 * dtbs - for building device-tree blobs (*.dtb) from kernel source tree (Ventana/IMX6; for Newport we use out-of-kernel tree device-tree)
     219 * Examples:
     220  - Newport/CN80XX:
     222make Image modules modules_install headers_install
     224  - Ventana/IMX6:
     226make uImage dtbs modules modules_install headers_install
     2296. Copy artifacts (depends on target):
     230 * kernel images (Image/uImage) will be in arch/$ARCH/boot
     231 * dtbs will be in arch/$ARCH/boot/dts
     232 * modules will be in $INSTALL_MOD_PATH. You can create a tarball via:
     234tar -C $INSTALL_MOD_PATH --owner=0 --group=0 -cvJf modules.tar.xz .
    268296And that's it! If you tar the kernel up, make sure to remove the backports directory as each {{{.ko}}} will be double counted if you already copied the {{{.ko's}}} to the kernel tree. Please see the [wiki:linux/kernel#updating updating section] for details on how to update a target's kernel.
    270 == Kernel Module Commands ==
    271  * depmod - builds module dependency database
    272  * modprobe loads module and all dependecies
    273  * insmod loads module but NO depedencies
    275 See Linux documentation for more information.
    278 == Updating the kernel dtbs and modules on a running target ==
    279 If you want to update the kernel, dtbs, and modules on a running target using the tarball created after building the kernel (see above), you can do this by booting and using:
     301== Installing or Updating the kernel artifacts
     302Installation of a newly build kernel and other artifacts (headers, modules, dtbs) depends on the target platform and how you are booting it.
     304Kernel modules are located in a directory structure /lib/modules/(kernel_version) which matches the structure used when you install the modules with the 'modules install' build target. If you created a tarball of the kernel modules you can install those on your target as such:
    281306# download kernel specific tarball suitable for booted kernel
     324 * Note that OpenWrt uses a flat directory structure for kernel modules
    329355  bootm ${loadaddr} - ${fdt_addr}
     361= Kernel Modules
     362Kernel modules are dynamically loadable portions of the kernel that can be loaded or unloaded at runtime. It is generally not feasible to build every kernel driver statically into a modern Linux kernel so instead only options required to load further modules are build static.
     364The userspace applications {{{insmod}}} and {{{rmmod}}} are used to load and remove modules at runtime.
     366Most Linux based Operating Systems these days also contain support for automatically determining and loading module dependencies (modules required by the module you are trying to load) and for these you will also have:
     367 * {{{modprobe}}} - load module and all dependecies
     368 * {{{depmod}}} - builds module dependency database
     370See Linux documentation for more information.