KnownIssues - Revision history

Chris: Blanked the page

2013-11-11T18:59:28Z

Blanked the page

← Older revision		Revision as of 18:59, 11 November 2013
Line 1:		Line 1:
	~~= 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 [http://bugs.linux-xtensa.org 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 [http://kgdb.linsyssoft.com/initmodule.htm Debuging init_module].

	~~The [http://linux.about.com/od/commands/l/blcmdl8_insmod.htm <tt>insmod</tt> command] has a <tt>''--map''</tt>~~
	~~option that dumps the module component offsets needed by Amit's approach.~~
	Unfortunately the initial Xtensa buildroot snapshots have a version of <tt>insmod</tt> that doesn't provide this option. Also, while debugging the kernel it's not convenient to run <tt>insmod</tt> on the console of the target.

	~~A workaround to this problem is to hack the kernel <tt>module.c</tt> file and enable debugging.~~

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

	~~This will enable <tt>module.c</tt> to print the module section addresses. You then just list them in the gdb <tt>add-symbol-file</tt> command using that command's section (<tt>''-s''</tt>) options.~~
	~~Note that the <tt>.text</tt> section is specified without using the <tt>''-s''</tt> option: its address is given alone before any <tt>''-s''</tt> 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 <tt>dir</tt> command.~~
	~~For example:~~
	~~dir /home/pdelaney/src/Transwitch/a2000_src/a2000_src/Linux_atlanta/ctlm-cpe/drivers/ctlmeth/~~

Chris: /* 128 MB RAM Limit */

2013-03-11T00:27:37Z

128 MB RAM Limit

← Older revision		Revision as of 00:27, 11 March 2013
Line 10:		Line 10:
	== 128 MB RAM Limit ==		== 128 MB RAM Limit ==

	Kernel highmem support has not yet been implemented, 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 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 ==		== Kernel loadable modules using FLIX with L32R ==

Piet at 20:24, 14 October 2009

2009-10-14T20:24:26Z

← Older revision		Revision as of 20:24, 14 October 2009
Line 66:		Line 66:
	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 <tt>dir</tt> command.		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 <tt>dir</tt> command.
	For example:		For example:
	dir /home/pdelaney/src/~~Transswitch~~/a2000_src/a2000_src/Linux_atlanta/ctlm-cpe/drivers/ctlmeth/		dir /home/pdelaney/src/Transwitch/a2000_src/a2000_src/Linux_atlanta/ctlm-cpe/drivers/ctlmeth/

Piet at 20:23, 14 October 2009

2009-10-14T20:23:26Z

← Older revision		Revision as of 20:23, 14 October 2009
Line 56:		Line 56:
	0xc02ab8fc .strtab		0xc02ab8fc .strtab

	add-symbol-file /export/src/~~Transswitch~~/a2000_src/a2000_src/Linux_atlanta/ctlm-cpe/drivers/ctlmeth/ctlmeth.ko \		add-symbol-file /export/src/Transwitch/a2000_src/a2000_src/Linux_atlanta/ctlm-cpe/drivers/ctlmeth/ctlmeth.ko \
	0xc02a7000 \		0xc02a7000 \
	-s .data 0xc02ac27c \		-s .data 0xc02ac27c \

Marc: Typo/consistency fixes

2009-10-14T14:49:14Z

Typo/consistency fixes

← Older revision		Revision as of 14:49, 14 October 2009
Line 27:		Line 27:
	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 [http://kgdb.linsyssoft.com/initmodule.htm Debuging init_module].		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 [http://kgdb.linsyssoft.com/initmodule.htm Debuging init_module].

	The [http://linux.about.com/od/commands/l/blcmdl8_insmod.htm insmod command] has a ''--map''		The [http://linux.about.com/od/commands/l/blcmdl8_insmod.htm <tt>insmod</tt> command] has a <tt>''--map''</tt>
	option that dumps the module component offsets needed by Amit's approach.		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 ~~debuging~~ the kernel it's not convenient to run insmod on the console of the target.		Unfortunately the initial Xtensa buildroot snapshots have a version of <tt>insmod</tt> that doesn't provide this option. Also, while debugging the kernel it's not convenient to run <tt>insmod</tt> on the console of the target.

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

	#if 1		#if 1
Line 39:		Line 39:
	#endif		#endif

	This will enable module.c to print the module section addresses. You then just them to the gdb add-symbol-file command ~~after~~ section '-s' options.		This will enable <tt>module.c</tt> to print the module section addresses. You then just list them in the gdb <tt>add-symbol-file</tt> command using that command's section (<tt>''-s''</tt>) options.
	Note that the .text section ~~isn~~'~~t prefixed by~~ '''-s''' option ~~and the section name~~.		Note that the <tt>.text</tt> section is specified without using the <tt>''-s''</tt> option: its address is given alone before any <tt>''-s''</tt> option.

	final section addresses: [Kernel Console Log/Output]		final section addresses: [Kernel Console Log/Output]
Line 64:		Line 64:
	-s .rodata 0xc02a90bc		-s .rodata 0xc02a90bc

	You likely want to compile your modules unoptimized and unstripped to ~~faciltate~~ debugging and provide the path to the module source to gdb with the 'dir' command.		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 <tt>dir</tt> command.
	Ex:		For example:
	dir /home/pdelaney/src/Transswitch/a2000_src/a2000_src/Linux_atlanta/ctlm-cpe/drivers/ctlmeth/		dir /home/pdelaney/src/Transswitch/a2000_src/a2000_src/Linux_atlanta/ctlm-cpe/drivers/ctlmeth/

Piet at 08:23, 14 October 2009

2009-10-14T08:23:08Z

@@ Line 17: / Line 17: @@
 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.

Marc: /* Kernel loadable modules using FLIX with L32R */ Mention the OSKit guide for info about XCC for Linux.

2008-12-09T22:10:38Z

Kernel loadable modules using FLIX with L32R: Mention the OSKit guide for info about XCC for Linux.

← Older revision		Revision as of 22:10, 9 December 2008
Line 20:		Line 20:
	Existing kernel code does not generate such instructions, so it is not susceptible.		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.		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.

Marc: Moved hardware contents to another page

2008-12-09T22:02:32Z

Moved hardware contents to another page

← Older revision		Revision as of 22:02, 9 December 2008
Line 1:		Line 1:
	= Known Kernel Issues and Limitations =		= Known Kernel Issues and Limitations =

	~~== Hardware System Limitations ==~~		This page contains recommendations, notes, limitations, and requirements for the development of software on systems using Xtensa processors running Linux.

	This ~~section contains recommendations, notes, limitations, and requirements for the development of hardware systems using Xtensa processors running Linux.~~

	~~'''Recommendations'''~~

	For future compatibility with Linux kernel releases for the Xtensa architecture, please include support for the atomic load-conditional-store S32C1I instruction when designing your memory system. The memory system must provide for the atomic update of a memory location by holding off the load until all other transactions are complete, and holding off any other transactions once the atomic operation has started until it has finished. Tensilica's PIF Bridges all support this but if you are using other bridges this implementation should be verified.

	Please contact Tensilica support if planning to use or build a linux based system that may require more than 128 MB of main RAM for an Xtensa processor configured with large caches (cache size > 4*N kB, for an N-way set associative cache). There are some system limitations that should be evaluated before proceeding.

	~~== Software Limitations ==~~

	~~This section~~ 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		Eventually all these should be duly reported and tracked in
Line 20:		Line 8:


	=== 128 MB RAM Limit ===		== 128 MB RAM Limit ==

	Kernel highmem support has not yet been implemented, 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 highmem support has not yet been implemented, 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 ===		== 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.		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.

Marc: Gather other system info pages, and add info about kernel modules with FLIX and L32R

2008-12-09T21:53:59Z

Gather other system info pages, and add info about kernel modules with FLIX and L32R

New page

= Known Kernel Issues and Limitations =

== Hardware System Limitations ==

This section contains recommendations, notes, limitations, and requirements for the development of hardware systems using Xtensa processors running Linux.

'''Recommendations'''

For future compatibility with Linux kernel releases for the Xtensa architecture, please include support for the atomic load-conditional-store S32C1I instruction when designing your memory system. The memory system must provide for the atomic update of a memory location by holding off the load until all other transactions are complete, and holding off any other transactions once the atomic operation has started until it has finished. Tensilica's PIF Bridges all support this but if you are using other bridges this implementation should be verified.

Please contact Tensilica support if planning to use or build a linux based system that may require more than 128 MB of main RAM for an Xtensa processor configured with large caches (cache size > 4*N kB, for an N-way set associative cache). There are some system limitations that should be evaluated before proceeding.

== Software Limitations ==

This section 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 [http://bugs.linux-xtensa.org 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, 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.