Issue

bsp/wavious-mcu/CMakeLists.txt sets values for CONFIG_WAV_MCU_IRQ_SYNC_CFG/CONFIG_WAV_MCU_IRQ_EDGE_CFG. These values are specific to WDDR's implementation. These variables should be set in a CMakeLists.txt that exists in wav-lpddr-sw project.

Feature Request

Have metal link libc, libm, and libgcc. Currently these are linked at the application level which isn't necessary if they are linked at this level instead.

Feature

configure script is specific to wav-rtos-sw. However, other projects that use this project will likely have configure scripts as well that set additional cmake variables. Instead of replicating wav-rtos-sw configure script they should be able to safely source the configure script and then add any additional cmake variables after the fact.

Patch

diff --git a/configure b/configure
index 29e62f0..edb1732 100755
--- a/configure
+++ b/configure
@@ -2,7 +2,7 @@
 # Configures build environment for appropriate target architecture
 
 # Definitions
-RISCV_TOOLCHAIN="toolchain/riscv.toolchain"
+RISCV_TOOLCHAIN="${RISCV_TOOLCHAIN}/toolchain/riscv.toolchain"
 BUILD_DIR="build"
 
 # Variables
@@ -63,10 +63,6 @@ while [ $# -gt 0 ]; do
       shift
       break
       ;;
-    -*|--*=) # unsupported flags
-      echo "Error: Unsupported flag $1" >&2
-      exit 1
-      ;;
     *) # preserve positional arguments
       PARAMS="$PARAMS $1"
       shift

Issue

This isn't an issue as much as it is a preference. It would be better to not specify a --specs in the linker / compile options of CMAKE. Instead, this option can be added at a top-level project by adding to the linker and compile options. Not specifying is a better default as it's easier to add the option, than it is to remove it.

Issue

Currently, the linker script is too coupled to freedom metal and FreeRTOS pair. We need to design an infrastructure for selecting the linker script.

Furthermore, we need a way such that once it's selected, it's set for all targets that are built for that configuration. This was the intent of the current design but after integrating v1.3-rc.2 with wav-lpddr-sw, its clear that add_linker_option is only scoped within wav-rtos-sw and doesn't apply to targets built at wav-lpddr-sw level.

We will probably just ship v1.3 with this being coupled and try to tackle it for the next major release.

Currently, all linker scripts place .trap_handler_vector at 0x00 of init. If .trap_handler_vector is not defined, .text.metal.init.enter will be placed at 0x00 instead of 0x80 as needed. A check should be added to all linker scripts to ensure this doesn't happen.

Feature Request

Currently, this project assumes that the underlying RTOS is FreeRTOS. It would be better to offer standard set of APIs that wrap this functionality. Upper layers call these functions directly. It allows for encapsulation of which RTOS is being used underneath.

• #58
• #59
• #60
• #61
• #62
• #63
• #64
• #65

Certain applications might want to configure some FreeRTOSConfig.h parameters depending on the needs of that application. For example, configUSE_IDLE_HOOK can be used to run specific code whenever the idle task is executed. On LPDDR, it would be nice to have the wfi instruction used during this case.

We should update the board level configs to wrap each define in an ifdef and/or allow a user specific FreeRTOSConfig.h to be used.

Issue

newlib support should be removed from FreeRTOSConfig.h. It's enabled but not hooked up properly. Additionally, our projects shouldn't be using newlib functions that require reentrancy. Instead, safer implementations will be used (printf in wavious-wh440). Since the newlib support is enabled for FreeRTOS, it is bringing in unnecessary functions growing the size of the code.

If for some reason newlib support is required, then the flag can be reenabled through CMAKE compile options. But this shouldn't be needed.

Issue

Image header doesn't work with wavious-wh440 board because of 32-bit versus 64-bit. Need to reevaluate in the future. Extremely low priority as of 8/2/21

Issue

A readable "dump" of the ELF file is created as a post build step for the sample application. This is done prior to patching the Image Header in the ELF with correct data and crc. This causes the "dump" to have incorrect header contents.

Fix

Fix would be to ensure that dump file isn't created until after the Image Header is patched. Also, it would be best to probably move the dump into the BSP CMakeLists.txt so that it's done for each application automatically.

Request

FreeRTOSConfig.h should be cleaned up for all BSPs. These configurations were generated for SiFive's FreeRTOS extension. This is no longer being used. The standard format should be used. It can be found here.

Issue

bsp_post_build macro needs to look at RUNTIME_OUTPUT_DIRECTORY property in order to honor per target specific output directories.

Issue

Currently Notification_t is an alias for UBaseType_t, which is dynamic based on the native word size of the processor. For 64-bit processors, the Notification_t type becomes too large to be used in some APIs (like Task Notifications).

Notification_t should just alias uint32_t instead.

Right now, all apps are required to create their own shutdown command when attempting to halt the program. It would be advantageous to have a common shutdown function in the rtos kernel which would allow for any application to call without specific implementations.

The 'v' in vReceiveMessage stands for the fact that the function returns void. However, vReceiveMessage actually returns BaseType_t. vReceiveMessage should be changed to xReceiveMessage.

Feature

RISC-V GNU Toolchain can be built with multilib option that allows riscv64-* binaries to build 32-bit application using -mabi flags. Docker images have been built that use the single binary approach.

RTOS toolchains directory should be consolidated to a single file for RISC-V so that it is compatible with the new Docker images.