Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

drivers: hci: da1469x: Add driver for CMAC core on DA1469x #57951

Merged
merged 3 commits into from
May 16, 2024

Conversation

andrzej-kaczmarek
Copy link
Collaborator

@andrzej-kaczmarek andrzej-kaczmarek commented May 16, 2023

This adds HCI driver which enables communication with CMAC core on
Renesas SmartBond(tm) DA1469x series. The CMAC firmware is provided as
a library via hal_renesas along with APIs to communicate via shared
memory. The protocol over shared memory mailboxes is H4 so the code is
based on existing hci_h4 driver.

@zephyrbot
Copy link
Collaborator

zephyrbot commented May 16, 2023

The following west manifest projects have been modified in this Pull Request:

Name Old Revision New Revision Diff
hal_renesas zephyrproject-rtos/hal_renesas@e3560c7 zephyrproject-rtos/hal_renesas@8390c9d (main) zephyrproject-rtos/[email protected]

Note: This message is automatically posted and updated by the Manifest GitHub Action.

@nordicjm
Copy link
Collaborator

The controller image is provided in hal_renesas repository

So that's a blob? This needs to follow https://docs.zephyrproject.org/latest/contribute/bin_blobs.html and have TSC approval

@andrzej-kaczmarek
Copy link
Collaborator Author

So that's a blob? This needs to follow docs.zephyrproject.org/latest/contribute/bin_blobs.html and have TSC approval

Binary blobs (or blobs for short) are files containing proprietary machine code or data in a binary format, e.g. without corresponding source code released under an OSI approved license.

So if I understand the above correctly it does not apply here since included image is a prebuilt Apache NimBLE controller. The source code is publicly available and licensed under Apache 2.0 license. It's exactly the same image that newt tool builds and links when building Apache Mynewt for DA1469x.

@carlescufi
Copy link
Member

So that's a blob? This needs to follow docs.zephyrproject.org/latest/contribute/bin_blobs.html and have TSC approval

Binary blobs (or blobs for short) are files containing proprietary machine code or data in a binary format, e.g. without corresponding source code released under an OSI approved license.

So if I understand the above correctly it does not apply here since included image is a prebuilt Apache NimBLE controller. The source code is publicly available and licensed under Apache 2.0 license. It's exactly the same image that newt tool builds and links when building Apache Mynewt for DA1469x.

This is an edge case then. You are still providing a precompiled library in binary form, so we need to at least discuss it in the TSC.

@carlescufi carlescufi added the TSC Topics that need TSC discussion label May 17, 2023
@nordicjm
Copy link
Collaborator

Note that another vendor has done similar previously and it was submitted as a blob: #54534

@andrzej-kaczmarek
Copy link
Collaborator Author

andrzej-kaczmarek commented May 17, 2023

Binary blobs (or blobs for short) are files containing proprietary machine code or data in a binary format, e.g. without corresponding source code released under an OSI approved license.
So if I understand the above correctly it does not apply here since included image is a prebuilt Apache NimBLE controller. The source code is publicly available and licensed under Apache 2.0 license. It's exactly the same image that newt tool builds and links when building Apache Mynewt for DA1469x.

This is an edge case then. You are still providing a precompiled library in binary form, so we need to at least discuss it in the TSC.

Understood. Do you want me to create an issue for binary blob anyway or you will discuss it first as it is now? I can also add some kind of readme to PR in hal_renesas with steps to rebuild that binary.

The reason why we want to provide that prebuilt binary is to make BLE work on DA1469x ootb, otherwise people will need to get complete Mynewt env just to create binary.

@carlescufi
Copy link
Member

Note that another vendor has done similar previously and it was submitted as a blob: #54534

But I am not sure that the source code for those Infineon libraries was available under an open source license actually, was it? @ifyall @npal-cy

@carlescufi
Copy link
Member

Understood. Do you want me to create an issue for binary blob anyway or you will discuss it first as it is now? I can also add some kind of readme to PR in hal_renesas with steps to rebuild that binary.

Let's create the issue for a binary blob @andrzej-kaczmarek, because precompiling an open source project is new. If you do this today we can include it in today's TSC.

The reason why we want to provide that prebuilt binary is to make BLE work on DA1469x ootb, otherwise people will need to get complete Mynewt env just to create binary.

I know this is not what you propose, but what about using the Zephyr LL instead?

@andrzej-kaczmarek
Copy link
Collaborator Author

Understood. Do you want me to create an issue for binary blob anyway or you will discuss it first as it is now? I can also add some kind of readme to PR in hal_renesas with steps to rebuild that binary.

