HAL module request: hal_realtek

[zjian-zhang]

Origin

This is a repository containing the Realtek SDK, which currently includes the Ameba SOC series. In the future, it will also include drivers for other SOCs in our company.
https://github.com/zjian-zhang/hal_realtek

Purpose

Reuse an existing hardware abstraction layer from the Ameba-AIoT SDK to support the drivers for AmebaDplus and Ameba-D SoCs.

Mode of integration

The module should be integrated as an external HAL module. The proposed name is hal_realtek.

Maintainership

hal_realtek will be maintained by for now:
@zjian-zhang

Pull Request

#78036 and #91933

Description

ameba-rtos is the development framework for Realtek SoCs supported on Linux, which contains the necessary software and tools to develop firmware for the AmebaDplus. This includes register files, peripheral drivers, system startup files, documentation, various utilities, third-party libraries and a toolchain.

The hal_realtek is a pared-down version of the ameba-rtos that contains only the components needed for Zephyr; namely, register files and bare metal peripheral drivers. Utilities, toolchains, and other components not needed by Zephyr are excluded. The hal_realtek will be an artifact generated by a GitHub Actions workflow implemented in the ameba-rtos repository.

Dependencies

none

Revision

b609aba258a9e44f836cd1725a15be267d7a0550

License

Apache-2.0 license

[github-actions]

Hi @zjian-zhang! We appreciate you submitting your first issue for our open-source project. 🌟

Even though I'm a bot, I can assure you that the whole community is genuinely grateful for your time and effort. 🤖💙

[nordicjm]

Binary files are not allowed

[zjian-zhang]

I have deleted the Binary files and will create a new Issue: Binary blobs for adding the binary blobs.

[keith-zephyr]

I see hal_realtek includes some cmsis files. Can the hal_realtek module use the one of the existing CMSIS modules instead?

• https://github.com/zephyrproject-rtos/cmsis
• https://github.com/zephyrproject-rtos/CMSIS_6

[zjian-zhang]

I see hal_realtek includes some cmsis files. Can the hal_realtek module use the one of the existing CMSIS modules instead?

• https://github.com/zephyrproject-rtos/cmsis
• https://github.com/zephyrproject-rtos/CMSIS_6

Thanks for your reply.

1. The hal_realtek repository is a copy (not a fork) of the ameba-rtos repository, which means the entire amebadplus folder was copied.
2. The hal_realtek use the same core_cm55.h as https://github.com/zephyrproject-rtos/cmsis, but our soc has a cache module in core_cm23, so the file core_cm23_km0.h is not identical and should be included.

If hal_realtek cannot include some cmsis files, we can remove it, and delete them when copying from ameba-rtos repository. waiting for your reply.

[keith-zephyr]

I see hal_realtek includes some cmsis files. Can the hal_realtek module use the one of the existing CMSIS modules instead?

• https://github.com/zephyrproject-rtos/cmsis
• https://github.com/zephyrproject-rtos/CMSIS_6

Thanks for your reply.

1. The hal_realtek repository is a copy (not a fork) of the ameba-rtos repository, which means the entire amebadplus folder was copied.
2. The hal_realtek use the same core_cm55.h as https://github.com/zephyrproject-rtos/cmsis, but our soc has a cache module in core_cm23, so the file core_cm23_km0.h is not identical and should be included.

If hal_realtek cannot include some cmsis files, we can remove it, and delete them when copying from ameba-rtos repository. waiting for your reply.

I think it would be preferred to use the existing https://github.com/zephyrproject-rtos/cmsis module, and remove the CMSIS provided headers from hal_realtek.

However, I do see some other HALs pull in a local copy of CMSIS content. I see the NXP HAL also makes a copy of many CMSIS files. @dleach02 - do you know the history of NXP's inclusion of CMSIS?

[zjian-zhang]

I see hal_realtek includes some cmsis files. Can the hal_realtek module use the one of the existing CMSIS modules instead?

• https://github.com/zephyrproject-rtos/cmsis
• https://github.com/zephyrproject-rtos/CMSIS_6

Thanks for your reply.

1. The hal_realtek repository is a copy (not a fork) of the ameba-rtos repository, which means the entire amebadplus folder was copied.
2. The hal_realtek use the same core_cm55.h as https://github.com/zephyrproject-rtos/cmsis, but our soc has a cache module in core_cm23, so the file core_cm23_km0.h is not identical and should be included.

If hal_realtek cannot include some cmsis files, we can remove it, and delete them when copying from ameba-rtos repository. waiting for your reply.

I think it would be preferred to use the existing https://github.com/zephyrproject-rtos/cmsis module, and remove the CMSIS provided headers from hal_realtek.

However, I do see some other HALs pull in a local copy of CMSIS content. I see the NXP HAL also makes a copy of many CMSIS files. @dleach02 - do you know the history of NXP's inclusion of CMSIS?

I have already removed the CMSIS provided headers from hal_realtek.

[zjian-zhang]

Please help to check again if there are any problems. I have other blobs to submit based on this repository, thanks.

[nordicjm]

I don't want to see another NXP-like hal added personally, so can you explain what any of this is and why it's needed in your hal:

• https://github.com/zjian-zhang/hal_realtek/blob/main/ameba/amebadplus/source/app/monitor/ram/monitor_km0.c what is this?
• https://github.com/zjian-zhang/hal_realtek/blob/main/ameba/amebadplus/source/misc/ameba_ota.c why do you need ota files? How is this useful for zephyr when mcuboot is the bootloader that zephyr uses?
• https://github.com/zjian-zhang/hal_realtek/tree/main/ameba/amebadplus/source/swlib/libnosys what are any of these files, why are any of them needed?
• https://github.com/zjian-zhang/hal_realtek/blob/main/ameba/amebadplus/source/swlib/log.c zephyr has a logging subsystem, why is there some custom log thing here?
• https://github.com/zjian-zhang/hal_realtek/blob/main/ameba/amebadplus/source/usrcfg/ameba_bootcfg.c zephyr devices are configured through devicetree, why are you doing it in a .h file?
• https://github.com/zjian-zhang/hal_realtek/blob/main/ameba/amebadplus/source/usrcfg/ameba_flashcfg.c as above
• https://github.com/zjian-zhang/hal_realtek/blob/main/ameba/amebadplus/source/usrcfg/include/ameba_userheapcfg.h heap is zephyr controlled by Kconfig, so it's definitely not 0
• https://github.com/zjian-zhang/hal_realtek/tree/main/ameba/amebadplus/ld why are there linker files for adding mbedtls functions or c stdio functions when zephyr deals with these?
• https://github.com/zjian-zhang/hal_realtek/tree/main/ameba/common/os_wrapper/source you are using zephyr functions and defines from your hal, your hal should have no knowledge of zephyr at all, it just needs to be the hal

[gmarull]

For reference: Zephyr glue code is NOT allowed in hal repos, otherwise any change in Zephyr can become a multirepo nightmare.

[zjian-zhang]

I don't want to see another NXP-like hal added personally, so can you explain what any of this is and why it's needed in your hal:

• https://github.com/zjian-zhang/hal_realtek/blob/main/ameba/amebadplus/source/app/monitor/ram/monitor_km0.c what is this?
  the whole folder was copied from ameba-rtos repository, so this file is here.
• https://github.com/zjian-zhang/hal_realtek/blob/main/ameba/amebadplus/source/misc/ameba_ota.c why do you need ota files? How is this useful for zephyr when mcuboot is the bootloader that zephyr uses?
  as above.
• https://github.com/zjian-zhang/hal_realtek/tree/main/ameba/amebadplus/source/swlib/libnosys what are any of these files, why are any of them needed?
  do not need them now, they were used for zero warning in our sdk when build with no OS.
• https://github.com/zjian-zhang/hal_realtek/blob/main/ameba/amebadplus/source/swlib/log.c zephyr has a logging subsystem, why is there some custom log thing here?
  the driver code use some log api like RTK_LOGx, and we do not want to changed to log api from zephyr.
• https://github.com/zjian-zhang/hal_realtek/blob/main/ameba/amebadplus/source/usrcfg/ameba_bootcfg.c zephyr devices are configured through devicetree, why are you doing it in a .h file?
  we will use our bootloader, not mucboot, so the ameba_bootcfg.c used for config out bootloader can be here? or every configuration for our bootloader must through devicetree like zephyr.bin?
• https://github.com/zjian-zhang/hal_realtek/blob/main/ameba/amebadplus/source/usrcfg/ameba_flashcfg.c as above
• https://github.com/zjian-zhang/hal_realtek/blob/main/ameba/amebadplus/source/usrcfg/include/ameba_userheapcfg.h heap is zephyr controlled by Kconfig, so it's definitely not 0
  it was not uesd in zephyr, and I have removed it.
• https://github.com/zjian-zhang/hal_realtek/tree/main/ameba/amebadplus/ld why are there linker files for adding mbedtls functions or c stdio functions when zephyr deals with these?
  the ld files are symbols of the rom code in asic, and mbedtls or c stdio functions are used in our drivers, the drives are also in the rom, so mbedtls or c stdio functions must in rom. we list all of symbols of rom and provide with PROVIDE(xxx = xxxx);，so they are all weak symbol, and does not impact zephyr's strong symbol.
• https://github.com/zjian-zhang/hal_realtek/tree/main/ameba/common/os_wrapper/source you are using zephyr functions and defines from your hal, your hal should have no knowledge of zephyr at all, it just needs to be the hal
  I have move the os wrapper to zephyr/soc/realtek/ameba, am i right? our driver need some service from OS, and we implement the glue code to support multi OS.

[zjian-zhang]

For reference: Zephyr glue code is NOT allowed in hal repos, otherwise any change in Zephyr can become a multirepo nightmare.

I have move the os wrapper to zephyr/soc/realtek/ameba, am i right? I refer to other hal_xxx and implement the glue code here, and now I do not where to put it.