STM32 Cortex-M33, such as the L5/H5/U5 series, have a cache peripheral for
instruction and data caches, which are not present in the C-M33
architecture spec.
The driver defaults to direct mapped cache as it uses less power than the
alternative set associative mapping [1]. This has also been the default in
stm32 soc initialization code for chips that have the ICACHE peripheral,
which makes it the safest choice for backward compatibility. The exception
to the rule is STM32L5, which has the n-way cache mode selected in SOC
code.
[1]: https://en.wikipedia.org/wiki/Cache_placement_policies
Signed-off-by: Henrik Lindblom <henrik.lindblom@vaisala.com>
This adds a few line use zephyr_syscall_header() to include
headers containing syscall function prototypes.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Following 4806e1087e ,
the following warning appears for some boards (e.g. `qemu_cortex_a53`)
```
CMake Warning at /zephyr/CMakeLists.txt:798 (message):
No SOURCES given to Zephyr library: drivers__cache
Excluding target from build.
```
Allow this driver to have no sources.
Signed-off-by: Henri Xavier <datacomos@huawei.com>
When a cache API function is called from userspace, this results on
ARM64 in an OOPS (bad syscall error). This is due to at least two
different factors:
- the location of the cache handlers is preventing the linker to
actually find the handlers
- specifically for ARM64 and ARC some cache handling functions are not
implemented (when userspace is not used the compiler simply optimizes
out these calls)
Fix the problem by:
- moving the userspace cache handlers to a their logical and proper
location (in the drivers directory)
- adding the missing handlers for ARM64 and ARC
Signed-off-by: Carlo Caione <ccaione@baylibre.com>
The CPU in Aspeed AST10x0 SOC is a ARM Cortex-M4 which doesn't internal
cache memory. Aspeed implements an integrated system level cache to
accelerate instruction and data memory accesses.
Signed-off-by: Dylan Hung <dylan_hung@aspeedtech.com>
The cache API currently shipped in Zephyr is assuming that the cache
controller is always on-core thus managed at the arch level. This is not
always the case because many SoCs rely on external cache controllers as
a peripheral external to the core (for example PL310 cache controller
and the L2Cxxx family). In some cases you also want a single driver to
control a whole set of cache controllers.
Rework the cache code introducing support for external cache
controllers.
Signed-off-by: Carlo Caione <ccaione@baylibre.com>
This adds support for the EC (embedded controller) on a Google
reference board with codename "kukui". This board uses the STM32F098RC
chip. We built an application for the board and verified UART
functionality on the board.
Signed-off-by: Jack Rosenthal <jrosenth@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
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>
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>
Move the SoC outside of the architecture tree and put them at the same
level as boards and architectures allowing both SoCs and boards to be
maintained outside the tree.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
This commit adds support for Microsemi Mi-V RISC-V softcore CPU
running on the M2GL025 IGLOO2 FPGA development board.
signed-off-by: Karol Gugala <kgugala@antmicro.com>
This commit moves code from fe310 platform into RISC-V privilege common
folder. This way the code can be reused by other platforms in future.
signed-off-by: Karol Gugala <kgugala@antmicro.com>
Introducing CMake is an important step in a larger effort to make
Zephyr easy to use for application developers working on different
platforms with different development environment needs.
Simplified, this change retains Kconfig as-is, and replaces all
Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild
offers is replaced by a set of CMake extentions. These extentions have
either provided simple one-to-one translations of KBuild features or
introduced new concepts that replace KBuild concepts.
This is a breaking change for existing test infrastructure and build
scripts that are maintained out-of-tree. But for FW itself, no porting
should be necessary.
For users that just want to continue their work with minimal
disruption the following should suffice:
Install CMake 3.8.2+
Port any out-of-tree Makefiles to CMake.
Learn the absolute minimum about the new command line interface:
$ cd samples/hello_world
$ mkdir build && cd build
$ cmake -DBOARD=nrf52_pca10040 ..
$ cd build
$ make
PR: zephyrproject-rtos#4692
docs: http://docs.zephyrproject.org/getting_started/getting_started.html
Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>