Unused after the old devicescript were removed in commit c8c35f76ab
("scripts: dts: Remove deprecated extract_dts_includes.py script"). The
old scripts relied on parsing the output of 'dts -Odts', which replaces
e.g. phandle references. The new scripts parse the DTS files directly.
Keep running the dtc compiler just to catch any warnings/errors from it.
The edit to doc/guides/build/build-config-phase.svg is to remove the box
with '*.dts_compiled' in it (and the arrows to/from it). https://draw.io
can be used to edit it.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
This commit splits the 'locore' and 'main' memory regions into
separate executable images and specifies the 'locore' as the boot
kernel, in order to prevent the QEMU direct multiboot kernel loader
from overwriting the BIOS and option ROM areas located in between
the two memory regions.
The Zephyr x86-64 kernel image consists of two discontiguous load
memory regions: 'locore' at 0x8000 and 'main' at 0x100000, but the
QEMU treats these as single contiguous memory region starting at
0x8000 and ending at (0x100000 + MAIN_IMAGE_SIZE - 1).
This results in the direct multiboot kernel loader overwriting the
BIOS and option ROM areas as part of the kernel loading process, and
causes any writable system regions to be corrupted (e.g. KVMVAPIC ROM).
By splitting the two discontiguous memory regions into separate images
and specifying only the boot image (i.e. 'locore') as the '-kernel',
it is possible to work around the QEMU direct kernel loading design
limitation.
This workaround is required to support the QEMU v4.2.0 and above.
For more details, refer to the issue zephyrproject-rtos/sdk-ng#168.
Signed-off-by: Stephanos Ioannidis <root@stephanos.io>
Fix an issue with 'ZEPHYR_TOOLCHAIN_VARIANT=host' where CMAKE_C_FLAGS
was incorrectly assumed to be set.
This fixes#21614
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
The XCC toolchain may come with Clang front-end depending on
how it's built. Currently, the only SoC/board using XCC is
the intel_s1000_crb and its XCC toolchain comes with Clang
3.9.0 which has a lot better support for C99 and C++11 than
the portion based on GCC 4.2 (which does not even support
C++11). So this change attempts to use the Clang portion
instead of GCC if the Clang executable exists.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
The undefined symbol option "-u" applies to linker so prefix
it with the linker prefix (usually "-Wl"). This fixes warnings
from LLVM/Clang about unknown arguments.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
The current QEMU console configuration directly connects the console
serial port to the backend using '-serial' option.
This is less than ideal because only single console instance can be
connected to a backend and aggregation of multiple console outputs is
not possible (e.g. multiple console serial ports and semihosting
console to single console backend).
In order to solve this problem, single multiplexed chardev console
backend is declared and all consoles are connected to it.
Signed-off-by: Stephanos Ioannidis <root@stephanos.io>
For application portability, it is required that feature activation
is made conditional in shield configuration. This way features remain
controlled on application side.
To enable this we need that list of user activated shield is made
available to Kconfig.
Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org>
Xtensa requires building a new toolchain for a specific SoC.
By default xtools built Xtensa toolchains all have prefix of
xtensa-zephyr-elf. In order to distinguish different toolchains,
they are now placed in their own directories under their SoC
name. This allows us to have multiple Xtensa toolchains
targeting multiple SoCs.
The additional level in path name is introduced in SDK v0.11
and sdk-ng master.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Allows snippets to be placed in a predictable order into the linker
script. This is useful for data that must be placed at a particular
location.
Signed-off-by: Øyvind Rønningstad <oyvind.ronningstad@nordicsemi.no>
This adds the necessary bits to build the Xtensa HAL as
a module, and removes the bits to use the HAL built with
the Zephyr SDK.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
-Wold-style-definition is not a supported option for C++ builds. To
prevent it being passed:
* the list of compiler flags to be excluded from C++ builds is moved
to be toolchain-specific;
* -Wold-style-definition is added to that list for gcc and clang;
* -Wold-style-definition is moved from zephyr_compiler_options to
zephyr_cc_option so the option checking code is executed for it.
Signed-off-by: Peter A. Bigot <pab@pabigot.com>
Zephyr currently requires Python 3.4 or later. The core Python team
declared version 3.4 hit End of Life (EOL) in March, so there's no
reason to continue to support it if that's causing a burden, which it
is.
This commit allows Zephyr's Python scripts to depend on features
present in version 3.6 or later.
This does skip support for a currently active version of Python:
- Python 3.5 is actively supported by the core Python devs until 09/2020
- Zephyr's 2.2 release, the first which could include this change, is
tentatively scheduled for 02/2020.
However, almost all supported platforms are either unaffected, or
their users can upgrade easily:
- Windows users who need to can upgrade Python with:
choco upgrade python
- macOS users who need to can upgrade Python with:
brew upgrade python3
- Red Hat Enterprise Linux users who need to upgrade can use
Software Collections (SCLs), e.g. as described here:
https://developers.redhat.com/blog/2018/08/13/install-python3-rhel/
- CentOS Linux users also have access to SCLs, as described here:
https://wiki.centos.org/AdditionalResources/Repositories/SCL
- Ubuntu's current long-term support (LTS) release (Bionic Beaver,
version 18.04) ships with Python 3.6. It and all later versions of
Ubuntu won't be affected by this change.
- Debian's current stable release (Buster, version 10) ships Python 3.7
and likewise won't be affected.
The impact of this change is therefore biggest for older versions of
Linux. In particular, these are impacted:
- Older Ubuntu LTS releases.
- Ubuntu 16.04 ships Python 3.5; it is still supported by Canonical.
- Ubuntu 14.04 ships Python 3.4, which is EOL. This Ubuntu version
is also no longer getting standard support from Canonical. Paying
customers are receiving security updates only.
https://wiki.ubuntu.com/Releases
- Older Debian versions.
- Debian 9 (stretch) ships Python 3.5 and is still a supported
Debian version.
- Debian 8 (jessie) ships Python 3.4, which is EOL. This Debian
version is no longer receiving mainline maintenance by the Debian
project. LTS updates are provided by interested community
volunteers only.
https://wiki.debian.org/LTS
Affected Linux users will no longer have a system Python 3 which works
"out of the box" with Zephyr after this change. Some ideas for these
users are:
- Use Zephyr v2.1 or v1.14 LTS, which are maintained and still
support Python 3.4
- Compile Python 3.6 or later from source and use it within a venv:
https://docs.python.org/3/library/venv.html
- Use something like https://github.com/pyenv/pyenv
Python 3.6 has compelling new features which make writing Zephyr's
scripts easier, and which it would be good to be able to rely upon.
This motivates moving from Python 3.4 to 3.6 instead of 3.5.
My personal killer 3.6 features motivating skipping 3.5 (YMMV):
- Windows console and file system encodings are UTF-8 (PEPs 528 and
529): Zephyr's scripts, and many utilities related to git, broadly
assume strings are UTF-8, so this is very helpful
- os.PathLike and the file system path protocol (PEP 519) allow
intermixing "smart" paths in pathlib with existing os.path based
code
- f-strings (PEP 0498) are a wonderful and efficient string
interpolation mechanism
- CPython dictionaries are insertion ordered as an implementation
detail starting with 3.6, which in practice helps with
reproducibility (and *all* Python implementations have insertion
ordered dicts starting with 3.7)
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
To detect where the cache directory has been located we have been
checking if $HOME is writable, and if it is assuming that $HOME/.cache
must be writable as well.
This is broken in environments where $HOME is owned by users and
$HOME/.cache is owned by admin. To fix this we check $HOME/.cache for
write-ability instead.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
The EXTRA_CPPFLAGS is applied via zephyr_compile_definitions()
instead of zephyr_compile_options(), which makes all specified
options as macros. So fix it.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
We do compiler flag compatibility tests to be able to support many
different toolchains and flags in a scalable way. But the test is not
perfect and in these situations we we will need to hardcode whether a
flag is compatible or not.
To support this we have zephyr_compiler_check first check if the flag
is covered by a hardcoded test before testing it.
Currently the only hardcoded compatibilty is that -Werror=implicit-int
is not supported for CXX.
This fixes#21229
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
Change the DTS preprocessor working directory from the binary
directory to the application directory.
This is done so that the user can specify
-DDTC_OVERLAY_FILE=overlay.dts with a relative path from the
application directory as is possible for CONF_FILE, and as is
reasonably expected to be possible by users.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
We now use EDTS and gen_defines.py to generate DTS defines. We
deprecated the old script and defines several releases ago, so lets now
remove them.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Basic tool to help checking Kconfig options against a list of
hardening preferences.
This tool is available as a kconfig target, so to run it:
make/ninja hardenconfig
[Flavio Ceolin: Simplify logic and fix python lint issues]
Signed-off-by: Lauren Murphy <lauren.murphy@intel.com>
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
The -Og (optimise for debugging) flag is only available for GCC 4.8.0
and above, and specifying it for a GCC version lower than 4.8.0 will
result in a compilation error.
This commit adds a check for compiler -Og optimisation flag support and
a fallback to -O0 (disable optimisation) when -Og flag is unsupported.
Signed-off-by: Stephanos Ioannidis <root@stephanos.io>
When generating the dependency file for DTS (${BOARD}.dts.pre.d),
some toolchains would use the source file for the file name stem.
So, the resulting dependency file is empty_file.d instead of one
with the board name. Fix this by passing -MF to explicitly tell
the compiler the name of the dependency file.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Renode 1.8 introduced a behaviour change in which it automatically
launches the telnet monitor on the TCP port 1234 by default.
In order to prevent sanitycheck failures from multiple renode instances
attempting to listen on the TCP port 1234 simultaneously, this commit
disables renode telnet monitor by specifying '--port -2' (a negative
number lower than -1 is required to disable telnet monitor because of
the way renode command line parser is implemented).
Signed-off-by: Stephanos Ioannidis <root@stephanos.io>
We need this information in the cache now that we're not allowed to
parse generated_dts_board.conf from Python code after build time.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
This adds support for Zephyr SDK 0.11.* is based on the 0.10 support
with the following changes:
Handle how xtensa toolchains for given targets are organized in SDK
0.11.x. They have their own directories per specific xtensa SoC.
The x86_64 toolchain in the SDK has been updated to build for 32-bit
targets (as it has 32-bit soft float libraries). Use this toolchain for
all x86 builds.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
The toolchain_ld_cpp macro currently uses zephyr_ld_options function
to link libstdc++, instead of zephyr_link_libraries which is actually
intended for this purpose.
This commit replaces the usage of zephyr_ld_options with
zephyr_link_libraries as the former may erroneously filter out
-lstdc++ and the latter ensures that this linker flag is
unconditionally forwarded to the linker.
For more details, refer to the issue #20406.
Signed-off-by: Stephanos Ioannidis <root@stephanos.io>
This commit refactors kernel and arch headers to establish a boundary
between private and public interface headers.
The refactoring strategy used in this commit is detailed in the issue
This commit introduces the following major changes:
1. Establish a clear boundary between private and public headers by
removing "kernel/include" and "arch/*/include" from the global
include paths. Ideally, only kernel/ and arch/*/ source files should
reference the headers in these directories. If these headers must be
used by a component, these include paths shall be manually added to
the CMakeLists.txt file of the component. This is intended to
discourage applications from including private kernel and arch
headers either knowingly and unknowingly.
- kernel/include/ (PRIVATE)
This directory contains the private headers that provide private
kernel definitions which should not be visible outside the kernel
and arch source code. All public kernel definitions must be added
to an appropriate header located under include/.
- arch/*/include/ (PRIVATE)
This directory contains the private headers that provide private
architecture-specific definitions which should not be visible
outside the arch and kernel source code. All public architecture-
specific definitions must be added to an appropriate header located
under include/arch/*/.
- include/ AND include/sys/ (PUBLIC)
This directory contains the public headers that provide public
kernel definitions which can be referenced by both kernel and
application code.
- include/arch/*/ (PUBLIC)
This directory contains the public headers that provide public
architecture-specific definitions which can be referenced by both
kernel and application code.
2. Split arch_interface.h into "kernel-to-arch interface" and "public
arch interface" divisions.
- kernel/include/kernel_arch_interface.h
* provides private "kernel-to-arch interface" definition.
* includes arch/*/include/kernel_arch_func.h to ensure that the
interface function implementations are always available.
* includes sys/arch_interface.h so that public arch interface
definitions are automatically included when including this file.
- arch/*/include/kernel_arch_func.h
* provides architecture-specific "kernel-to-arch interface"
implementation.
* only the functions that will be used in kernel and arch source
files are defined here.
- include/sys/arch_interface.h
* provides "public arch interface" definition.
* includes include/arch/arch_inlines.h to ensure that the
architecture-specific public inline interface function
implementations are always available.
- include/arch/arch_inlines.h
* includes architecture-specific arch_inlines.h in
include/arch/*/arch_inline.h.
- include/arch/*/arch_inline.h
* provides architecture-specific "public arch interface" inline
function implementation.
* supersedes include/sys/arch_inline.h.
3. Refactor kernel and the existing architecture implementations.
- Remove circular dependency of kernel and arch headers. The
following general rules should be observed:
* Never include any private headers from public headers
* Never include kernel_internal.h in kernel_arch_data.h
* Always include kernel_arch_data.h from kernel_arch_func.h
* Never include kernel.h from kernel_struct.h either directly or
indirectly. Only add the kernel structures that must be referenced
from public arch headers in this file.
- Relocate syscall_handler.h to include/ so it can be used in the
public code. This is necessary because many user-mode public codes
reference the functions defined in this header.
- Relocate kernel_arch_thread.h to include/arch/*/thread.h. This is
necessary to provide architecture-specific thread definition for
'struct k_thread' in kernel.h.
- Remove any private header dependencies from public headers using
the following methods:
* If dependency is not required, simply omit
* If dependency is required,
- Relocate a portion of the required dependencies from the
private header to an appropriate public header OR
- Relocate the required private header to make it public.
This commit supersedes #20047, addresses #19666, and fixes#3056.
Signed-off-by: Stephanos Ioannidis <root@stephanos.io>
Commit 28a5657f1f and f67dcdbdf8 stopped ZEPHYR_BASE and
CMAKE_SOURCE_DIR from leaking into __FILE__ and other macros.
WEST_TOPDIR was still missing. Add it now that the new 'west topdir'
command has been implemented in
https://github.com/zephyrproject-rtos/west/pull/311
If the west version is too old then do nothing; same as before.
Any ASSERT in a zephyr module outside ZEPHYR_BASE is enough to test
this. One example:
$ZEPHYR_BASE/sanitycheck -T $ZEPHYR_BASE/tests/posix/fs/ -p qemu_x86 -v
readelf --string-dump=.rodata.disk_status.str1.1 {} \
$(find sanity-out -name zfs_diskio.c.obj | head -n 1)
String dump of section '.rodata.disk_status.str1.1':
[ 0] WEST_TOPDIR/modules/fs/fatfs/zfs_diskio.c
[ 2a] pdrv < ((long) (((int) sizeof(char[1 - 2 * !(!__built....
[ de] ASSERTION FAIL [%s] @ %s:%d^J
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
If duplicates gets passed to scripts/dts/gen_defines.py, the bindings in
those directories will be loaded twice and actually get in conflict with
itself.
Signed-off-by: Tobias Svehagen <tobias.svehagen@gmail.com>
Speed up CMake by 100ms by importing west instead of invoking it as an
executable.
There is significant overhead in invoking west as a script via
pip. The exact reason why is not clear.
Also, simplify the version output parsing as we get the version in a
more machine-readable form now.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
This commit allows a more dynamic approach for specifying that a zephyr
library must be placed in a dedicated app memomory partition.
This is still done by defining the partition in code using
K_APPMEM_PARTITION_DEFINE, but now the zephyr library can be added to
the generation of partition table using zephyr_library_app_memory
instead of modifying the overall zephyr/CMakeLists.txt file.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Of the 1.7s or so that CMake spends in Configure-time there is 0.1s
spent to determine whether west can flash or not. This is significant
compared to the usefulness of flash-check.
AFAICT when installing west there is no longer a two-step procedure
where first a bootstrapper that can't flash is installed, and then a
proper west is installed, so the risk of having installed the
bootstrapper is no longer something we should spend 100ms testing for.
This patch removes the check, thereby speeding up CMake by 100ms.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
Fixed a bug where python 3.8 was not detected on Windows.
Python 3.8 was released two weeks ago and any Windows user that
installs it will detect the wrong version.
Also add detection for 3.9 for future-proofing.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
Move _LINKER and _ASMLANGUAGE to target.cmake because of how we pick the
linker script that might be used. This way regardless of how or where a
linker.ld gets included we will always set _LINKER & _ASMLANGUAGE (so
any header that needs check based on those defines they can,
specifically generated_dts_board.h)
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Since x86_64-zephyr-elf is a multi-lib toolchain, m32/m64
need to be specified for the compiler to return the correct
library path when queried (e.g. --print-libgcc-file-name).
This affects the compile check done by CMake. Without these
flags, the compiler returns incorrect toolchain path (e.g.
requiring 64-bit libraries but returning 32-bit library path).
This also affects compiler flag checks for "-lstdc++". Incorrect
library path results in error when checking for "-lstdc++", and
this flag will not be used for the build. This results in
undefined references when compiling C++ code.
This creates target_x86.cmake to add the necessary flags for
CMake to use. The target_x86_64.cmake is also created to
mirror the same change.
Also removing the -m32 flags for host-gcc since we are not
building x86 targets with the host-gcc compiler.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
The target.cmake for xtools needs to be updated for changes in
sdk-ng repo. This is simply a copy from the target.cmake for
0.10 SDK.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
There are two set of code supporting x86_64: x86_64 using x32 ABI,
and x86 long mode, and this consolidates both into one x86_64
architecture and SoC supporting truly 64-bit mode.
() Removes the x86_64:x32 architecture and SoC, and replaces
them with the existing x86 long mode arch and SoC.
() Replace qemu_x86_64 with qemu_x86_long as qemu_x86_64.
() Updates samples and tests to remove reference to
qemu_x86_long.
() Renames CONFIG_X86_LONGMODE to CONFIG_X86_64.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Remove the common.dts file which has been used for a year.
common.dts at one point allowed us to conditionally add an MCUBoot
overlay based on Kconfig.
but since DT lost access to Kconfig options it has been unused.
The overridable variable DTS_COMMON_OVERLAYS, which by default points
to common.dts, is also unused in-tree, and any out-of-tree usage can
be ported over to use DTC_OVERLAY_FILE instead, so we remove the
variable as well.
This simplifies the configuration system.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
When DT sources change CMake must be run again. CMake is currently
detecting changes to DT source files that we manually specify, but not
sources that are included through use of the preprocessor.
This patch makes the preprocessor output the includes used and adds
them to the 'CMAKE_CONFIGURE_DEPENDS' property.
This fixes#16791.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
Added a function that can parse the dependency information given when
invoking gcc with the argument '-M'. This could be used to manually
add dependencies detected when preprocessing a file.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
This commit introduces the cmake extension zephyr_library_amend.
This function allows for adding files in an out-of-tree Zephyr module
to a zephyr library created in zephyr repo CMake files.
As example:
drivers/entropy/CMakeLists.txt creates an zephyr library as:
zephyr_library()
only available to zephyr itself.
The amend function allows to amend to such a lib, by creating a
CMakeLists.txt file following identical folder structure in a Zephyr
Module:
<zephyr_module_oot>/drivers/entropy/CMakeLists.txt
zephyr_library_amend()
zephyr_library_sources() # Sources are amended to the original library
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Instead, use the QEMU_KERNEL_FILE facility to perform the
change in a new file zephyr-qemu.elf. This is what will
be sent to the emulator.
Fixes an issue where opening zephyr.elf in GDB would treat
it as a 32-bit binary instead of what it actually is,
forcing the user to override the arch setting.
Fixes: #19734
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
This was a very early test and got bitrotten inside a esp32-only
whitelist. Make it run generically.
SMP must be forced off by the test (it's commonly a platform default).
Add a build-time failure when the configuration is single-CPU, for
clarity.
Filter the test likewise so it runs on all supported systems.
Also, the key argument to the CPU startup function is vestigial and
the test was being too strict by requiring it to be non-zero.
Finally, the qemu command line needs to predicate the "-smp" argument
on CONFIG_MP_NUM_CPUS and not just CONFIG_SMP so we have an extra CPU
to test against.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Putting overlay files in the test/sample root clutters the file
system. Allow them to be in the boards subdirectory alongside
board.conf files.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
Fix a bug where DTS_BINDINGS_DIRS could only have one entry. When
there were more than one entry the command for invoking menuconfig
became corrupted.
This changes the separator of DTS_BINDINGS_DIR from a space to ? so
that the shell does not interpret the space as an argument separator.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
The CMake documentation for 'project' states "Call the project()
command near the top of the top-level CMakeLists.txt". Meaning, it
should be run as early as possible.
An obscure internal error was observed when 'project' was located in
zephyr/CMakeLists.txt and was observed to be fixed after moving
'project' earlier, hence this patch that moves it earlier.
Invoking project depends on knowing information about the toolchain so
it is placed after target_toolchain.cmake.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
Should be --bindings-dirs, not --bindings-dir, but the 'argparse' module
supports shortening flags, so it worked anyway.
Broke my grepping though.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
This PR adds the possibility to specify ZEPHYR_EXTRA_MODULES from an
environmental variable. To add a custom module mymodule in
path/mymodule the variable ZEPHYR_EXTRA_MODULES can be set in
`.zephyrrc` as `export ZEPHYR_EXTRA_MODULES=path/mymodule`.
Signed-off-by: Laczen JMS <laczenjms@gmail.com>
We are observing warnings when test-compiling toolchain flags that
look like:
cannot find entry symbol _start; defaulting to 00000000000010d4
To fix this warning we explicitly set an entry point to an arbitrary
address. The files are only compiled, not run, so the entry point does
not need to be correct.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
Mimic what we have in cmake/compiler/gcc/target.cmake for clang
targetting ARM. Match gcc behavior by setting -fshort-enums
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Encountered situation when sdk_version string was empty
(as the result of corrupted installation).
The version should had 0.0.0 format.
Patch add check for this and descriptive failure message.
Objective is to help the user to recognize the installation failure.
Signed-off-by: Andrzej Puzdrowski <andrzej.puzdrowski@nordicsemi.no>
Some confluence of recent changes resulted in builds with
application-specific bindings being unable to find bindings present in
the system directory. Add quotes and splits as necessary to propagate
multiple directories through the system.
Signed-off-by: Peter A. Bigot <pab@pabigot.com>
Add qemu_x86_long board (with CONFIG_X86_LONGMODE=y) for testing.
This requires adding support to soc/ia32 for long mode (trivial),
and adding a quick 64- to 32-bit ELF conversion before invoking
QEMU, which apparently doesn't like 64-bit kernel files.
Signed-off-by: Charles E. Youse <charles.youse@intel.com>
* Add support to search for a board specific shield in
<SHIELD DIR>/boards/<SHIELD>/<BOARD>.{overlay,conf}. So we can
support something like:
x_nucleo_iks01a3/boards/x_nucleo_iks01a3_shub/stm32mp157c_dk2.overlay
x_nucleo_iks01a3/boards/x_nucleo_iks01a3_shub/stm32mp157c_dk2.conf
Fixes#19078
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
* Fix dir name when shield name doesn't match the dir name. So for
shield 'x_nucleo_iks01a3_shub' we will look in now for
x_nucleo_iks01a3/boards/<BOARD>.{overlay,conf} instead of
x_nucleo_iks01a3_shub/boards/<BOARD>.{overlay,conf}
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Move handling for shield boards/board.overlay, shield.conf and
boards/board.conf inside the SHIELD_LIST check.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
It turns out that 'check_compiler_flag' has not been working for flags
that start with -Wno-. This has caused old compilers to accidentally
use flags that they do not support.
To fix this we check for compatibility with the appropriate -W flag
instead and infer the -Wno- compatibility from this check.
The root cause of this problem is explained well here:
https://github.com/zephyrproject-rtos/zephyr/pull/18922#discussion_r321537098
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
Error-out when 'project' is invoked before boilerplate.cmake is
included. This is not supported and causes obscure errors.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
Drop the old deprecation warning about
ZEPHYR_TOOLCHAIN_CAPABILITY_CACHE. Sufficient time has passed to allow
users to migrate.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
We need SDK version 0.10.3 to fix a build regress on RISC-V when
linking. So bump the version to pickup that fix.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Now when SMP support for ARC is available we may introduce a simulation
platform which might be used for testing & development for SMP setups.
One important note is stand-alone nSIM (as well as its "Free" flavour)
doesn't support SMP simulation so we have to switch to use of nSIM via
proprietary MetaWare debugger [1] and so:
1. We introduce new emulation target "mdb"
2. It's only possible to run that platform for those who
have MetaWare tools installed and valid license.
Though QEMU port for ARC is in work at the moment and once we
open that port and it has SMP support we'll switch to it and everybody
will be able to try ARC HS with SMP.
[1] https://www.synopsys.com/dw/ipdir.php?ds=sw_metaware
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
The xlnx-zcu102 qemu machine is the only one that supports a Cortex-R
processor. However, its main CPUs are Cortex A53s which requires the
aarch64 qemu binary to run.
Signed-off-by: Bradley Bolen <bbolen@lexmark.com>
For now we enforce the medany code model for 64-bit builds as we get
reloc issues otherwise. The instruction set and ABI are also set to
soft-float usage.
The ilp32 ABI is explicitly specified on 32-bit build to make sure
it is not using a wrong default if the same toolchain is used for both
32- and 64-bit builds. The archittecture options are the same as the
SDK's riscv32 toolchain default in that case.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
We want to use the riscv64 toolchain across the board for RISC-V. That
requires a min of the 0.10.2 SDK, so bump the version before we make
that change.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
The main change is the elimination of the bootstrapper, a design flaw
/ misfeature.
Update the documentation to be compatible with the 0.6.x releases as
well. This has to be done atomically, as there were incompatible
changes. Make use of the versionchanged and versionadded directives
to begin keeping track of how these APIs are evolving.
(Note that west 0.6.0 will remain compatible with the extension
commands in Zephyr v1.14 LTS as long as that is still alive. This
change is targeted towards Zephyr 2.0 users.)
This requires a bump in the shippable container and allows us to
simplify the west_commands test procedure.
Signed-off-by: Marti Bolivar <marti.bolivar@nordicsemi.no>
The SDK version is of the form X.Y.Z. Change the cmake scripts to be
based on X.Y of the version. This allows us to easily support newer
toolchains without having to explicitly add cmake files for the version
as well as removes duplication between those files.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
With the upcoming riscv64 support, it is best to use "riscv" as the
subdirectory name and common symbols as riscv32 and riscv64 support
code is almost identical. Then later decide whether 32-bit or 64-bit
compilation is wanted.
Redirects for the web documentation are also included.
Then zephyrbot complained about this:
"
New files added that are not covered in CODEOWNERS:
dts/riscv/microsemi-miv.dtsi
dts/riscv/riscv32-fe310.dtsi
Please add one or more entries in the CODEOWNERS file to cover
those files
"
So I assigned them to those who created them. Feel free to readjust
as necessary.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
Depending on how compiler is built, it prints a different include
directory with `--print-file-name=include`. What we want, instead, is
directories with `stddef.h` and `include-fixed/limits.h`.
This commit explicitly specify the header files we want to use, then
take the directory from the returned path.
Signed-off-by: Yasushi SHOJI <y-shoji@ispace-inc.com>
This abstracts the interface for generation of the strip command
line, by naming the desired actions instead of directly setting the
command parameters, which then opens up for other binary tool sets
which may require different arguments to achieve the desired result.
The intent here is to abstract Zephyr's dependence on toolchains,
thus allowing for easier porting to other, perhaps commercial,
toolchains and/or usecases.
No functional change expected.
Signed-off-by: Danny Oerndrup <daor@demant.com>
This abstracts the interface for generation of the readelf command
line, by naming the desired actions instead of directly setting the
command parameters, which then opens up for other binary tool sets
which may require different arguments to achieve the desired result.
The intent here is to abstract Zephyr's dependence on toolchains,
thus allowing for easier porting to other, perhaps commercial,
toolchains and/or usecases.
No functional change expected.
Signed-off-by: Danny Oerndrup <daor@demant.com>
This abstracts the interface for generation of the objdump command
line, by naming the desired actions instead of directly setting the
command parameters, which then opens up for other binary tool sets
which may require different arguments to achieve the desired result.
The intent here is to abstract Zephyr's dependence on toolchains,
thus allowing for easier porting to other, perhaps commercial,
toolchains and/or usecases.
No functional change expected.
Signed-off-by: Danny Oerndrup <daor@demant.com>
This abstracts the interface for generation of the objcopy command
line, by naming the desired actions instead of directly setting the
command parameters, which then opens up for other binary tool sets
which may require different arguments to achieve the desired result.
The intent here is to abstract Zephyr's dependence on toolchains,
thus allowing for easier porting to other, perhaps commercial,
toolchains and/or usecases.
No functional change expected.
Signed-off-by: Danny Oerndrup <daor@demant.com>
ARC nSIM simulates pretty much any modern ARC core,
moreover it emulates a lot of different core features so
it is possible to play with them even wo real hardware.
Thus we add yet another ARC core family to be used on simulated
nSIM board.
For now it's just a basic configuration with ARC UART for
smoke-testing of Zephyr on ARC HS CPUs.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
The ARC HS is a family of high performance CPUs from Synopsys
capable of running wide range of applications from heavy DPS
calculation to full-scale OS.
Still as with other ARC cores ARC HS might be tailored to
a particular application.
As opposed to EM cores ARC HS cores always have support of unaligned
data access and by default GCC generates such a data layout with
so we have to always enable unaligned data access in runtime otherwise
on attempt to access such data we'd see "Unaligned memory exception".
Note we had to explicitly mention CONFIG_CPU_ARCEM=y in
all current defconfigs as CPU_ARC{EM|HS} are now parts of a
choice so we cannot simply select ether option in board's Kconfig.
And while at it change "-mmpy-option" of ARC EM to "wlh1"
which is the same as previously used "6" but matches
Programmer's Reference Manual (PRM) and is more human-friendly.
Signed-off-by: Wayne Ren <wei.ren@synopsys.com>
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
The method for getting a memory usage report printed during build, is
based on a GNU linker (ld) option flag, and thus is not necessarily
supported by other toolchain binary tools.
The introduced cmake macro allows for a given toolchain to specify how
the memory usage report is to be generated, and whether the command for
generation, if any, is to be added to the post_build_commands and the
post_build_byproducts lists of the top level CMakeLists.txt
The intent here is to abstract Zephyr's dependence on toolchains,
thus allowing for easier porting to other, perhaps commercial,
toolchains and/or usecases.
No functional change expected.
Signed-off-by: Danny Oerndrup <daor@demant.com>
This forms the foundation for the abstraction of the binary tools,
where the following steps are taken:
- Move binary tool resolving, such as objcopy, objdump, readelf and
so forth, out of compiler definitions and place in a dedicated binary
tools folder with the binary tools supplier as subfolder, similar to
the compiler and linker directories.
- Create binary tool sets, gnu, host-gnu and llvm.
- Each toolchain selects the required set of binary tools by setting
BINTOOLS via its generic.cmake as it also does for compiler and linker.
The intent here is to abstract Zephyr's dependence on toolchains,
thus allowing for easier porting to other, perhaps commercial,
toolchains and/or usecases.
No functional change expected.
Signed-off-by: Danny Oerndrup <daor@demant.com>
This toolchain is no londer supported or needed. It was used to build
configurations that are now being removed.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
This board and SoC was discontinued some time ago and is currently not
maintained in the zephyr tree.
Remove all associated configurations and variants from the tree.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Add a new DTS/binding parser to scripts/dts/ for generating
generated_dts_board.conf and generated_dts_board_unfixed.h.
The old code is kept to generate some deprecated defines, using the
--deprecated-only flag. It will be removed later.
The new parser is implemented in three files in scripts/dts/:
dtlib.py:
A low-level .dts parsing library. This is similar to devicetree.py in
the old code, but is a general robust DTS parser that doesn't rely on
preprocessing.
edtlib.py (e for extended):
A library built on top of dtlib.py that brings together data from DTS
files and bindings and creates Device instances with all the data for
a device.
gen_defines.py:
A script that uses edtlib.py to generate generated_dts_board.conf and
generated_dts_board_unfixed.h. Corresponds to extract_dts_includes.py
and the files in extract/ in the old code.
testdtlib.py:
Test suite for dtlib.py. Can be run directly as a script.
testedtlib.py (uses test.dts and test-bindings/):
Test suite for edtlib.py. Can be run directly as a script.
The test suites will be run automatically in CI.
The new code turns some things that were warnings (or not checked) in
the old code into errors, like missing properties that are specified
with 'category: required' in the binding for the node.
The code includes lots of documentation and tries to give helpful error
messages instead of Python errors.
Co-authored-by: Kumar Gala <kumar.gala@linaro.org>
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
The macro, toolchain_cc_produce_debug_info, adds the compiler specific
flag for enabling the production of debugging information in the
toolchain native format.
The intent here is to abstract Zephyr's dependence on toolchains,
thus allowing for easier porting to other, perhaps commercial,
toolchains and/or usecases.
No functional change expected.
Signed-off-by: Danny Oerndrup <daor@demant.com>
In order for CMake and Python to interact correctly when the former
invokes the latter, ensure that Python uses UTF-8 encodings when
interacting with stdout and stdin on Windows.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
We don't generate any CONFIG_ prefixed symbols from dts files so we
don't need to try and import them in anymore.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
We need to pass -m64 instead of -m32 when CONFIG_64BIT is set.
This is pretty x86 centric. Many platforms don't have the ability
to select between 32-bits or 64-bits builds and either of those should
be dropped in that case with restriction on the available configuration
done elsewhere. But for the time being this allows for testing both.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
This reverts commit b4078c557d / zephyrproject-rtos/zephyr#17495
This revert is needed for two reasons:
1. As reported by Lawrence King at
https://lists.zephyrproject.org/g/users/message/1566
this breaks incremental builds with ninja:
cd sample/hello_world
west build -b qemu_x86
touch src/main.c
west build -b qemu_x86
hello_world/build/../src/main.c:11: multiple definition of main';
app/libapp.a(main.c.obj):samples/hello_world/build/../src/main.c:11:
first defined here
collect2: error: ld returned 1 exit status
ar tf build/app/libapp.a
main.c.obj
main.c.obj
This does NOT break incremental builds with GNU Make, not sure why not.
2. Less urgently, I finally got someone from the CMake team to help me
and point me at an alternative solution that doesn't rely on CMake
internals: https://gitlab.kitware.com/cmake/cmake/issues/19474
I was about to try it when Lawrence reported the regression above.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Quoting GNU ar man/info page:
'D'
Operate in _deterministic_ mode. When adding files and the archive
index use zero for UIDs, GIDs, timestamps, and use consistent file
modes for all files. When this option is used, if 'ar' is used
with identical options and identical input files, multiple runs
will create identical output files regardless of the input files'
owners, groups, file modes, or modification times.
If 'binutils' was configured with
'--enable-deterministic-archives', then this mode is on by default.
It can be disabled with the 'U' modifier, below.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Not all DTS changes are board specific and we should support overlays
that can be used with multiple boards. For example with a sensor, for
example:
Use this overlay for a sensor:
&arduino_i2c {
bme280@76 {
compatible = "bosch,bme280";
reg = <0x76>;
label = "BME280";
};
};
This will work with any board that has &arduino_i2c defined, but should
also work if you specify the instance directly (&i2c0 or &i2c1).
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
The Particle mesh feather boards provide device-tree overlays that
allow individual applications to select the SPI peripheral to be
used for the pins associated with a specific labelled SPI device.
This is necessary because different peripheral instances have slightly
different properties.
Add BOARD_DIR to DTS_ROOTS so these shared files can be located when
included from application-specific overlays.
Signed-off-by: Peter A. Bigot <pab@pabigot.com>
sanitycheck takes any "extra_config" list found in the testcase.yaml
file and generates an "overlay" file from it. This file is placed in
the per-test build directory and passed to cmake/kconfig.cmake through a
-DOVERLAY_CONF= option set in the (also) generated sanity-out/Makefile.
This commit moves this generated config overlay to a subdirectory one
level down from the build directory, otherwise kconfig.cmake picks it
up *twice*: once from the -DOVERLAY_CONF= option already mentioned above
and a second time because kconfig.cmake scans the build directory and
blindly picks up ALL files ending with .conf[*]. The second pickup is
problematic because kconfig.cmake currently gives it the top precedence,
even higher than anything the user espressed with --extra-args=CONFIG_*
Here's a quick and simple demonstration of the issue fixed by this
commit:
cd $ZEPHYR_BASE/samples/net/sockets/net_mgmt/
sanitycheck -T. -p qemu_x86 -b -v # --extra-args=CONFIG_USERSPACE=y|n
grep CONFIG_USERSPACE $(find sanity-out/ -name .config)
.net_mgmt.kernelmode/zephyr/.config: # CONFIG_USERSPACE is not set
.net_mgmt.usermode/zephyr/.config: CONFIG_USERSPACE=y
grep 'Merged configuration' $(find sanity-out/ -name build.log)
Without this commit, attemps to override anything with
--extra-args=CONFIG_ are silently dropped on the floor.
For more background this issue was found while using the recipe in
commit message 4afcc0f8af
[*] picking up all .conf files is debatable but a much bigger debate
with backward compatibility implications. This small fix makes
absolutely zero difference to anyone or anything not using sanitycheck.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Check for ZEPHYR_SDK_INSTALL_DIR being invalid instead of
checking for SDK_VERSION being not defined. This change
relates to commit bb09c458c1 ("cmake: Prevent infinite
recursion").
Signed-off-by: Vinayak Kariappa Chettimada <vich@nordicsemi.no>
This allows for inclusion of out-of-tree toolchain cmake files
relating to compiler and linker for both target and generic
toolchains.
The base path used was ZEPHYR_BASE, instead of TOOLCHAIN_ROOT, thus
making it impossible to load the out-of-tree toolchain specific
cmake files.
In addition, the generic toolchain may now specify a generic cmake
file for the linker, similar to the target toolchain linker.
The intent here is to abstract Zephyr's dependence on toolchains,
thus allowing for easier porting to other, perhaps commercial,
toolchains and/or usecases.
No functional change expected.
Signed-off-by: Danny Oerndrup <daor@demant.com>
Ensure that xcc is at parity with gcc and clang by inferring missing
definitions based on those that it already provides.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
Commit f57ba2d30c ("cmake: toolchain_cc_imacros: don't use space
separated arguments") moved toolchain_cc_imacros() to using the long
argument format in order to avoid spaces that CMake uses to delimitate
and deduplicate arguments.
It seems that xcc doesn't support the --imacros=foo form. However
it does support the short "combined" -imacrosfoo form (without space).
So let's use that instead and document the caviat.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
target_sources() documentation states:
Relative source file paths are interpreted as being relative to the
current source directory (i.e. CMAKE_CURRENT_SOURCE_DIR).
Remove spurious code duplicating cmake's behaviour. It proved to be a
time-consuming red herring while debugging some path-related issue and
"less is more".
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
This adds the necessary bits to utilize the x86_64 toolchain
built by sdk-ng for x86_64 when toolchain variant is either
zephyr or xtools. This allows decoupling the builds from
the host toolchain.
Newlib is also available with this toolchain so remove
the Kconfig restriction on CONFIG_NEWLIB_LIBC.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
This new SDK:
() Fixes an issue with i586 toolchain where no coverage data
would be produced;
() Adds a new x86_64 toolchain for building x86_64
targets, decoupling x86_64 builds from host toolchain;
() Includes MIPS toolchain;
() Reverts bossa to older version to fix flashing issues;
() Turns on multilib support for RISC-V; and,
() Updates OpenOCD for TI and some ARC fixes.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Because CMake explicitly deduplicates arguments, it is not possible
to use toolchain_cc_imacros() multiple times as the later "-imacros"
are stripped away, leaving the associated file arguments dangling.
The documented workaround in the CMake manual involves some "SHELL:..."
construct but that doesn't get through zephyr_compile_options()
undammaged.
Let's simply remove this issue altogether by replacing "-imacros x.h"
with the joined form "--imacros=x.h" instead. Both gcc and clang
support this syntax.
FYI, this joined form is also available for other arguments such as:
-include x.h --> --include=x.h
-A foo --> --assert=foo
-D foo --> --define-macro=foo
-U foo --> --undefine-macro=foo
Etc.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
Found a few annoying typos and figured I better run script and
fix anything it can find, here are the results...
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
The start of generated/cfb_font_dice.h looked like this:
/*
* This file was automatically generated using the following command:
* /home/john/zephyrproject/zephyr/scripts/gen_cfb_font_header.py
* --input fonts/dice.png --output
* /home/john/tmp/build/zephyr/include/generated//cfb_font_dice.h
* --width 32 --height 32 --first 49 --last 54
*/
For build reproduction and "privacy" reasons, change it to this:
/*
* This file was automatically generated using the following command:
* ${ZEPHYR_BASE}/scripts/gen_cfb_font_header.py
* --input fonts/dice.png --output
* zephyr/include/generated//cfb_font_dice.h
* --width 32 --height 32 --first 49 --last 54
*/
Test with:
sanitycheck -p reel_board \
-T $ZEPHYR_BASE/samples/display/cfb_custom_font/
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
The macro obtains the toolchain specific flag and value for
setting of the requested c standard.
The intent here is to abstract Zephyr's dependence on toolchains,
thus allowing for easier porting to other, perhaps commercial,
toolchains and/or usecases.
No functional change expected.
Signed-off-by: Danny Oerndrup <daor@demant.com>
Final step of linker abstraction:
* Abstract zephyr_lnk by including it in toolchain_ld_link_elf.
* Abstract relevant uses of target_link_libraries.
* Introduce toolchain_ld_force_undefined_symbols.
No functional change expected.
This is motivated by the wish to abstract Zephyr's usage of toolchains,
permitting non-intrusive porting to other (commercial) toolchains.
Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
The macro is intended to abstract the -fno-common compiler option
which controls the placement of uninitialized global variables. The
macro leaves it up to the toolchain to define the option.
The intent here is to abstract Zephyr's dependence on toolchains,
thus allowing for easier porting to other, perhaps commercial,
toolchains and/or usecases.
No functional change expected.
Signed-off-by: Danny Oerndrup <daor@demant.com>
The macro is intended to abstract the -imacros compiler option for
inclusion of the autoconf.h header file. The abstraction allows for a
given toolchain to decide how the inclusion of the header file is to
be done.
The intent here is to abstract Zephyr's dependence on toolchains,
thus allowing for easier porting to other, perhaps commercial,
toolchains and/or usecases.
No functional change expected.
Signed-off-by: Danny Oerndrup <daor@demant.com>
The macro is intended to abstract the -ffreestanding compiler option
which tells the compiler that this is a bare metal env. The option is
compiler and thus toolchain specific, but this macro leaves it up to
the toolchain to decide the value of the option.
The intent here is to abstract Zephyr's dependence on toolchains,
thus allowing for easier porting to other, perhaps commercial,
toolchains and/or usecases.
No functional change expected.
Signed-off-by: Danny Oerndrup <daor@demant.com>
cmake has a number of issues dealing with symbolic links:
https://gitlab.kitware.com/cmake/cmake/issues/16228
One of them can cause cmake to rewrite the -S input from the user and
CMAKE_SOURCE_DIR to unexpectedly include symbolic links:
https://cmake.org/pipermail/cmake/2019-May/thread.html#69496
Catch this corner case and warn about subtle issues like breaking
-fmacro-prefix-map=${ZEPHYR_BASE}=
Sample warning message:
CMake Warning at ../../CMakeLists.txt:30 (message):
ZEPHYR_BASE doesn't match CMAKE_CURRENT_SOURCE_DIR
ZEPHYR_BASE = ~/zephyrproject/zephyr
PWD = ~/westsymlink/zephyr/samples/hello_world
CMAKE_CURRENT_SOURCE_DIR = ~/westsymlink/zephyr
You may be using a mix of symbolic links and real paths which causes
subtle and hard to debug CMake issues.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
This helps by letting us add checks for when the runner has already
been set. There is documentation saying you can set
-DBOARD_DEBUG_RUNNER at the command line and have it take effect,
which turns out not to be true for a large number of boards.
A status message helps the user debug.
(We'll address the existing in-tree boards in the next patch.)
Signed-off-by: Marti Bolivar <marti.bolivar@nordicsemi.no>
Add a version check to allow building with older GCC versions that did
not support this option.
Fixes#16607
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
With gcc 9.1.x on fedora 30 we are getting new warnings that turn into
errors when running sanitycheck. Disable those while the issues are
being addressed.
Relates to #16587
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
This is a graphical configuration interface written in Tkinter. Like
menuconfig.py, it supports showing all symbols (with invisible symbols
in red) and jumping directly to symbols. Symbol values can also be
changed directly from the jump-to dialog.
This interface should feel a lot smoother than menuconfig.py on Windows.
When single-menu mode is enabled, a single menu is shown at a time, like
in the terminal menuconfig. Only this mode distinguishes between symbols
defined with 'config' and symbols defined with 'menuconfig'.
Compatible with both Python 2 and Python 3. Has been tested on X11,
Windows, and macOS.
To avoid having to carry around a bunch of GIFs, the image data is
embedded in guiconfig.py. To use separate GIF files instead, change
_USE_EMBEDDED_IMAGES to False. The image files can be found in
https://github.com/ulfalizer/Kconfiglib/tree/screenshots/guiconfig.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Make headers look like this instead:
/* From ${ZEPHYR_BASE}/arch/common/isr_tables.ld: */
Besides being shorter and more "private", this makes the content of
snippets-*.ld files the same no matter who built them and where.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
With the addition of a local CMake variable ZEPHYR_BASE that mirrors the
value of the environment variable the documentation build broke on
Windows. This is because CMake was incorrectly interpreting backslashes
present in the Windows path as escaping characters. In order to avoid
this, use CMake's built-in file(TO_CMAKE_PATH) functionality, which
converts the path to a canonical version using forward slashes only.
At the same time rework boilerplate.cmake to use the same mechanism
instead of manually replacing backslashes and removing trailing ones.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
Introducing the macro toolchain_cc_warning_error_implicit_int which,
abstracts the implicit_int error flag thus leaving it to the toolchain
to decide whether this flag is needed or not.
The intent here is to abstract Zephyr's dependence on toolchains,
thus allowing for easier porting to other, perhaps commercial,
toolchains and/or usecases.
No functional change expected.
Signed-off-by: Danny Oerndrup <daor@demant.com>
The macros are named toolchain_cc_warning_error_misra_sane and
toolchain_cc_cpp_warning_error_misra_sane
These macros provide toolchain specific flag(s) relating to the MISRA
SANE configuration option.
The macros will place the flag(s) in a variable provided by caller,
which can then add to zephyr compile options.
The intent here is to abstract Zephyr's dependence on toolchains,
thus allowing for easier porting to other, perhaps commercial,
toolchains and/or usecases.
No functional change expected.
Signed-off-by: Danny Oerndrup <daor@demant.com>
on non-XIP system, SRAM is the default region, and relocated .data
section and .bss section of SRAM shouldn't be inserted between
_image_rom_start and _image_rom_end, because the memory region between
_image_rom_start and _image_rom_end will construct the mpu ro region.
Also for the newly added memory region on non-XIP system, the
relocated .text secition and .rodata section should also be mpu aligned.
Fixes: #16090.
Signed-off-by: Wentong Wu <wentong.wu@intel.com>
'west --version' output has the path to the west manifest directory.
If there is a semantic version string in this path name, it will
raise a false version check failure.
Signed-off-by: Thomas Stilwell <Thomas.Stilwell@nordicsemi.no>
Shields can often be very complex to setup in a generic way for several
boards to support. Let's allow shields to have their own .conf files
as well as specialized overlays per board (when needed).
Signed-off-by: Michael Scott <mike@foundries.io>
Allows snippets to be placed in different locations:
- The noinit, rwdata and rodata output sections
- Two different locations for placing custom output sections,
one location for RAM and another for all other sections.
Signed-off-by: Øyvind Rønningstad <oyvind.ronningstad@nordicsemi.no>
This is placeholder for extended warning flags, likely to change between
toolchains.
The intent here is to abstract Zephyr's dependence on toolchains,
thus allowing for easier porting to other, perhaps commercial,
toolchains and/or usecases.
No functional change expected.
Signed-off-by: Danny Oerndrup <daor@demant.com>
This is placeholder for base warning flags, common to most toolchains.
The intent here is to abstract Zephyr's dependence on toolchains,
thus allowing for easier porting to other, perhaps commercial,
toolchains and/or usecases.
No functional change expected.
Signed-off-by: Danny Oerndrup <daor@demant.com>
The introduced macros are placeholders for the cmake parameter warning
level.
The intent here is to abstract Zephyr's dependence on toolchains,
thus allowing for easier porting to other, perhaps commercial,
toolchains and/or usecases.
No functional change expected.
Signed-off-by: Danny Oerndrup <daor@demant.com>
No functional change expected.
This is motivated by the wish to abstract Zephyr's usage of toolchains,
permitting non-intrusive porting to other (commercial) toolchains.
Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
- Add examples for the latter.
- Point at each other and highlight how independent they are from each
other.
- State their inputs and outputs in plain English.
- Fix "git describe" error message giving the wrong impression that
everyone cares about BUILD_VERSION. Only the boot banner cares now.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Move PROPERTY_LINKER_SCRIPT_DEFINES to toolchain_ld_base.
No functional change expected.
This is motivated by the wish to abstract Zephyr's usage of toolchains,
permitting non-intrusive porting to other (commercial) toolchains.
Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
No functional change expected.
This is motivated by the wish to abstract Zephyr's usage of toolchains,
permitting non-intrusive porting to other (commercial) toolchains.
Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
On some systems where you don't have access to `PATH` and you can't
set the `ENV{PATH}` variable. You need to be able to pass the path
to the west executable down to the python script so it is better
for it to be set explicitly than assuming that it exsists as a
part of the PATH/executables in the shell being called.
Signed-off-by: Sigvart M. Hovland <sigvart.hovland@nordicsemi.no>
While configure_linker_script() may be useful for other linkers, it
currently only aimed at GNU ld. To really be useful among different
linkers, we would need to abstract its usage of the C preprocessor.
We can do this later, if needed.
No functional change expected.
Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
No functional change expected.
This is motivated by the wish to abstract Zephyr's usage of toolchains,
permitting non-intrusive porting to other (commercial) toolchains.
Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
