xiaoxiang781216 commented on code in PR #20398:
URL: https://github.com/apache/nuttx/pull/20398#discussion_r4143556469
##########
arch/arm/src/nrf54l/CMakeLists.txt:
##########
@@ -59,4 +59,55 @@ if(CONFIG_PM)
list(APPEND SRCS nrf54l_pminitialize.c)
endif()
+if(CONFIG_NRF54L_SOFTDEVICE_CONTROLLER)
+ set(NRFXLIB_VER "3.4.1")
+ set(NRFXLIB_DIR "${NUTTX_CHIP_ABS_DIR}/sdk-nrfxlib")
Review Comment:
If the controller run on a separated core, NuttX just load the binary to ram
and release the remote core to run the code and talk with the firmware through
IPC, it's fine. But if the binary run on the same core with NuttX, NuttX
interact the blob with the function call, it's same as calling other vendor HAL
from the technical perspective.
I see your code call sdc_hci_cmd_xxx which doesn't implement in the same
patch, so I assume this code come from sdk-nrfxlib.
> Do you even know how binary blobs for radio controllers work? If we were
to abandon that approach, we might as well remove every radio controller from
upstream. Pre-compiled radio binaries are required for regulatory reasons. Even
if you write your open-source BLE controller (which now is impossible for this
project), you won't be able to certify it easily, binary blob is required for
this.
Why do we need consider the certification in open-source project? The
company which do the certification could switch to the specific binary required
chip vendor anyway.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
