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>
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 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>
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 LINKER variable is introduced to follow the same logic and flow as
the existing COMPILER variable: That is, each TOOLCHAIN is responsible
for choosing COMPILER and LINKER.
Currently, Zephyr's build system is hardcoded for GNU ld.
Reflect this in LINKER by letting all existing toolchains use GNU ld.
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>
Update the files which contain no license information with the
'Apache-2.0' SPDX license identifier. Many source files in the tree are
missing licensing information, which makes it harder for compliance
tools to determine the correct license.
By default all files without license information are under the default
license of Zephyr, which is Apache version 2.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
When using xtools as toolchain, cmake searches the toolchain home
directory. However, if the first toolchain directory does not
begin with any character before "s", "sources" (if exists) would
become the first directory being probed. Since it does not
conform to "arch-vendor-abi" naming, cmake would fail.
So exclude "sources" from the list to avoid this issue.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
newlib is not supported with this toolchain, so mark it as such and
filter tests based on the variable defined in the toolchain file.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Xtensa toolchain has a HAL library that needs to be compiled in similar
to how we do this with the Zephyr SDK.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Split up the toolchain configuration into two phases, generic and
target. The 'generic' phase configures the toolchain just enough to be
able to preprocess DT files. The 'target' phase completes the
configuration with target-specific configuration.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
Charles E. Youse