| /Zephyr-Core-3.4.0/doc/develop/west/ |
| D | build-flash-debug.rst | 1 .. _west-build-flash-debug:
8 ``build``, ``flash``, ``debug``, ``debugserver`` and ``attach``.
23 Building: ``west build``
26 .. tip:: Run ``west build -h`` for a quick overview.
28 The ``build`` command helps you build Zephyr applications from source. You can
33 - If there is a Zephyr build directory named :file:`build` in your current
35 run ``west build`` from a Zephyr build directory.
37 - Otherwise, if you run ``west build`` from a Zephyr application's source
38 directory and no build directory is found, a new one is created and the
44 The easiest way to use ``west build`` is to go to an application's root
[all …]
|
| D | without-west.rst | 13 - specifying the locations of these repositories to the Zephyr build
27 Otherwise, Zephyr's build system will find it and may try to use
52 You can build a Zephyr application using CMake and Ninja (or make) directly
58 :goals: build
62 When building with west installed, the Zephyr build system will use it to set
63 :ref:`ZEPHYR_MODULES <important-build-vars>`.
66 these repositories, the build will still work.
81 Running build system targets like ``ninja flash``, ``ninja debug``,
83 <west-build-flash-debug>`. For example, ``ninja flash`` calls ``west
89 If you want to use these build system targets but do not want to
[all …]
|
| D | sign.rst | 13 The Zephyr build system has special support for signing binaries for use with
15 developers. You can both build and sign this type of application binary in one
20 build system will do it for you.
29 west build -b YOUR_BOARD bootloader/mcuboot/boot/zephyr -d build-mcuboot
30 west build -b YOUR_BOARD zephyr/samples/hello_world -d build-hello-signed -- \
34 west flash -d build-mcuboot
35 west flash -d build-hello-signed
47 - :kconfig:option:`CONFIG_BOOTLOADER_MCUBOOT`: build the application for loading by
57 to run ``pip3 install imgtool``, then retry with a pristine build directory.
61 serial console when you run ``west flash -d build-mcuboot``:
[all …]
|
| /Zephyr-Core-3.4.0/tests/drivers/build_all/pwm/ |
| D | testcase.yaml | 7 drivers.pwm.gecko.build:
10 drivers.pwm.imx.build:
13 drivers.pwm.litex.build:
16 drivers.pwm.mcux.ftm.build:
19 drivers.pwm.mcux.pwt.build:
24 drivers.pwm.mcux.tpm.build:
27 drivers.pwm.mcux.build:
30 drivers.pwm.mcux.sctimer.build:
33 drivers.pwm.rv32m1.tpm.build:
36 drivers.pwm.sifive.build:
[all …]
|
| /Zephyr-Core-3.4.0/tests/drivers/build_all/adc/ |
| D | testcase.yaml | 7 drivers.adc.build:
18 drivers.adc.cc32xx.build:
21 drivers.adc.ite.it8xxx2.build:
24 drivers.adc.mcux.adc12.build:
27 drivers.adc.mcux.adc16.build:
30 drivers.adc.mcux.lpadc.build:
33 drivers.adc.npcx.build:
36 drivers.adc.nrf.build:
39 drivers.adc.nrf.saadc.build:
42 drivers.adc.sam0.build:
[all …]
|
| /Zephyr-Core-3.4.0/doc/build/cmake/ |
| D | index.rst | 3 Build System (CMake)
7 CMake is used to build your application together with the Zephyr kernel. A
8 CMake build is done in two stages. The first stage is called
9 **configuration**. During configuration, the CMakeLists.txt build scripts are
11 Zephyr build, and can generate build scripts that are native to the host
14 CMake supports generating scripts for several build systems, but only Ninja and
16 **build** stage by executing the generated build scripts. These build scripts
19 be executed again before building. The build scripts can detect some of these
23 Zephyr uses CMake's concept of a 'target' to organize the build. A
26 understand. All source code that goes into a Zephyr build does so by
[all …]
|
| /Zephyr-Core-3.4.0/doc/build/sysbuild/ |
| D | index.rst | 3 Sysbuild (System build)
6 Sysbuild is a higher-level build system that can be used to combine multiple
7 other build systems together. It is a higher-level layer that combines one
8 or more Zephyr build systems and optional additional build systems
9 into a hierarchical build system.
11 For example, you can use sysbuild to build a Zephyr application together
19 Like Zephyr's :ref:`build system <build_overview>`, sysbuild is written in
27 Single-image build
29 build system.
31 Multi-image build
[all …]
|
| /Zephyr-Core-3.4.0/tests/drivers/build_all/ieee802154/ |
| D | testcase.yaml | 7 ieee802154.build.external:
9 ieee802154.build.cc13xx_cc26xx:
11 ieee802154.build.kw41z:
13 ieee802154.build.mcr20a:
15 ieee802154.build.nrf5:
17 ieee802154.build.telink_b91:
19 ieee802154.build.upipe:
|
| /Zephyr-Core-3.4.0/boards/xtensa/esp32s2_franzininho/doc/ |
| D | index.rst | 61 It is build as a subproject at each application build. No further attention
68 must be build (and flash) at least once.
73 2. Manual build
86 The sysbuild makes possible to build and flash all necessary images needed to
89 To build the sample application using sysbuild use the command:
95 :goals: build
102 Build directory structure created by sysbuild is different from traditional
103 Zephyr build. Output is structured by the domain subdirectories:
107 build/
120 With ``--sysbuild`` option the bootloader will be re-build and re-flash
[all …]
|
| /Zephyr-Core-3.4.0/scripts/west_commands/ |
| D | build_helpers.py | 10 See build.py for the build command itself.
27 DEFAULT_BUILD_DIR = 'build'
28 '''Name of the default Zephyr build directory.'''
34 If the build directory is not given, the default is {}/ unless the
35 build.dir-fmt configuration variable is set. The current directory is
36 checked after that. If either is a Zephyr build directory, it is used.
57 # Guess the build folder by iterating through all sub-folders from the
85 '''Heuristic for finding a build directory.
87 The default build directory is computed by reading the build.dir-fmt
89 be None if the build.dir-fmt configuration option is set but cannot be
[all …]
|
| D | build.py | 26 west build [-h] [-b BOARD[@REV]]] [-d BUILD_DIR]
45 A "pristine" build directory is empty. The -p option controls
46 whether the build directory is made pristine before the build
49 guess if a pristine build may be necessary."""
52 log.inf('-- west build: ' + msg, colorize=True)
55 return config.get('build', option, fallback=fallback)
58 return config.getboolean('build', option, fallback=fallback)
65 class Build(Forceable): class
68 super(Build, self).__init__(
69 'build',
[all …]
|
| /Zephyr-Core-3.4.0/scripts/pylib/pytest-twister-harness/ |
| D | README.rst | 29 or build shell application by west and call pytest directly:
38 west build -p -b native_posix -- -DCONFIG_NATIVE_UART_0_ON_STDINOUT=y
39 pytest --twister-harness --device-type=native --build-dir=build -p twister_harness.plugin
42 west build -p -b qemu_x86 -- -DQEMU_PIPE=qemu-fifo
43 pytest --twister-harness --device-type=qemu --build-dir=build -p twister_harness.plugin
46 west build -p -b nrf52840dk_nrf52840
47 …pytest --twister-harness --device-type=hardware --device-serial=/dev/ttyACM0 --build-dir=build -p …
|
| /Zephyr-Core-3.4.0/tests/drivers/build_all/sensor/ |
| D | testcase.yaml | 8 sensors.build.sensorhub:
10 sensors.build.trigger.own:
12 sensors.build.trigger.global:
14 sensors.build.trigger.none:
16 sensors.build:
18 sensors.build.pm:
|
| /Zephyr-Core-3.4.0/modules/trusted-firmware-m/ |
| D | Kconfig.tfm.partitions | 16 to be passed to the TF-M build system. Look at 'config_default.cmake'
19 options are handled by the build system in the trusted-firmware-m
27 to be passed to the TF-M build system. Look at 'config_default.cmake'
30 options are handled by the build system in the trusted-firmware-m
38 to be passed to the TF-M build system. Look at 'config_default.cmake'
41 options are handled by the build system in the trusted-firmware-m
50 to be passed to the TF-M build system. Look at 'config_default.cmake'
53 options are handled by the build system in the trusted-firmware-m
61 to be passed to the TF-M build system. Look at 'config_default.cmake'
64 options are handled by the build system in the trusted-firmware-m
[all …]
|
| D | Kconfig.tfm | 29 bool "Build with TF-M as the Secure Execution Environment"
37 When enabled, this option instructs the Zephyr build process to
44 them, are generated during the normal Zephyr build process.
80 Build profile used to build tfm_s image. The available values are
85 prompt "TF-M build profile"
89 The TF-M build profile selection. Can be empty (not set),
95 bool "TF-M build profile is not set"
98 bool "TF-M build profile: small"
101 bool "TF-M build profile: medium"
104 bool "TF-M build profile: large"
[all …]
|
| /Zephyr-Core-3.4.0/tests/drivers/build_all/modem/ |
| D | testcase.yaml | 8 drivers.modem.build:
18 drivers.modem.ublox_sara.build:
26 drivers.modem.simcom_sim7080.build:
34 drivers.modem.quectel_bg9x.build:
43 drivers.modem.gsm.build:
52 drivers.modem.gsm_mux.build:
64 drivers.modem.esp_at.build:
69 drivers.modem.esp_at.async.build:
|
| /Zephyr-Core-3.4.0/samples/tfm_integration/tfm_ipc/ |
| D | README.rst | 36 #. Build Zephyr with a non-secure configuration (``-DBOARD=mps2_an521_ns``).
41 mkdir build
42 cd build
50 $ west build -p -b mps2_an521_ns zephyr/samples/tfm_integration/tfm_ipc
89 As part of the normal build process above, a binary is also produced that can
94 qemu-system-arm -M mps2-an521 -device loader,file=build/zephyr/tfm_merged.hex -serial stdio
96 You can also run the binary as part of the ``west`` build process by appending
97 the ``-t run`` flag to the end of your build command, or in the case of
102 $ west build -b mps2_an521_ns zephyr/samples/tfm_integration/tfm_ipc -t run
104 Or, post build:
[all …]
|
| /Zephyr-Core-3.4.0/doc/build/snippets/ |
| D | using.rst | 11 Snippets have names. You use snippets by giving their names to the build
14 With west build
21 west build -S foo app
27 west build -S snippet1 -S snippet2 [...] app
32 If you are running CMake directly instead of using ``west build``, use the
39 cmake --build build
|
| /Zephyr-Core-3.4.0/boards/xtensa/heltec_wifi_lora32_v2/doc/ |
| D | index.rst | 49 It is build as a subproject at each application build. No further attention
56 must be build (and flash) at least once.
61 2. Manual build
74 The sysbuild makes possible to build and flash all necessary images needed to
77 To build the sample application using sysbuild use the command:
83 :goals: build
90 Build directory structure created by sysbuild is different from traditional
91 Zephyr build. Output is structured by the domain subdirectories:
95 build/
108 With ``--sysbuild`` option the bootloader will be re-build and re-flash
[all …]
|
| /Zephyr-Core-3.4.0/tests/drivers/build_all/dac/ |
| D | testcase.yaml | 7 drivers.dac.build:
18 drivers.dac.mcux.build:
21 drivers.dac.mcux32.build:
24 drivers.dac.sam0.build:
27 drivers.dac.stm32.build:
|
| /Zephyr-Core-3.4.0/cmake/usage/ |
| D | usage.cmake | 15 message(" pristine - Remove all files in the build directory")
22 message(" all - Build a zephyr application")
23 message(" run - Build a zephyr application and run it if the board supports emulation")
28 message(" ram_report - Build and create RAM usage report")
29 message(" rom_report - Build and create ROM usage report")
33 message(" help - Display all build system targets")
35 message("Build flags:")
37 message(" ${generator} ${verbose} [targets] verbose build")
|
| /Zephyr-Core-3.4.0/samples/subsys/usb/dfu/ |
| D | README.rst | 35 The build system can do this for you by setting the :kconfig:option:`CONFIG_MCUBOOT_SIGNATURE_KEY_F…
41 west build -b nrf52840dk_nrf52840 zephyr/samples/subsys/usb/dfu -d build-dfu -- \
44 Build and flash MCUboot bootloader for Zephyr project as it is described in
45 the `Using MCUboot with Zephyr`_ documentation. Then build, sign and flash
48 Build and sign a second application image e.g. :ref:`hello_world`,
55 west build -b nrf52840dk_nrf52840 zephyr/samples/hello_world -d build-hello_world -- \
74 dfu-util --alt 1 --download build-hello_world/zephyr/zephyr.signed.bin
81 *** Booting Zephyr OS build zephyr-v3.0.0-360-gc0dd594d4d3d ***
89 *** Booting Zephyr OS build zephyr-v3.0.0-361-gb987e6daa2f9 ***
98 *** Booting Zephyr OS build zephyr-v3.0.0-360-gc0dd594d4d3d ***
[all …]
|
| /Zephyr-Core-3.4.0/doc/_extensions/zephyr/ |
| D | application.py | 19 of the shell commands needed to manage (build, flash, etc.) an application.
21 For example, to generate commands to build samples/hello_world for
27 :goals: build
36 path to the application to build.
39 path to the application to build, this is an app present in the upstream
43 if set, build instructions are given from within the \:app: folder,
47 which build system to generate. Valid options are
56 if set, the application build will target the given board.
59 if set, the application build will target the given shield.
62 if set, the application build will use the given configuration
[all …]
|
| /Zephyr-Core-3.4.0/doc/develop/application/ |
| D | index.rst | 11 - its **build directory** is :file:`<app>/build`
17 makes it easier to use ``west build`` and other commands with it. (You can
19 <important-build-vars>` is set appropriately, though.)
24 Zephyr's build system is based on `CMake`_.
26 The build system is application-centric, and requires Zephyr-based applications
27 to initiate building the Zephyr source code. The application build controls
28 the configuration and build process of both the application and Zephyr itself,
32 and build system. You also likely have installed various :ref:`modules`
53 * **CMakeLists.txt**: This file tells the build system where to find the other
55 build system. This link provides features supported by Zephyr's build system,
[all …]
|
| /Zephyr-Core-3.4.0/boards/riscv/stamp_c3/doc/ |
| D | index.rst | 63 It is build as a subproject at each application build. No further attention
70 must be build (and flash) at least once.
75 2. Manual build
88 The sysbuild makes possible to build and flash all necessary images needed to
91 To build the sample application using sysbuild use the command:
97 :goals: build
104 Build directory structure created by sysbuild is different from traditional
105 Zephyr build. Output is structured by the domain subdirectories:
109 build/
122 With ``--sysbuild`` option the bootloader will be re-build and re-flash
[all …]
|
