michaelh/zephyr
1
0
Fork 0
Code Releases Activity

doc: Terminology--Replace 'platform' with 'board'

Browse source 
Replaced the term "platform" with "board" or "SoC" depending
on context as per, ZEP-534.

Change-Id: I14c13d4eed429fe6e41e2221d6ff6afe97e942eb
Signed-off-by: Evan Couzens <evanx.couzens@intel.com>
This commit is contained in:
viggo.jf.intel.com 2016-08-11 13:50:45 -07:00 • committed by Inaky Perez-Gonzalez
commit 7c151cfcc3
9 changed files with 15 additions and 15 deletions
Download patch file Download diff file Expand all files Collapse all files

2
doc/api/api.rst
View file

@ -12,7 +12,7 @@ microkernel APIs. If you are looking for a specific API, enter it on the
search box. The search results display all sections containing information
about that API.
The use of the Zephyr APIs is the same for all platforms and boards.
The use of the Zephyr APIs is the same for all SoCs and boards.
.. toctree::
:maxdepth: 2

4
doc/crypto/tinycrypt.rst
View file

@ -81,7 +81,7 @@ Design Goals
************
* Minimize the code size of each cryptographic primitive. This means minimize
the size of a platform-independent implementation, as presented in TinyCrypt.
the size of a board-independent implementation, as presented in TinyCrypt.
Note that various applications may require further features, optimizations with
respect to other metrics and countermeasures for particular threats. These
peculiarities would increase the code size and thus are not considered here.
@ -104,7 +104,7 @@ General Remarks
***************
* TinyCrypt does **not** intend to be fully side-channel resistant. Due to the
variety of side-channel attacks, many of them making certain platforms
variety of side-channel attacks, many of them making certain boards
vulnerable. In this sense, instead of penalizing all library users with
side-channel countermeasures such as increasing the overall code size,
TinyCrypt only implements certain generic timing-attack countermeasures.

2
doc/drivers/drivers.rst
View file

@ -45,7 +45,7 @@ are listed below.
Synchronous Calls
*****************
Zephyr provides a set of device drivers for multiple platforms. Each driver
Zephyr provides a set of device drivers for multiple boards. Each driver
should support an interrupt-based implementation, rather than polling, unless
the specific hardware does not provide any interrupt.

4
doc/getting_started/getting_started.rst
View file

@ -118,7 +118,7 @@ After building an application successfully, the results can be found in the
The ELF binaries generated by the build system are named by default
:file:`zephyr.elf`. This value can be overridden in the application configuration
The build system generates different names for different use cases depending on
the hardware and platforms used.
the hardware and boards used.
Using Custom and 3rd Party Cross Compilers
==========================================
@ -190,7 +190,7 @@ To run an application using the ARM qemu_cortex_m3 board configuration, type:
$ make BOARD=qemu_cortex_m3 ARCH=arm qemu
QEMU is not supported on all boards and platforms. When developing for a specific
QEMU is not supported on all boards and SoCs. When developing for a specific
hardware target you should always test on the actual hardware and should not
rely on testing in the QEMU emulation environment only.

2
doc/kernel/nanokernel/nanokernel_kernel_event_logger.rst
View file

@ -97,7 +97,7 @@ More details are provided in function description.
Timestamp
*********
The timestamp used by the kernel event logger is 32-bit LSB of platform HW timer (for example
The timestamp used by the kernel event logger is 32-bit LSB of board HW timer (for example
Lakemont APIC timer for Quark SE). This timer period is very small and leads to timestamp
wraparound happening quite often (e.g. every 134s for Quark SE).

4
doc/kernel/overview/source_tree.rst
View file

@ -8,13 +8,13 @@ each of which may have one or more additional levels of subdirectories
which are not described here.
:file:`arch`
Architecture-specific nanokernel and platform code. Each supported
Architecture-specific nanokernel and board code. Each supported
architecture has its own subdirectory, which contains additional
subdirectories for the following areas:
* architecture-specific nanokernel source files
* architecture-specific nanokernel include files for private APIs
* platform-specific code
* board-specific code
:file:`boards`
Board related code and configuration files.

2
doc/porting/porting.rst
View file

@ -4,7 +4,7 @@ Porting Guides
##############
This section contains details regarding porting the Zephyr kernel to new
architectures, platforms and boards.
architectures, SoCs and boards.
.. toctree::
:maxdepth: 1

6
doc/reference/kbuild/kbuild_kconfig.rst
View file

@ -65,7 +65,7 @@ Default Configurations
======================
The default configuration files define the default configuration for a specific
kernel on a specific platform. For example:
kernel on a specific SoC. For example:
* :file:`arch/arm/configs`,
* :file:`arch/x86/configs` and
@ -73,11 +73,11 @@ kernel on a specific platform. For example:
All the default configuration files must end with the suffix _defconfig. For
example, the :file:`galileo_defconfig` file contains the configuration
information for the galileo platform.
information for the galileo board.
The :file:`Makefile.inc` file uses defconfig files to provide a clean interface
to developers using environment variables to define the kernel type and the
platform of new projects. Developers can provide the build system with a
board of new projects. Developers can provide the build system with a
target's defconfig. The build system takes the specified defconfig file and
sets it as the current :file:`.config` file for the current project. For
example:

4
doc/reference/kbuild/kbuild_project.rst
View file

@ -27,7 +27,7 @@ A common application project is composed of the following files:
* **Makefile**: Defines the application's build process and integrates the
developer's application with the kernel's build system.
* **Configuration file**: Allows the developer to override the platform's
* **Configuration file**: Allows the developer to override the board's
default configuration.
* **MDEF**: Defines the set of kernel objects that the the application
@ -76,7 +76,7 @@ The following predefined variables configure the development project:
:file:`$(PROJECT_BASE/)src/` by default. This directory name should end
with slash **'/'**.
* :makevar:`BOARD`: Selects the platform that the application's
* :makevar:`BOARD`: Selects the board that the application's
build will use for the default configuration.
* :makevar:`KERNEL_TYPE`: Selects the kernel type that the application's