Hi Lawrence, FYI: I have just created a github issue [1] for tracking this. Please take a look and share your thoughts. Thanks, Mani [1] https://github.com/zephyrproject-rtos/zephyr/issues/15598

---------- Forwarded message --------- From: Mani Sadhasivam <manivannanece23@...> Date: Tue, 5 Mar, 2019, 12:11 AM Subject: Re: [Zephyr-users] 96Boards GPIO standard names? To: Lawrence King <l

That's right! In RISC-V terms, Machine mode has access to all system resources and is the mandatory mode to implement. Supervisor mode has a different usage model, which I guess used for virtualizatio

#customboard #defconfig #supervisormode

Where did you find this information? For RISC-V SoCs, the supervisor mode is only used when the base architecture has the 'S' extension. Since there is no Supervisor enabled SoCs supported by Zephyr s

#customboard #defconfig #supervisormode

Hi Sathya, Which SoC are you trying with? AFAIK all supported SoC's only incorporate Machine mode access, not even User mode. Supervisor mode is meant for a full-fledged operating system. Thanks, Mani

#customboard #defconfig #supervisormode

Hi Johan, You are right... Mistakenly specified the cfg_srv model. It is working fine now :) Sure, will make use of it. Thanks for the clarification! Regards, Mani

Hello, My objective is to use 96Boards carbons running Zephyr to form a mesh network for publishing sensor data. For testing purposes, I am using Generic ON/OFF server model for sending the sensor dat

yikes... I was connecting to PB8/PB9 by looking at the pinout. But the default pinmux is configured for PB6/PB7 and it works with the same. It looks confusing with having two different I2C_1 labels in

Hello, I've observed the same issue on 96b_carbon while trying to communicate over I2C_1. In polling mode, it looks like carbon sends slave address and waits forever for the status of address sent in