Linux Kernel

From Linux/Xtensa
Revision as of 06:34, 14 October 2014 by Jcmvbkbc (talk | contribs) (grammar fixes, add links to crosstool and buildroot)
Jump to navigation Jump to search

Getting linux kernel sources

Now that linux mainline has up-to-date xtensa support kernel.org is the primary place to go for xtensa linux. Depending on whether kernel tree with full history is needed for development or not either release tarball should be downloaded or git tree cloned.

Using tip of the cloned git tree for work is usually a bad idea, basing development branches on known releases (marked by tags) would give more predictable results.

Adding specific processor configuration

Note that the Xtensa port of Linux uses the terminology variant to describe a processor configuration. The steps involved adding a processor configuration are:

  1. Create a new directory for the processor variant and copy a set of configuration files that describes the processor to that directory.
  2. When configuring the kernel set .config variable CONFIG_XTENSA_VARIANT_CUSTOM_NAME to the name of used variant.

All processor configuration specific sources and header files are located in arch/xtensa/variants/variant-name for source files, and arch/xtensa/variants/variant-name/include/variant for header files. The include directory typically contains at least the following three files that describe the processor configuration:

  • tie.h - describing custom defined TIE registers
  • tie-asm.h - macros to access additional TIE registers
  • core.h - describing various processor configurations, such as cache sizes, register options, etc.

All processor configurations provide a set of these files as part of the overlay provided by Tensilica.

If we want to add another processor, we have to create the following directory and copy the three configurations file to that directory: 

mkdir -p arch/xtensa/variants/MyCore/include/variant
cp tie.h tie-asm.h core.h arch/xtensa/variants/MyCore/include/variant

Configuring and building the kernel

To build the kernel a toolchain for the target variant is needed: gcc (it need not have libc) and binutils. Currently the kernel can not built with xcc. The toolchain may be built with crosstool-NG or buildroot.


Define CROSS_COMPILE=cross-compiler-spec environment variable to specify cross-compiler to be used. cross-compiler-spec is a path to cross-compiler binaries plus cross-compiler name up to its last component (e.g. if your cross-compiler is /opt/xtensa/tools/fsf/bin/xtensa-fsf-elf-gcc then specify CROSS_COMPILE=/opt/xtensa/tools/fsf/bin/xtensa-fsf-elf- to use it).


The kernel may be built in-tree of out-of-tree, building out-of-tree is usually cleaner and involves less actions when several configurations need to be built. Adding parameter O=build-dir-path to make controls out-of-tree kernel configuration/building.

The steps involved in building linux kernel are:

  1. Configure the kernel
  2. Build it

Configuring the kernel

Configuring the kernel creates build infrastructure and .config file in the build directory. .config file may be written from scratch, copied from the outside source or taken from a predefined configuration and edited. For a list of predefined configurations see contents of directory arch/xtensa/configs. It's a good idea to run configuration after copying external or predefined config, as newer kernel releases may have added/removed or changed configuration parameters and the config file may need to be updated.

  • to use external .config just copy it to the build directory
  • to use predefined .config run ARCH=xtensa CROSS_COMPILE=cross-compiler-spec make O=build-dir-path predefined_config_name
  • to edit existing configuration run ARCH=xtensa CROSS_COMPILE=cross-compiler-spec make O=build-dir-path menuconfig.

To search for a specific configuration item in curses interface use '/'. The following configuration parameters are important/interesting/worth checking:

  • CONFIG_XTENSA_VARIANT_CUSTOM: must be set when a custom core variant is used
  • CONFIG_XTENSA_VARIANT_CUSTOM_NAME: must specify custom core variant name
  • CONFIG_XTENSA_VARIANT_MMU: if set to 'N' will build noMMU kernel even when core variant actually supports MMU. Should always be set for MMUv2 cores.
  • CONFIG_HAVE_SMP: must always be set correctly, as presence of MX interrupt distributor affects external interrupts numbering.
  • CONFIG_INITIALIZE_XTENSA_MMU_INSIDE_VMLINUX: controls whether uImage will reinitialize memory mapping. Should be set for noMMU and MMUv3 cores, unless MMU is fully initialized by uBoot. Ignored for MMUv2 cores. Has no effect for Image.elf, as it has to initialize MMU either in reset vector or in vmlinux.
  • XTENSA_PLATFORM_*: must specify target platform. xtensa currently does not support multiplatform kernels.
  • CONFIG_CMDLINE: default kernel command line. Gets overridden by command line specified in the device tree (built-in or externally loaded) or passed from the bootloader.
  • BUILTIN_DTB: default kernel device tree. Only used when device tree is not supplied by the bootloader.
  • CONFIG_DEVTMPFS: enables kernel self-maintained /dev filesystem.
  • CONFIG_SERIAL_OF_PLATFORM: enables UART driver that may be instantiated from the device tree.
  • CONFIG_LD_NO_RELAX: disables link-time relaxation at kernel build. This is useful against linker relaxation bugs and currently speeds up the build significantly.

