nrf52_bsim: Use HW models from new west module

[aescolar]

Fetch HW models from a new west module.
And, remove all pre-west glue which was used to:

• fetch them in CI
• validate their vesion
• Modify the include path and link to them

Signed-off-by: Alberto Escolar Piedras [email protected]

New west module provisional placement:
https://github.com/aescolar/nrf52_HW_models

[mbolivar]

Seems fine, but I think that one cmake nit makes sense to clean up here.

[nashif]

if this fixes #20366, we should add a reference to the body.

With this change, do we still need the code in the docker image?

[aescolar]

With this change, do we still need the code in the docker image?

Yes, the code in the docker image (the simulator base components) are akin to cmake, and cannot be built by Zephyr's build system.

[nashif]

Yes, the code in the docker image (the simulator base components) are akin to cmake, and cannot be built by Zephyr's build system.

ok, do we have documentation or instructions somewhere for how someone can get babblesim installed on their system to be able to run sanitycheck the same way it is run in CI?

[aescolar]

ok, do we have documentation or instructions somewhere for how someone can get babblesim installed on their system to be able to run sanitycheck the same way it is run in CI?

Here:
https://docs.zephyrproject.org/latest/boards/posix/nrf52_bsim/doc/index.html#building-and-running
Though the exact sub-set of repos fetched when building the CI docker image is this manifest: https://github.com/BabbleSim/manifest/blob/master/zephyr_docker.xml

[nashif]

Here:
docs.zephyrproject.org/latest/boards/posix/nrf52_bsim/doc/index.html#building-and-running

This documentation would make more sense under doc/guides/test/ with reference to the board, can we move this and change it to explain how it would work with sanitycheck?

[aescolar]

This documentation would make more sense

We could. If the plan is just to document how it is today and leave it at that. I was thinking of maybe including the simulator in the SDK, in which case it could be transparent for users.

[aescolar]

Just cleaned up a bit more the run_ci.sh script as we do not need to re-trigger a (incremental) build of the simulator each time, because we do not fetch any component update for it.

diff --git a/scripts/ci/run_ci.sh b/scripts/ci/run_ci.sh
index 3f4080d107..8a3a85af17 100755
--- a/scripts/ci/run_ci.sh
+++ b/scripts/ci/run_ci.sh
@@ -115,14 +115,6 @@ function on_complete() {
        fi;
 }
 
-
-function build_btsim() {
-       pushd . ;
-       cd ${BSIM_OUT_PATH}
-       make everything -j 8 -s
-       popd ;
-}
-
 function run_bsim_bt_tests() {
        WORK_DIR=${ZEPHYR_BASE}/bsim_bt_out tests/bluetooth/bsim_bt/compile.sh
        RESULTS_FILE=${ZEPHYR_BASE}/${BSIM_BT_TEST_RESULTS_FILE} \
@@ -235,10 +227,7 @@ if [ -n "$MAIN_CI" ]; then
        $short_git_log
 
        if [ -n "${BSIM_OUT_PATH}" -a -d "${BSIM_OUT_PATH}" ]; then
-               echo "Build BT simulator tests"
-               # Build BT Simulator
-               build_btsim
-
+               echo "Build and run BT simulator tests"
                # Run BLE tests in simulator on the 1st CI instance:
                if [ "$MATRIX" = "1" ]; then
                        run_bsim_bt_tests

(and as a bonus we save ~50ms)

[aescolar]

Rebased due to run_ci.sh conflict (variables case change). No changes otherwise.