AW: RTEMS trap handling versus RISCV mtvec BASE and MODE

Hesham Almatary wrote: > You might be confusing taking BASE[XLEN-1:2] (see Figure 3.8) with shifting > an address by 2. RTEMS aligns _RISCV_Exception_handler to 4 bytes as per the > specification, so you'd always end up with an address with zeros in the least > significant 2 bits. So,

RTEMS trap handling versus RISCV mtvec BASE and MODE

hello world, I'm scratching my head over what may turn out to be a glitch in Volume 2, Privileged Spec v. 20190608 RISC-V https://github.com/riscv/riscv-isa-manual/releases/download/Ratified-IMFDQC-and-Priv-v1.11/riscv-privileged-20190608.pdf In particular, the way RTEMS for RISCV sets the

Handling RISC-V32 interrupts and traps, mcause mapping for rtems_interrupt_catch()

Hello *, I'm trying to install interrupt and trap handlers for interrupts and traps not used by RTEMS 5 on a RISC-V32 rocket chip system. In "Volume II: RISC-V Privileged Architectures" I found "Table 3.6: Machine cause register (mcause) values." listing the interrupts and traps: Interrupt

Overcoming a 256 bytes console/uart limit

Hello world\n I'm observing a 256 byte input limit with RTEMS 5 on riscv that I don't know how to overcome. We are using the RTEMS console driver and newlib stdio. The effect is that an fgets() appears to only accept 256 characters, specifically if we connect via picocom on a Linux box, we can

Where to define CPU_SIMPLE_VECTORED_INTERRUPTS for RISC-V?

Hello world, we are using a customized RV32IMAF CPU with RTEMS and need to handle interrupts. I'm new to configuring low level things such as this and need a bit of guidance where goes what. I build using the RTEMS source builder. It appears that for RISC-V a value for

AW: LEON3 RTEMS rc7 Tool Issue

The rc7 change log talks about DWARF v2 versus v4 incompatibilities: 1.3-rc7 (20191129) - released LLVM/Clang 8.0 toolchain built on stable LLVM branch * UT700/UT699E support with errata work-arounds * REX support: LEON-REX backend (16-bit ISA) added * various LEON optimizations

AW: sparc and trap 4 (floating point disabled)

Hello Sebastian et al., > Hello Jens, > in uni-processor configurations a lazy floating-point context switch is done > on SPARC. You can search for SPARC_USE_LAZY_FP_SWITCH in the sources. This appears to be the reason for the observed behavior. Looking at the disassembled application code:

sparc and trap 4 (floating point disabled)

Hello, world\n I have a question about the use of trap 4 by RTEMS on Sparc32 (leon3). Since our app needs FP, we set the PSR[EF] bit during the boot process before RTEMS is invoked. Since we don't expect the fp_disabled trap (4) to occur, we install a fatal handler for it with