Platform Porting - Revision history

Chris: /* Adding a new Platform to the Kernel */

2013-03-18T22:03:27Z

Adding a new Platform to the Kernel

← Older revision		Revision as of 22:03, 18 March 2013
Line 4:		Line 4:

	# Modify <code>arch/xtensa/Kconfig</code> and <code>arch/xtensa/Makefile</code> to add support for the new platform.		# Modify <code>arch/xtensa/Kconfig</code> and <code>arch/xtensa/Makefile</code> to add support for the new platform.
			# Create a directory with the name of the platform in the architecture part of the kernel under <code>arch/xtensa/platforms/</code>. This directory should contain the source files to support hardware components other than generic devices, such as PCI host-bridges, etc.
	# Create a directory for the header files: <code>arch/xtensa/platforms/''name''/include</code>. It must at least contain the <code>hardware.h</code> file to describe some fundamental hardware settings.		# Create a directory for the header files: <code>arch/xtensa/platforms/''name''/include</code>. It must at least contain the <code>hardware.h</code> file to describe some fundamental hardware settings.
	# Create a directory with the name of the platform in the architecture part of the kernel under <code>arch/xtensa/platform/</code>. This directory should contain the source files to support hardware components other than generic devices, such as PCI host-bridges, etc.
	# ''(optional)'' add a default configuration file for the platform with the name <code>''name''_defconfig</code> to <code>arch/xtensa/configs</code>.		# ''(optional)'' add a default configuration file for the platform with the name <code>''name''_defconfig</code> to <code>arch/xtensa/configs</code>.

Chris: /* Adding a new Platform to the Kernel */

2013-03-18T22:02:15Z

Adding a new Platform to the Kernel

← Older revision		Revision as of 22:02, 18 March 2013
Line 4:		Line 4:

	# Modify <code>arch/xtensa/Kconfig</code> and <code>arch/xtensa/Makefile</code> to add support for the new platform.		# Modify <code>arch/xtensa/Kconfig</code> and <code>arch/xtensa/Makefile</code> to add support for the new platform.
	# Create a directory for the header files: <code>~~include~~/~~asm-~~xtensa/~~platform-~~''name''</code>. It must at least contain the <code>hardware.h</code> file to describe some fundamental hardware settings.		# Create a directory for the header files: <code>arch/xtensa/platforms/''name''/include</code>. It must at least contain the <code>hardware.h</code> file to describe some fundamental hardware settings.
	# Create a directory with the name of the platform in the architecture part of the kernel under <code>arch/xtensa/platform/</code>. This directory should contain the source files to support hardware components other than generic devices, such as PCI host-bridges, etc.		# Create a directory with the name of the platform in the architecture part of the kernel under <code>arch/xtensa/platform/</code>. This directory should contain the source files to support hardware components other than generic devices, such as PCI host-bridges, etc.
	# ''(optional)'' add a default configuration file for the platform with the name <code>''name''_defconfig</code> to <code>arch/xtensa/configs</code>.		# ''(optional)'' add a default configuration file for the platform with the name <code>''name''_defconfig</code> to <code>arch/xtensa/configs</code>.

Chris: New page: == Adding a new Platform to the Kernel == The easiest way to add support for a new platform for Xtensa is usually to look at the directories of one of the platforms already supported for ...

2007-04-24T07:02:53Z

New page: == Adding a new Platform to the Kernel == The easiest way to add support for a new platform for Xtensa is usually to look at the directories of one of the platforms already supported for ...

New page

== Adding a new Platform to the Kernel ==

The easiest way to add support for a new platform for Xtensa is usually to look at the directories of one of the platforms already supported for Xtensa and to copy and modify those files. Drivers to support on-chip devices should go to the generic driver directory instead of the architecture directory. Adding a new platform should not require other changes to generic sources outside the platform specific directories. Modifications to the kernel are, therefore, mostly limited to the following places:

