Known Kernel Issues and Limitations
This page contains recommendations, notes, limitations, and requirements for the development of software on systems using Xtensa processors running Linux.
Eventually all these should be duly reported and tracked in the Mantis bug tracker. For the time being, here are some of the main known issues (this is by no means an exhaustive list!).
128 MB RAM Limit
Kernel highmem support has not yet been implemented in the main kernel tree, thus restricting generally usable RAM to the first 128 MB (starting from physical address zero). Implementing kernel highmem support should release this limitation, but it isn't yet clear whether an implementation is practical in the presence of cache aliasing (caches larger than 4 x N kB, for an N-way set-associative cache) on RB-200x release or earlier Tensilica processors.
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: