Platform Porting

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:

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

Modify Kconfig and Makefile

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

Kconfig

config XTENSA_PLATFORM_NAME
    bool NAME
    help
    descriptive text

Makefile

platform-$(CONFIG_XTENSA_PLATFORM_NAME)           := directory-name

Directory for the Headers

Any platform specific header files should go to the platform-name directory under include/asm-xtensa/. It should contain at least the hardware.h 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 arch/xtensa/platforms/name. The Xtensa port provides a few hooks that can be used by the platform for initialization and other purposes. These functions are defined as weak 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.

extern void platform_init(bp_tag_t* bootparams);
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 bootparams is a list of configuration tags passed from the boot-loader (see also Boot Loader

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

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

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

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

extern void platform_heartbeat (void);
The kernel calls this function every HZ interval.

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

extern int platform_pcibios_fixup (void);
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.

extern void platform_calibrate_ccount (void);
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:

• ccount_per_jiffy - This is the number of CCOUNT ticks per jiffy. 'A jiffy' is the time between two ticks, where HZ describes the number of ticks per seconds.
• ccount_nsec - This is the time (in nano-seconds) between two subsequent CCOUNT ticks.