Commit graph zephyr/arch/riscv
Author SHA1 Message Date
Mrinal Sen
1246cb8cef debug: tracing: Remove unneeded abstraction
Various C and Assembly modules
make function calls to z_sys_trace_*. These merely call
corresponding functions sys_trace_*. This commit
is to simplify these by making direct function calls
to the sys_trace_* functions from these modules.
Subsequently, the z_sys_trace_* functions are removed.

Signed-off-by: Mrinal Sen <msen@oticon.com>
2019-09-26 06:26:22 -04:00
Huang Qi
2c277077fe arch: riscv: Use infinite loop instead of simple wfi to halt slave core
If it's a multicore system, infinite loop wfi to halt slave core

Signed-off-by: Huang Qi <757509347@qq.com>
2019-09-20 10:42:28 -04:00
Huang Qi
19da4ee379 arch: riscv: Add simple wrokaround to boot multicore system
Just boot master core, halt others

Signed-off-by: Huang Qi <757509347@qq.com>
2019-09-20 10:42:28 -04:00
Andrew Boie
a470ba1999 kernel: remove z_fatal_print()
Use LOG_ERR instead.

Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
2019-09-12 05:17:39 -04:00
Peter Bigot
43fc6a7eff arch/riscv: rearrange for standard use of extern "C"
Consistently place C++ use of extern "C" after all include directives,
within the negative branch of _ASMLANGUAGE if used.

Remove extern "C" support from files that don't declare objects or
functions.

Background from issue #17997:

Declarations that use C linkage should be placed within extern "C"
so the language linkage is correct when the header is included by
a C++ compiler.

Similarly #include directives should be outside the extern "C" to
ensure the language-specific default linkage is applied to any
declarations provided by the included header.

See: https://en.cppreference.com/w/cpp/language/language_linkage
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
2019-08-18 16:20:10 +02:00
Karsten Koenig
f0d4bdfe3f include: arch: riscv: rename global macro
SR and LR were used as global names for load and store RISC-V assembler
operations, colliding with other uses such as SR for STATUS REGISTER in
some peripherals. Renamed them to a longer more specific name to avoid
the collision.

Signed-off-by: Karsten Koenig <karsten.koenig.030@gmail.com>
2019-08-17 11:48:02 +02:00
Nicolas Pitre
c351492bc7 riscv: toolchain arguments for a 64-bit build
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>
2019-08-09 09:11:45 -05:00
Nicolas Pitre
39ada71688 riscv: isr.S: fix a missing lw to LR conversion
This loads a pointer and therefore has to use LR to be 64-bit
compatible.

Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
2019-08-05 21:51:09 +02:00
Nicolas Pitre
0440a815a9 riscv: make core code 64-bit compatible
There are two aspects to this: CPU registers are twice as big, and the
load and store instructions must use the 'd' suffix instead of the 'w'
one. To abstract register differences, we simply use a ulong_t instead
of u32_t given that RISC-V is either ILP32 or LP64. And the relevant
lw/sw instructions are replaced by LR/SR (load/store register) that get
defined as either lw/sw or ld/sd. Finally a few constants to deal with
register offsets are also provided.

Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
2019-08-02 13:54:48 -07:00
Nicolas Pitre
1f4b5ddd0f riscv32: rename to riscv
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>
2019-08-02 13:54:48 -07:00