Let's create the issue for a binary blob @andrzej-kaczmarek, because precompiling an open source project is new. If you do this today we can include it in today's TSC.

Done: #57987

The reason why we want to provide that prebuilt binary is to make BLE work on DA1469x ootb, otherwise people will need to get complete Mynewt env just to create binary.

I know this is not what you propose, but what about using the Zephyr LL instead?

Porting Zephyr LL to CMAC architecture would require lots of work so for now I'm afraid that's not an option.

@andrzej-kaczmarek andrzej-kaczmarek force-pushed the da1469x-cmac branch 2 times, most recently from be81dd7 to 1b0c0eb Compare May 23, 2023 20:36
Copy link

This pull request has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time.

@jhedberg
Copy link
Member

@andrzej-kaczmarek please fix the compliance check failures

.fifo = Z_FIFO_INITIALIZER(rx.fifo),
};

static inline void h4_get_type(void)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unless you've profiled the code and concluded that the compiler doesn't do an optimal job, please don't do these explicit inline declarations. Same goes for the other functions here (I won't comment on them separately).

drivers/bluetooth/hci/hci_da1469x.c Outdated Show resolved Hide resolved
Comment on lines 378 to 384
void cmac_read_req(void)
{
while (cmac_mbox_has_data()) {
process_rx();
}
}

void cmac_rng_req(void)
{
k_sem_give(&rng_sem);
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe add code comments explaining where the calls to these functions are coming from, since they're not in the main Zephyr tree.

Comment on lines 473 to 471
#ifdef CONFIG_BT_HCI_HOST
.close = bt_da1469x_close,
#endif
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not directly related to this PR, but it seems a bit arbitrary that close() would depend on the Zephyr host stack. The only other user of the HCI driver API right now. is HCI_RAW, which indeed doesn't use close(), but it seems wrong to me that the HCI driver API makes such assumptions about the higher level implementation that uses the API. I guess we can fix this once we move to a native Zephyr driver API.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@andrzej-kaczmarek could I get some comment here? Drivers shouldn't generally know or care who their user is (the normal bluetooth host stack or HCI_RAW). So I think it might be cleaner to just remove the #ifdefs from close().

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

tbh I added #ifdefs based on other driver (iirc ipm_stm32wb), so didn't really know if they were required. I'll just remove them.

Copy link
Member

@jhedberg jhedberg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A few more minor comments. Also, please pay attention to the work done in #72323. This driver will also need to be converted as part of that other PR (assuming this PR gets merged first).

Comment on lines 29 to 33
#define H4_NONE 0x00
#define H4_CMD 0x01
#define H4_ACL 0x02
#define H4_EVT 0x04
#define H4_ISO 0x05
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These are all available in include/zephyr/bluetooth/hci_types.h please use those defines instead.


ret = cmac_mbox_read(rx.hdr + bytes_read, rx.remaining);
if (unlikely(ret < 0)) {
LOG_ERR("Unable to read from UART (ret %d)", ret);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"UART" in the log message seems wrong, since you're not calling a UART API


err = cmac_mbox_read(buf, MIN(len, sizeof(buf)));
if (unlikely(err < 0)) {
LOG_ERR("Unable to read from UART (err %d)", err);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same here


read = cmac_mbox_read(net_buf_tail(rx.buf), rx.remaining);
if (unlikely(read < 0)) {
LOG_ERR("Failed to read UART (err %d)", read);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

and here

Pull changes required for CMAC driver.

Signed-off-by: Andrzej Kaczmarek <[email protected]>
@zephyrbot zephyrbot removed the DNM This PR should not be merged (Do Not Merge) label May 13, 2024
@andrzej-kaczmarek
Copy link
Collaborator Author

west.yml is now updated with proper hash for HAL

@jhedberg
Copy link
Member

@andrzej-kaczmarek the PR looks generally fine to me. I'd be willing to approve if it wasn't for the open question regarding the #ifdefs around close().

This adds HCI driver which enables communication with CMAC core on
Renesas SmartBond DA1469x series. The CMAC core is running an Apache
NimBLE controller binary and uses shared memory for communcation via
mailboxes.

Signed-off-by: Andrzej Kaczmarek <[email protected]>
Adds required defconfigs for BT on DA1469x DK.

Signed-off-by: Andrzej Kaczmarek <[email protected]>
@blauret
Copy link
Contributor

blauret commented May 16, 2024

@jhedberg, I think your last comment was addressed.

@nashif nashif merged commit dd395e7 into zephyrproject-rtos:main May 16, 2024
24 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

7 participants