[feat][zephyr] Enable bl_mcu_sdk as zephyr module

[nandojve]

The ZephyrRTOS is a newer Open Source RTOS. It strives to deliver the best-in-class RTOS for connected resource-constrained devices, built to be secure and safe.

This add ZephyrRTOS entry point and define environment to build Bouffalo Lab low level peripheral drivers as hal_bouffalolab. Initially, bl602 is the target but can be extended to any other SoC series present in the bl_mcu_sdk.

The commit sequence try fix small issues found due to code isolation. The BFLB_USE_PLATFORM was necessary to be created to isolate low level drivers and Bouffalo Lab HAL, once Zephyr have their own.

The zephyr directory is completely isolated from bl_mcu_sdk and not interfere. This layout was created to allow add manufacturer repositories as external modules into ZephyrRTOS.

Currently there is a minimal attempt to enable Bouffalo Lab SoC at ZephyrRTOS at PR 37686

How to Build/Flash on a working zephyr environment:

1. Clone PR 37686
2. Read board/riscv/dt_bl10_devkit/doc/index.rst
3. west update
4. west build -b dt_bl10_devkit samples/hello_world
5. west flash

[nandojve]

Hello, due to recent changes in Zephyr. I'd prefer add 3437feb later.
Would BFLB accept others? I can drop 3437feb and send an update.

The 0bc9054 is just a proposal. But a similar solution is essential to allow use bl_mcu_sdk as hal_bouffalolab for Zephyr.
If this require more time to find a better solution, I can drop it from sequence too.

Regards,
Gerson

[sakumisu]

@nandojve Thank you sincerely for your PR.

1. 49e938d contains nothing i saw, could you check again?
2. 28ac5d7 has merged locally, thanks!
3. d756f6d, efbc5c1, and 86b13eb
   firstly, bl602_romdriver.c do not participate in compilation. and ROM_API_INDEX_XIP_SFlash_Read_With_Lock cannot modify with ROM_API_INDEX_XIP_SFlash_Read_Need_Lock, these two functions have a difference. Others are the same reason. ASM_Delay_US is replaced by arch_delay_us.
4. af636a6 and e91b7ed have merged locally, thanks!
5. c6b1d43 do not miss <stdint.h>, soft_crc.h included it.
6. 0bc9054f64 , we have remove bflb_platform.h in chip drivers, but riscv_encoding.h has left, you are cordially invited to resubmit this change.

Also, if your project has managed irq, like nuttx, zephyr or other os, you need to ignore interrupt.c into compiling.

Best Regards,
jzlv

[nandojve]

Hi @sakumisu ,

Thank you for the explanation. I successfully drop bl602_romdriver.c from build.
I send remaining things.

Regards,
Gerson

[sakumisu]

Hi @nandojve ,is the directory:zephyr updated frequently?If so ,maybe bl_mcu_sdk and zephyr are in the peer path better?

root
├── bl_mcu_sdk
└── zephyr

Another, BFLB_USE_PLATFORM maybe is ambiguous, if disabled, our driver may compile error, we need it, if enabled, yours may compile error?

[nandojve]

Hi @nandojve ,is the directory:zephyr updated frequently?If so ,maybe bl_mcu_sdk and zephyr are in the peer path better?

No, is rarely updated. Zephyr uses this directory to instruct toolchain how to handle Cmake and Kconfig option. The newer format allows include any project into ZephyrRTOS without add files. You can see by here how I manage to build bl_mcu_sdk as hal_bouffalolab. This means that every newer version of bl_mcu_sdk can be easy sync with ZephyrRTOS project. I mean, the intention is to use bl_mcu_sdk as upstream repository for hal_bouffalolab repository at zephyrproject github account.

Another, BFLB_USE_PLATFORM maybe is ambiguous, if disabled, our driver may compile error, we need it, if enabled, yours may compile error?

