Changeset 3de74ba in rtems-docs
- Timestamp:
- 01/11/19 13:44:36 (5 years ago)
- Branches:
- 5, master
- Children:
- 0facb9d
- Parents:
- 89a33b3
- git-author:
- Sebastian Huber <sebastian.huber@…> (01/11/19 13:44:36)
- git-committer:
- Sebastian Huber <sebastian.huber@…> (01/14/19 06:15:27)
- Location:
- user
- Files:
-
- 1 deleted
- 7 edited
Legend:
- Unmodified
- Added
- Removed
-
user/bsps/index.rst
r89a33b3 r3de74ba 3 3 .. Copyright (C) 2018 embedded brains GmbH 4 4 5 .. _B oardSupportPackages:5 .. _BSPs: 6 6 7 7 Board Support Packages … … 17 17 target hardware. 18 18 19 You can see the current BSP list in the RTEMS sources by asking RTEMS with: 20 21 .. code-block:: shell 22 23 $ ./rtems-bsps 24 19 25 .. toctree:: 20 26 21 bsps-aarch6422 bsps-arm23 bsps-bfin24 bsps-epiphany25 bsps-i38626 bsps-lm3227 bsps-m68k28 bsps-microblaze29 bsps-mips30 bsps-moxie31 bsps-nios232 bsps-or1k33 bsps-powerpc34 bsps-riscv35 bsps-sh36 bsps-sparc6437 bsps-sparc38 bsps-v85039 bsps-x86_6427 bsps-aarch64 28 bsps-arm 29 bsps-bfin 30 bsps-epiphany 31 bsps-i386 32 bsps-lm32 33 bsps-m68k 34 bsps-microblaze 35 bsps-mips 36 bsps-moxie 37 bsps-nios2 38 bsps-or1k 39 bsps-powerpc 40 bsps-riscv 41 bsps-sh 42 bsps-sparc64 43 bsps-sparc 44 bsps-v850 45 bsps-x86_64 -
user/exe/index.rst
r89a33b3 r3de74ba 2 2 3 3 .. Copyright (C) 2018 Chris Johns <chrisj@rtems.org> 4 5 .. _Executables: 4 6 5 7 Executables -
user/glossary/index.rst
r89a33b3 r3de74ba 6 6 7 7 .. glossary:: 8 9 ABI 10 Application Binary Interface 8 11 9 12 Architecture -
user/hardware/architectures.rst
r89a33b3 r3de74ba 1 1 .. SPDX-License-Identifier: CC-BY-SA-4.0 2 2 3 .. Copyright (C) 2019 embedded brains GmbH 4 .. Copyright (C) 2019 Sebastian Huber 3 5 .. Copyright (C) 2016 Chris Johns <chrisj@rtems.org> 4 6 … … 7 9 .. index:: Architectures 8 10 9 An RTEMS architecture is a class or family of a processor that RTEMS10 supports.The RTEMS architecture model follows the architecture model of11 An RTEMS architecture is a class or family of a processor architecture that 12 RTEMS supports. The RTEMS architecture model follows the architecture model of 11 13 GCC. An architecture in GCC results in a specific RTEMS GCC compiler. This 12 14 compiler may support a range of processors in the family that may have 13 differences in instructions sets or floating point support. RTEMS configures 14 GCC to create separate runtime libraries for each supported instruction set and 15 floating point unit in the architecture. This is termed **multlib**. Multlibs 16 are manage automatically by GCC by selecting a specific instruction set or 17 specific device in a family. 15 differences in instructions sets, floating point support or other aspects. 16 RTEMS configures GCC to create separate runtime libraries for each supported 17 instruction set, floating point unit, vector unit, word size (e.g. 32-bit and 18 64-bit), endianess, code model, :ref:term:`ABI`, processor errata workarounds, 19 and so on in the architecture. This is termed *multilib*. Multilibs are chosen 20 automatically by GCC via selecting a specific set of machine options. 18 21 19 RTEMS executables are statically linked for a specific target therefore a 20 precise and exact match can be made for the hardware that extracts the best 21 possible performance. The compiler supports the variants to the instruction set 22 and RTEMS extends the specialization to specific processors in an 23 architecture. This specialization gives RTEMS a finer resolution of features 24 and capabilites a specific device may offer allowing the kernel, drivers and 25 application to make the most of those resources. The trade off is portability 26 however this is not important because the executable are statically linked for 27 a single target. 22 You can query the multilibs of a specific RTEMS GCC compiler via the 23 ``-print-multi-lib`` option: 24 25 .. code-block:: shell 26 27 $ sparc-rtems5-gcc -print-multi-lib 28 .; 29 soft;@msoft-float 30 v8;@mcpu=v8 31 leon3;@mcpu=leon3 32 leon3v7;@mcpu=leon3v7 33 leon;@mcpu=leon 34 leon3/gr712rc;@mcpu=leon3@mfix-gr712rc 35 leon3v7/gr712rc;@mcpu=leon3v7@mfix-gr712rc 36 leon/ut699;@mcpu=leon@mfix-ut699 37 leon/at697f;@mcpu=leon@mfix-at697f 38 soft/v8;@msoft-float@mcpu=v8 39 soft/leon3;@msoft-float@mcpu=leon3 40 soft/leon3v7;@msoft-float@mcpu=leon3v7 41 soft/leon;@msoft-float@mcpu=leon 42 soft/leon3/gr712rc;@msoft-float@mcpu=leon3@mfix-gr712rc 43 soft/leon3v7/gr712rc;@msoft-float@mcpu=leon3v7@mfix-gr712rc 44 soft/leon/ut699;@msoft-float@mcpu=leon@mfix-ut699 45 soft/leon/at697f;@msoft-float@mcpu=leon@mfix-at697f 46 47 Each printed line represents a multilib. The ``.`` corresponds to the default 48 multilib. It is used if a set of machine options does not match to a 49 specialized multilib. The string before the ``;`` describes the directory in 50 the GCC installation used for the particular multilib. After the ``;`` the set 51 of machine options for this multilib follows separated by ``@`` characters. 52 53 You can figure out the multilib selected by GCC for a set of machine options 54 with the ``-print-multi-directory`` option: 55 56 .. code-block:: shell 57 58 $ sparc-rtems5-gcc -print-multi-directory -mcpu=leon3 59 leon3 60 61 It is crucial that the RTEMS BSP, support libraries and the application code 62 are compiled consistently with a compatible set of machine options. Otherwise, 63 in the best case errors during linking will occur or you may end up silently 64 with undefined behaviour which results in sporadic run-time crashes. A wrong 65 set of machine options may result in a running application, however, with 66 degraded performance, e.g. hardware floating point unit is not used by the 67 mathematical library. 68 69 For a list of architectures supported by RTEMS please have a look at the 70 sections of the :ref:`Board Support Packages <BSPs>` chapter. 71 72 :ref:`RTEMS executables <Executables>` are statically linked for a specific 73 target therefore a precise and exact match can be made for the hardware that 74 extracts the best possible performance. The compiler supports the variants to 75 the instruction set and RTEMS extends the specialization to specific processors 76 in an architecture. This specialization gives RTEMS a finer resolution of 77 features and capabilities a specific device may offer allowing the kernel, 78 drivers and application to make the most of those resources. The trade off is 79 portability however this is not important because the executable are statically 80 linked for a single target. 28 81 29 82 .. note:: … … 33 86 that is equivalent to statically linked executable of the same code. Dynamic 34 87 loading is a system level tool for system architects. 35 36 RTEMS supports 18 architectures:37 38 - arm39 - bfin40 - epiphany41 - i38642 - lm3243 - m68k44 - mips45 - moxie46 - nios247 - no_cpu48 - or1k49 - riscv50 - powerpc51 - sh52 - sparc53 - sparc6454 - v85055 - x86_64 -
user/hardware/index.rst
r89a33b3 r3de74ba 5 5 .. _Hardware: 6 6 7 Hardware8 ******** 7 Target Hardware 8 *************** 9 9 .. index:: Hardware 10 11 This section discusses supported Hardware, Architectures, Board Support 12 Packages, and running RTEMS on real hardware and simulators. 10 .. index:: Target Hardware 13 11 14 12 .. toctree:: … … 16 14 targets 17 15 architectures 18 bsps19 16 tiers -
user/hardware/targets.rst
r89a33b3 r3de74ba 9 9 .. index:: Targets 10 10 11 Hardware that can run RTEMS is often referred to as a *target* because RTEMS is 12 specifically aimed at that hardware or target. An RTEMS executable is 13 statically linked and executes in a single address space on the target 14 hardware. A statically linked executable means the RTEMS Kernel, drivers, third 15 party packages and application code is linked into a single executable image. A 16 single address space means no virtual memory and no memory protected process 17 address space is running within the RTEMS arena and the RTEMS Kernel, drivers 18 and application have unprotected access to the whole address space and all 19 hardware.11 *Target hardware* that can run RTEMS is often referred to simply as the 12 *target* because RTEMS is specifically aimed at that target hardware. An RTEMS 13 executable is statically linked and executes in a single address space on the 14 target hardware. A statically linked executable means the RTEMS Kernel, 15 drivers, third party packages and application code is linked into a single 16 executable image. A single address space means no virtual memory and no memory 17 protected process address space is running within the RTEMS arena and the RTEMS 18 executive, drivers and application have unprotected access to the whole address 19 space and all hardware. 20 20 21 Target hardware supported by RTEMS has a Board Support Package or BSP. A BSP is22 a specific instance of an RTEMS architecture that allows the creation of an 23 RTEMS executable. You can view the layering as:21 Target hardware supported by RTEMS has a :ref:`Board Support Package <BSPs>` or 22 BSP. A BSP is a specific instance of an RTEMS architecture that allows the 23 creation of an RTEMS executable. You can view the layering as: 24 24 25 25 .. comment Build image with: … … 32 32 :alt: Software Layers on Hardware 33 33 34 RTEMS Targets are grouped by architectures and within an architecture there are34 RTEMS targets are grouped by architectures and within an architecture there are 35 35 a number of Board Support Packages or BPSs. An architecture is a specific class 36 36 or family of processors and can be large such as ARM or specific such as the -
user/index.rst
r89a33b3 r3de74ba 13 13 | © 2018 Vidushi Vashishth 14 14 | © 2017 Tanu Hari Dixit 15 | © 2016, 201 7embedded brains GmbH16 | © 2016, 201 7Sebastian Huber15 | © 2016, 2019 embedded brains GmbH 16 | © 2016, 2019 Sebastian Huber 17 17 | © 2012, 2015 Chris Johns 18 18 | © 1988, 2018 On-Line Applications Research Corporation (OAR)
Note: See TracChangeset
for help on using the changeset viewer.