doc: Terminology--Replace 'platform' with 'board'
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:
parent
3bd79cae93
commit
7c151cfcc3
9 changed files with 15 additions and 15 deletions
|
@ -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
|
||||
|
|
|
@ -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.
|
||||
|
|
|
@ -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.
|
||||
|
||||
|
|
|
@ -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.
|
||||
|
||||
|
|
|
@ -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).
|
||||
|
||||
|
|
|
@ -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.
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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:
|
||||
|
|
|
@ -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
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue