Module Request: hisilicon

[xingrz]

Origin

https://github.com/xingrz/zephyr_module_hisilicon

Purpose

This repository provides source of components support for the HiSilicon Hi3861 SoC.

Mode of integration

Please integrate this project as a module.

Maintainership

• @xingrz

Pull Request

57363

Description

This repository contains the source code of loaderboot for the HiSilicon Hi3861 SoC. It has been selectively imported from the original SDK and is required by the hiburn runner, which I have implemented in the PR above.

Loaderboot is a bootable image. When flashing the board, this image will be sent to and executed from the RAM of the SoC. It receives data from hiburn on the host side and writes it onto the flash.

Since Hi3861 is a WiFi SoC, this repository will also be used to declare the references for RF blobs to be fetched in the future.

Dependencies

None.

Revision

https://github.com/xingrz/zephyr_module_hisilicon/tree/4754f8a9ab31556cd15bd98143c60f653165d280

License

Apache-2.0

[henrikbrixandersen]

License

Apache-2.0

This is not correct. At least some of the files (i.e. hi3861/boot/flashboot/riscv_init.S are under 3-clause BSD.

[xingrz]

License

Apache-2.0

This is not correct. At least some of the files (i.e. hi3861/boot/flashboot/riscv_init.S are under 3-clause BSD.

You're right. But the original LiteOS SDK says it was released under Apache-2.0 License.

https://gitee.com/openharmony/device_soc_hisilicon/tree/master/hi3861v100/sdk_liteos/license

[xingrz]

License

Apache-2.0

This is not correct. At least some of the files (i.e. hi3861/boot/flashboot/riscv_init.S are under 3-clause BSD.

You're right. But the original LiteOS SDK says it was released under Apache-2.0 License.

https://gitee.com/openharmony/device_soc_hisilicon/tree/master/hi3861v100/sdk_liteos/license

Oh, I see what the issue is now. The manufacturer has released their code from multiple sources. Initially, they provided zip files on their website, but now they release the code on Gitee, where all sources have been re-licensed with Apache 2.0. I will update my repository with the latest sources.

[xingrz]

License

Apache-2.0

This is not correct. At least some of the files (i.e. hi3861/boot/flashboot/riscv_init.S are under 3-clause BSD.

I just updated and switched to the OpenHarmony branch. Now the code is definitely licensed under Apache 2.0.

[keith-zephyr]

Can you contribute the flashboot directly into the Zephyr tree? This code is your own, correct?

The loaderboot code probably makes sense as a module, but it's definitely not a HAL.

[xingrz]

Can you contribute the flashboot directly into the Zephyr tree? This code is your own, correct?

Yes, but I'm not sure which directory I should place it in.

[henrikbrixandersen]

Yes, but I'm not sure which directory I should place it in.

Perhaps a subdirectory to the soc directory?

[keith-zephyr]

@xingrz - Can you drop the "hal" from the proposed module name? How about hisilicon_loaderboot or just hisilicon?

[xingrz]

@xingrz - Can you drop the "hal" from the proposed module name? How about hisilicon_loaderboot or just hisilicon?

Sure. However, without the "hal" prefix, is it appropriate to use this repository to declare the west blobs required for WiFi in the future?

[keith-zephyr]

@xingrz - Can you drop the "hal" from the proposed module name? How about hisilicon_loaderboot or just hisilicon?

Sure. However, without the "hal" prefix, is it appropriate to use this repository to declare the west blobs required for WiFi in the future?

Note that blobs are not permitted to be hosted in the Zephyr main tree or modules. See details here. However the module can be used to reference the blob hosted somewhere else.

Please use hisilicon as the module name. This allows flexibility to add additional code from HiSilicon in the future.

Once this issue gets updated, I'll add the TSC label so that this issue gets voted on by the TSC. Assuming it's approved, then maintainers will create the zephyrproject-rtos/hisilcon.

[xingrz]

Note that blobs are not permitted to be hosted in the Zephyr main tree or modules. See details here. However the module can be used to reference the blob hosted somewhere else.

Yes, I'm aware of that.

I've updated the title and the description of this issue.

[keith-zephyr]

The TSC noticed that there are some pre-built libraries/object files in the proposed module. https://github.com/xingrz/zephyr_module_hisilicon/tree/master/hi3861/loaderboot/libs

If these libraries are not needed, please delete from the module. If the libraries are required, you'll need to follow the process for adding binary blobs.

[xingrz]

If these libraries are not needed, please delete from the module. If the libraries are required, you'll need to follow the process for adding binary blobs.

I understand the concern. These libs are indeed necessary. However, it's important to note that these libs will not be compiled into the Zephyr binary. The loaderboot.bin itself is similar to FLM files used during JLink flash.

While it is possible to reimplement a pure open-source alternative, it would require a significant amount of time.

Instead, would it be feasible if I provide the loaderboot.bin separately in another location, such as my own GitHub repo, telling the developers that they need to obtain this additional bin file for flashing in the README for the board?

[carlocaione]

is there any progress on this discussion?

[nashif]

Marking as rejected by the TSC due to the binaries in the module.