With a new board.yml file and reorganizing their
Kconfig options.
Note: the nrf5340 variants remain as their own
targets, instead of being variants of the base ones
to avoid breakage in this commit
(while not having a massime commit)
Signed-off-by: Alberto Escolar Piedras <alberto.escolar.piedras@nordicsemi.no>
To un-block continuing of soc and board porting then move all socs and
boards which have not yet been ported to boards_legacy / soc_legacy
folders.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Signed-off-by: Jamie McCrae <jamie.mccrae@nordicsemi.no>
Add options to force MCUs to boot/not boot, overriding
of how they would behave otherwise, as well as an
option to print info about the MCUs present in the
platform.
Signed-off-by: Alberto Escolar Piedras <alberto.escolar.piedras@nordicsemi.no>
As we will now we having more nrf5*_bsim boards defined in this
same folder, the old folder names became missleading.
Signed-off-by: Alberto Escolar Piedras <alberto.escolar.piedras@nordicsemi.no>
To allow knowing for which MCU are the options,
prepend them with the MCU number.
The primary/preferred MCU will also keep an alias to the
old options (without the cpu<n>_ prefix)
Signed-off-by: Alberto Escolar Piedras <alberto.escolar.piedras@nordicsemi.no>
Convert the nrf52_bsim board, to use the native simulator
as its engine.
This means some of the functionality the board included
before is now handled by the native simulator, including
the overall program main and CPU/HW scheduling.
Note that this board remains separate from the native_sim
board, even if both use the native simulator.
Also update the nRF HW models component to a new version
which has been converted into an extension for the
native simulator.
After this change, it becames also possible to build
the nrf52_bsim with an embedded C library, and to
use with it the Zephyr POSIX API shim.
Signed-off-by: Alberto Escolar Piedras <alberto.escolar.piedras@nordicsemi.no>
Some users use this simulated board interactively
(even though it is not recomended).
In that case, they may want to perceive a relatively smooth
time flow.
By default the maximum resynchronization offset is set at
1 second.
When running with a simulation speed close to real time,
this results in the simulated board jerking and pausing in
time 1 second at a time when there is no radio activity.
With this new option, users can set a resynchronization
offset of, for ex., 10 ms, which would give the illusion
of time progressing smoothly.
Signed-off-by: Alberto Escolar Piedras <alberto.escolar.piedras@nordicsemi.no>
Some testcases may benefit from having options to synchronize
to the Phy either before running the test pre-initialization
and/or before booting the CPU.
Provide these options.
Background: Before synchronizing to the Phy devices execute
ahead asynchronously. This is not a problem in most cases,
as normally the only interaction between devices happens thru the
radio, and as soon as any radio interaction occurs, the devices
are step-locked by the Phy.
But some devices do share information in other ways between,
like for example using the backchannels. This may benefit
from using these options.
Signed-off-by: Alberto Escolar Piedras <alberto.escolar.piedras@nordicsemi.no>
In some simulated test cases, it can be usefull
to delay the boot of the CPU and the test initialization
for a while. Namely by the offset of the device
relative to other simulated devices.
We add the option to select so from command line.
By default the option is disabled so this change is
backwards compatible.
Signed-off-by: Alberto Escolar Piedras <alpi@oticon.com>
Reapply the part of 4b5cd92312
that added new functionality/fixed the actual issues described
in the original commit message withtout the further cleanup.
There was also some cross-commit content from
2b91ebe16e
as part of the cleanup in test_friendship.c which is also included.
+ added cleanup also to test_provision.c on request from Aleksandr.
Original commit msg:
-----------
Multiple bsim devices cannot store individual settings
with the existing settings backend for bsim.
Signed-off-by: Aleksandr Khromykh <aleksandr.khromykh@nordicsemi.no>
-----------
Signed-off-by: Alberto Escolar Piedras <alpi@oticon.com>
This reverts commit 4b5cd92312.
global_device_nbr is used by many bsim tests.
And many of those are now off tree in preparation of the LE-Audio
work. Removing this for cleanliness now is not nice on others.
=> Revert
Signed-off-by: Alberto Escolar Piedras <alpi@oticon.com>
Multiple bsim devices cannot store individual settings
with the existing settings backend for bsim.
Signed-off-by: Aleksandr Khromykh <aleksandr.khromykh@nordicsemi.no>
With this change, drivers or components can register on runtime
their own command line arguments.
What this change does is to use the dynamic command line arguments
API from BabbleSim's libUtil and provides a function for the
drivers to add their own.
Note that this change requires v1.3 of the HW models (which remove
a dependency on the board command line arguments structure)
Signed-off-by: Alberto Escolar Piedras <alpi@oticon.com>
This function can only be used when the arguments structure memory
layout starts as in bs_basic_dev_args_t.
This assumption is just too dangerous in this board as somebody
may change the structure in the future unaware of this weird
requirement.
=> Do not use this function but do what it does in place.
Signed-off-by: Alberto Escolar Piedras <alpi@oticon.com>
When the -nosim option is used the user may still want to set
either the simulation ID string (-s) or the device number (-d)
to control the tracing prefixes and/or dump folder, but may not
care to set both of them.
=> This change allows it, while the old behaviour is otherwise
maintained (setting both or none with -nosim)
Signed-off-by: Alberto Escolar Piedras <alpi@oticon.com>
Fixed a typo in the warning message printed when the user does not
pass any parameters (and therefore does not connect to a BabbleSim
Phy)
Signed-off-by: Alberto Escolar Piedras <alpi@oticon.com>
Added a new simulated board, which models the NRF52832 SOC.
Its main use is for workstation testing and simulation of
the BLE stack and any application which relies mostly on it.
It uses BabbleSim (http://Babblesim.github.io) for the radio
simulation.
And the NRF52 HW models hosted in that same GitHub organization:
https://github.com/BabbleSim/ext_NRF52_hw_models
For speed it uses the POSIX arch to (not) emulate the CPU.
It uses Vanilla Zephyr, with a couple of configuration differences:
* It uses (like other POSIX arch boards) the system libC
* It does not use the nrfx hosted by Zehpyr in ext/, but the one
provided by the HW models.
Otherwise it relies in the same drivers as the real NRF52 boards.
Signed-off-by: Alberto Escolar Piedras <alpi@oticon.com>
Alberto Escolar Piedras
Jamie McCrae
Alberto Escolar Piedras
Aleksandr Khromykh