NRF54LM20 CRACEN SilexPK Header Include Issues

[ashlin4010]

On v3.2.3 and v3.3.0-preview3 we are having issues getting CRACEN to build without patching it.

There are a bunch of includes that use the wrong paths, pointing to files that have been moved.
Most of these have been fixed in v3.3.0-preview3, but there is at least one left.

/workspace/nrf/subsys/nrf_security/src/drivers/cracen/silexpk/target/hw/ba414/ec_curves.c:10:10: fatal error: ../../target/hw/ba414/regs_commands.h: No such file or directory
   10 | #include "../../target/hw/ba414/regs_commands.h"
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.

The correct line should just be `#include "regs_commands.h"`.

There is also an issue in "nrf/subsys/nrf_security/src/drivers/cracen/silexpk/silexpk.cmake". In this CMake file, it's adding "silexpk/target/baremetal_ba414e_with_ik" to the include path.
The problem with this is that in baremetal_ba414e_with_ik has a header file named "internal.h" (a very generic name). This is causing collisions with other software using the same name (wolfSSL in our case).

There is also "nrf_security/src/drivers/cracen/silexpk/src/blind.c", it brings in internal.h like this "#include "internal.h"", in this case, internal.h does not exist in the same directory.


How to fix
silexpk.cmake should not add files directly to the include list, replace "${CMAKE_CURRENT_LIST_DIR}/target/baremetal_ba414e_with_ik" with "${CMAKE_CURRENT_LIST_DIR}/target"
Also, all the files that use "internal.h" should be updated to "#include <baremetal_ba414e_with_ik/internal.h>".

This would bring it a little more inline with how sxsymcrypt has its internal.h (fixed in v3.3.0-preview3)

Question

What is the status of CRACEN code? It did/does not build in v3.2.3 and v3.3.0-preview3, is it meant to?

Environment
nrf54lm20A
v3.2.3 and v3.3.0-preview3

Files

I have added a patch file for clarity.
/cfs-file/__key/communityserver-discussions-components-files/4/cracen.patch

[Amanda Hsieh]

Hi, 

Could you elaborate on how you build? We just tested this on NCS v3.3.0-preview3-branch, and it builds fine using west. Guess you might do something different? Could you provide a simple project to help us reproduce the issue? In which release did it stop working? Could you try to delete the build folder manually to get a completely clean build?

Regards,
Amanda H.

[ashlin4010]

Sorry for the lack of info, I was quite busy at the time.

I have created a very minimal example of the issues and have included a patch file that resolves the issue.
The patch file is not to be considered as a proper fix, but it does help to highlight the problem.

Building and setup instructions are available in the README file.

Steps to reproduce are as follows (see README for specific commands, assumes you are on Linux):

1. Extract zip
2. Set workspace, west init etc
3. west build ... (will fail)
4. observe build errors
5. apply patch
6. west build (will succeed)

Environment
Board: nrf54lm20A & nrf54lm20B
SDK: v3.3.0-preview3
Toolchain: v3.2.1

Notes on preview3 & v3.2.3
Both versions have these issues; it's not a regression.
Preview 3 is actually an improvement, but still not 100% correct.

Source Files
/cfs-file/__key/communityserver-discussions-components-files/4/workspace_5F00_cracen.tar.gz

Thanks

[Amanda Hsieh]

Hi, 

The team did some testing, and there are no issues with these included in NCS. The problem here is that you are trying to use wolfssl, which is not really supported in NCS, and it does some weird header injecting. So the answer to your original question of: "What is the status of CRACEN code? It did/does not build in v3.2.3 and v3.3.0-preview3, is it meant to?" is that it works perfectly fine with NCS. The team has created a PR that makes your sample build here: https://github.com/nrfconnect/sdk-nrf/pull/27921, since it is a nice cleanup anyways, but you should use the PSA api when doing crypto in NCS. 

-Amanda H.

[ashlin4010]

Thank you for your work on this and the PR. It is appreciated.