# Modify <code>arch/xtensa/Kconfig</code> and <code>arch/xtensa/Makefile</code> to add support for the new platform.
# Create a directory for the header files: <code>include/asm-xtensa/platform-''name''</code>. It must at least contain the <code>hardware.h</code> file to describe some fundamental hardware settings.
# Create a directory with the name of the platform in the architecture part of the kernel under <code>arch/xtensa/platform/</code>. This directory should contain the source files to support hardware components other than generic devices, such as PCI host-bridges, etc.
# ''(optional)'' add a default configuration file for the platform with the name <code>''name''_defconfig</code> to <code>arch/xtensa/configs</code>.

=== Modify <code>Kconfig</code> and <code>Makefile</code> ===

Adding support for a new platform to the build system of Linux only requires to modify <code>Kconfig</code> and <code>Makefile</code>. The new entry in <code>Kconfig</code> allows the configuration scripts to pick up the new platform and the change in <code>Makefile</code> instructs the build process to enter the platform directory, if selected.

<code>Kconfig</code>

config XTENSA_PLATFORM_''NAME''
bool ''NAME''
help
''descriptive text''

<code>Makefile</code>
platform-$(CONFIG_XTENSA_PLATFORM_''NAME'') := ''directory-name''

=== Directory for the Headers ===

Any platform specific header files should go to the <code>platform-''name''</code> directory under <code>include/asm-xtensa/</code>. It should contain at least the <code>hardware.h</code> file that describes the physical memory configuration.

/*
* Memory configuration.
*/

#define PLATFORM_DEFAULT_MEM_START 0x00000000
#define PLATFORM_DEFAULT_MEM_SIZE 0x08000000

=== Directory for the new Platform ===

All source files for the new platform should be in <code>arch/xtensa/platforms/''name''</code>. The Xtensa port provides a few hooks that can be used by the platform for initialization and other purposes. These functions are defined as <code>weak</code> symbols with a default 'dummy' implementation in the generic Xtensa sources. Platforms can, therefore, overwrite the default implementation simply by defining the function in one of its sources.

<code>extern void platform_init(bp_tag_t* bootparams);</code> 
The kernel calls this function early in the boot process prior to initializing the MMU. This allows the platform to perform early initializations of components. The argument <code>bootparams</code> is a list of configuration tags passed from the boot-loader (see also [[Boot Loader]]

<code>extern void platform_setup (char **);</code> 
This function is called from <code>setup_arch</code> with a pointer to the command-line string.

<code>extern void platform_init_irq (void);</code> 
This function, called from <code>init_IRQ</code>, allows platforms to initialize external interrupt controllers.

<code>extern void platform_restart (void);</code> 
<code>extern void platform_halt (void);</code> 
<code>extern void platform_power_off (void);</code> 
The kernel calls one of these functions to either restart, halt, or reboot the system.

<code>extern void platform_idle (void);</code> 
This is the ''idle'' function called whenever there is no thread or process ready.

<code>extern void platform_heartbeat (void);</code> 
The kernel calls this function every HZ interval.

<code>extern void platform_pcibios_init (void);</code> 
The kernel calls this function in case PCI is enabled to allow the platform to setup the PCI bus.

<code>extern int platform_pcibios_fixup (void);</code> 
The kernel calls this function in case PCI is enabled to allow the platform to modify PCI configuration after scanning the PCI bus has completed.

<code>extern void platform_calibrate_ccount (void);</code> 
Platforms that can identify the processor speed should implement this function. It allows the platform to set the cpu clock frequency (if CONFIG_XTENSA_CALIBRATE is enabled). This function should determine the processor speed and set the following variables accordingly:
* <code>ccount_per_jiffy</code> - This is the number of CCOUNT ticks per <code>jiffy</code>. 'A jiffy' is the time between two ticks, where HZ describes the number of ticks per seconds.
* <code>ccount_nsec</code> - This is the time (in nano-seconds) between two subsequent CCOUNT ticks.