Building the kernel

  • to build kernel and modules run ARCH=xtensa CROSS_COMPILE=cross-compiler-spec make O=build-dir-path all
  • to build only the kernel run ARCH=xtensa CROSS_COMPILE=cross-compiler-spec make O=build-dir-path zImage
  • all commands supported by kernel build system may be listed with ARCH=xtensa make help

Features by release

Linux 3.17

  • Highmem on cores with aliasing cache.
  • New (simpler) method of configuring for specific core variant.

Linux 3.16

  • Stability: xtensa linux may be rebuilt natively.

Linux 3.15

  • Highmem.
  • KC705 board.

Linux 3.14

  • SMP.
  • Futex.
  • register spilling overhaul.
  • OpenCores ethernet works when connected to gigabit network.
  • c67x00 USB host is usable on XTFPGA.
  • TAP network works in ISS.

Linux 3.12

  • Kernel preemption.

Linux 3.11

  • Multihit exceptions fixed.
  • Static function tracer.

Linux 3.10

  • MMUv3 cores.
  • Lockdep/stack tracing.

Linux 3.9

  • TLS (THREADPTR register).
  • Oprofile.
  • ISS simdisk.

Linux 3.8

  • Device trees.
  • uImage generation.
  • IRQ subsystem overhaul (IRQ domains, medium-priority interrupts).
  • XTFPGA boards.
  • s32c1i-based atomic/bit operations and spinlocks.

Linux 3.7

  • Overall architecture port overhaul, mainline is alive again, builds and runs.
  • There were dragons prior to that release.

Kernel loadable modules using FLIX with L32R

The kernel module loader (for the Xtensa architecture) supports only the limited set of relocations needed for module loading. This includes, for example, relocation of literals referenced by L32R instructions. This loader is not given specific information about any custom TIE configured in the processor, and thus is currently not able to relocate L32R instructions encoded in a FLIX bundle.

To ensure kernel modules load properly, they need to avoid L32R instructions within FLIX instruction bundles.

Existing kernel code does not generate such instructions, so it is not susceptible. However, it is possible to generate FLIX instructions using assembly code, or using the Tensilica XCC compiler. In the case of assembly code, simply avoid using L32R or MOVI instructions within a FLIX instruction bundle, unless a MOVI is known to fit without expanding ("relaxing") into an L32R instruction. In the case of XCC, pass the -mno-flix to the compiler (xt-xcc) to avoid generating FLIX bundles.

Note: The use of Tensilica software tools (including XCC) for Linux development is described in the Tensilica OSKit Guide, available from Tensilica.

Debugging Kernel Loadable Modules

Debugging loadable modules isn't easy, a few pointers mentioned here might save you some time. There is a mechanism that Amit Kalie mentioned on his KGDB webpage on loading the module symbols into gdb while loading a module Debuging init_module.

The insmod command has a --map option that dumps the module component offsets needed by Amit's approach. Unfortunately the initial Xtensa buildroot snapshots have a version of insmod that doesn't provide this option. Also, while debugging the kernel it's not convenient to run insmod on the console of the target.

A workaround to this problem is to hack the kernel module.c file and enable debugging. 

   #if 1
   #define DEBUGP printk
   #else
   #define DEBUGP(fmt , a...)
   #endif

This will enable module.c to print the module section addresses. You then just list them in the gdb add-symbol-file command using that command's section (-s) options. Note that the .text section is specified without using the -s option: its address is given alone before any -s option. 

   final section addresses:                  [Kernel Console Log/Output]
       0xc02a9098 .note.gnu.build-id
       0xc02b1000 .init.literal
       0xc02a7000 .text
       0xc02b11d8 .init.text
       0xc02a90bc .rodata
       0xc02a92c4 .rodata.str1.4
       0xc02ac27c .data
       0xc02ac640 __param
       0xc02ac668 .gnu.linkonce.this_module
       0xc02ac76c .bss
       0xc02aaf0c .symtab
       0xc02ab8fc .strtab

   add-symbol-file /export/src/Transwitch/a2000_src/a2000_src/Linux_atlanta/ctlm-cpe/drivers/ctlmeth/ctlmeth.ko   \
       0xc02a7000                           \
       -s .data 0xc02ac27c                  \
       -s .init.text 0xc02b11d8             \
       -s .bss 0xc02ac76c                   \
       -s .init.literal 0xc02b1000          \
       -s  .rodata 0xc02a90bc

You likely want to compile your modules unoptimized and unstripped to facilitate debugging and provide the path to the module source to gdb with the dir command. For example: 

   dir /home/pdelaney/src/Transwitch/a2000_src/a2000_src/Linux_atlanta/ctlm-cpe/drivers/ctlmeth/
Retrieved from "http://wiki.linux-xtensa.org/index.php?title=Linux_Kernel&oldid=732"