mcuboot/samples/zephyr/README.md

# Zephyr sample application.

In order to successfully deploy an application using MCUboot, it is
necessary to build at least one other binary: the application itself.
It is beyond the scope of this documentation to describe what an
application is able to do, however a working example is certainly
useful.

Please see the comments in the Makefile in this directory for more
details on how to build and test this application.

Note that this sample uses the "ninja" build tool, which can be
installed on most systems using the system package manager, e.g., for
a Debian-based distro:

```
$ sudo apt-get install ninja
```

or in Fedora:

```
$ sudo dnf install ninja
```
samples: Create a zephyr sample Most of the meat of this is in the Makefile, which is able to build the bootloader, and two small applications, along with instructions on how to load these into flash and test that upgrades work. JIRA: MCUB-62 Signed-off-by: David Brown <david.brown@linaro.org> 2017-07-06 03:36:37 +08:00			`# Zephyr sample application.`

doc: Fixed consistency of MCUboot Fixed the consistency of the case used in the term MCUboot. Signed-off-by: Francesco Servidio <francesco.servidio@nordicsemi.no> 2021-10-20 21:27:16 +08:00			`In order to successfully deploy an application using MCUboot, it is`
samples: Create a zephyr sample Most of the meat of this is in the Makefile, which is able to build the bootloader, and two small applications, along with instructions on how to load these into flash and test that upgrades work. JIRA: MCUB-62 Signed-off-by: David Brown <david.brown@linaro.org> 2017-07-06 03:36:37 +08:00			`necessary to build at least one other binary: the application itself.`
			`It is beyond the scope of this documentation to describe what an`
			`application is able to do, however a working example is certainly`
			`useful.`

			`Please see the comments in the Makefile in this directory for more`
			`details on how to build and test this application.`
Use Ninja instead of Makefiles for Zephyr Zephyr builds use 'cmake' which can generate either makefiles, or use the Ninja build tools. There are several significant advantages to using Ninja as the build tool: - It is significantly faster. Ninja reads a directory and stats the files in it once. Make often stats a given directory thousands of times, many for files that don't even exist. - It has better output. Ninja collects commands together with their error output. When doing multi-cpu builds, Ninja prints a status indicator, and only prints fully verbose commands when that command fails. Instead of having to try an piece together a given command with its errors, they will always be together. - Make's support of multiple CPUs is a crude hack. Make forks off multiple processes to use multiple CPUs. These processes don't communicate with each other (very much), which causes make to often continue after enountering errors. It is common for a multi-CPU make invocation to print hundreds or thousands of additional lines after an error message. Nearly all distros have a version of Ninja available in their package manager, making this change of low cost. Signed-off-by: David Brown <david.brown@linaro.org> 2019-06-26 00:13:20 +08:00
			`Note that this sample uses the "ninja" build tool, which can be`
			`installed on most systems using the system package manager, e.g., for`
			`a Debian-based distro:`

			```
			`$ sudo apt-get install ninja`
			```

			`or in Fedora:`

			```
			`$ sudo dnf install ninja`
			```