I set this as 'build always' in your toolchain cmake rules. This means, if users try to build using BFLB cmake, it will be always included. From my side, this is never defined and riscv_encoding.h is excluded. After v1.4.1 BFLB_USE_PLATFORM become almost irrelevant. The important thing whould be define a way to exclude riscv_encoding.h, because others RTOS may already define it. ZephyrRTOS is one of those and I got build errors.

[sakumisu]

Hi,@nandojve in riscv_encoding.h ,our chip driver needs some macro ,so if set BFLB_USE_PLATFORM=0 , compile error also.

[nandojve]

Hi @sakumisu ,

I think best I can do is add the __ZEPHYR__ conditional guard to allow build ZephyrRTOS without breaking BFLB code compatibility.

[sakumisu]

Hi @nandojve,I think you may have misunderstood what I meant.What I mean is that ,for example, if i need write_csr macro, but if cannot define in zephyr, in zephyr, it defined by csr_write , so chip driver will compile error even if there is no error reported yet.And ,csr.h in zephyr is not very comprehensive, some macros do not have,like MTVT.

[nandojve]

Hi @sakumisu ,

Yes, I did.

I took another look and it is clear to me that RISC-V should be initialized at Zephyr side. For now, I just copy source from sdk and added temporally at soc directory. The proposed changes at bl_mcu_sdk are to move includes in the right place. I mean, move riscv includes out bl602/bl702.h to source files, since a very small number of sources files are using, I presume.

Let me know what you think about this.

[sakumisu]

Hi,@nandojve, if csr.h in zephyr can add fpu and mtvt macro,i can copy csr in our sdk.This will be best.And then like this.

#ifdef BFLB_USE_ISA_FILE
#include BFLB_USE_ISA_FILE
#endif

in c flag will be -DBFLB_USE_ISA_FILE="csr.h"

[nandojve]

Just another comment, not sure if it is relevant at this moment but I saw that you have NMSIS at components/nmsis.
There is a plan to add it at zephyrproject-rtos/zephyr#39491

[sakumisu]

Just another comment, not sure if it is relevant at this moment but I saw that you have NMSIS at components/nmsis. There is a plan to add it at zephyrproject-rtos/zephyr#39491

yes,also in nmsis has the same encoding.

[nandojve]

Hi @sakumisu ,

Hi,@nandojve, if csr.h in zephyr can add fpu and mtvt macro,i can copy csr in our sdk.This will be best.And then like this.

I think it is possible add missing macros. To do it, it will be necessary a commit in PR 37686 sequence with newer macros.

[nandojve]

Hi @sakumisu ,

I was thinking about this issue and realize that real problem is that arch dependent files are together with SoC registers definition. RISC-V core files are used in very few places: risc-v timer, interrupts and system initialization; and can be defined by RTOS, like Zephyr is doing.

drivers/blX02_driver/hal_drv/src/hal_mtimer.c
drivers/blX02_driver/startup/interrupt.c
drivers/blX02_driver/startup/system_bl602.c

On my view, drivers never will require any risc-v/arm definitions and that entries could be safe removed from blX02.h. It require only add proper include in a few places like f33ca05. I'm asking to you review this option because for any RTOS those will be specific. In case of Zephyr, risc-v timer, interrupts and system initialization will be made in the main tree and will not use bl_mcu_sdk.

On my view, and I can be wrong, seems better not contaminate register include files.

Could you check if this is a valid solution ?

[nandojve]

Hi @sakumisu ,

I was wondering if you have time to check my last comment.

BTW, Nuclei specific will be add as a newer file instead a full module. This reinforce that #18 (comment) may be a definitive solution. Do you mind send me PVT your expected solution so I can incorporate at Draft? If you prefer, you can simple open a Zephyr PR adding missing entries.

[sakumisu]

@nandojve Hi, we have evaluated your solution,is a better way currently, and next time will be merged in locally.

[sakumisu]

Has done，i cherry picked your previous commit

[nandojve]

Already merged