zephyr
/
nrf_hw_models
mirror of https://github.com/zephyrproject-rtos/nrf_hw_models.git
1
0
Fork 0
Code Issues Releases Wiki Activity
You cannot select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
master
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from 'd8f125e198'
${ noResults }
nrf_hw_models/Makefile

43 lines
1.1 KiB
Makefile
Raw Normal View History Unescape Escape

First commit Signed-off-by: Alberto Escolar Piedras <alpi@oticon.com>
5 years ago
# Copyright 2018 Oticon A/S
# SPDX-License-Identifier: Apache-2.0
BSIM_BASE_PATH?=$(abspath ../ )
include ${BSIM_BASE_PATH}/common/pre.make.inc
2G4_libPhyComv1_COMP_PATH?=$(abspath ${BSIM_COMPONENTS_PATH}/ext_2G4_libPhyComv1)
SRCS:=$(shell find src/ -name "*.c")
nrfx: Use actual nrfx instead of manually modified files Warning. This commit breaks backwards compatibility with Zephyr <= 2.4.0. With nrfx 2.3.0 it is possible to include the MDK files on non-ARM platforms. As the MDK has a depenency to cmsis core files, a simple mocked core_cm4.h has been provided. By defining NRF_DECLARE_ONLY and NRF_STATIC_INLINE to nothing, no functions are inlined. This ensures that it is possible to mock the peripherals. For a non-zephyr build, the application must provide the environment varianble NRFX_BASE. The user of the nRF MDK or nrfx must ensure that the peripheral pointers are redefined before they are used. This is done in nrfx_bsim_redef.h. Include this header after including nrf.h or similar. When using nrfx, this inclusion can be placed in nrfx_glue.h For non-zephyr builds, a nrfx_config and nrfx_glue is provided. Other builds should include nrfx_config_bsim.h and nrfx_glue_bsim.h in their config and glue files. The original implementation of the HAL APIs from the real nrfx is included in `nrf_hal_originals.c`. All these functions are labelled as weak, so they can be replaced as needed with new definition in `src/nrfx/hal/` This removes the need for duplicating code. Signed-off-by: Rubin Gerritsen <rubin.gerritsen@nordicsemi.no>
3 years ago
ifndef NRFX_BASE
$(error NRFX_BASE must be set to the nrfx checkout folder)
endif
First commit Signed-off-by: Alberto Escolar Piedras <alpi@oticon.com>
5 years ago
INCLUDES:=-I${libUtilv1_COMP_PATH}/src/ \
-I${libPhyComv1_COMP_PATH}/src/ \
-I${2G4_libPhyComv1_COMP_PATH}/src \
-I${libRandv2_COMP_PATH}/src/ \
nrfx: Use actual nrfx instead of manually modified files Warning. This commit breaks backwards compatibility with Zephyr <= 2.4.0. With nrfx 2.3.0 it is possible to include the MDK files on non-ARM platforms. As the MDK has a depenency to cmsis core files, a simple mocked core_cm4.h has been provided. By defining NRF_DECLARE_ONLY and NRF_STATIC_INLINE to nothing, no functions are inlined. This ensures that it is possible to mock the peripherals. For a non-zephyr build, the application must provide the environment varianble NRFX_BASE. The user of the nRF MDK or nrfx must ensure that the peripheral pointers are redefined before they are used. This is done in nrfx_bsim_redef.h. Include this header after including nrf.h or similar. When using nrfx, this inclusion can be placed in nrfx_glue.h For non-zephyr builds, a nrfx_config and nrfx_glue is provided. Other builds should include nrfx_config_bsim.h and nrfx_glue_bsim.h in their config and glue files. The original implementation of the HAL APIs from the real nrfx is included in `nrf_hal_originals.c`. All these functions are labelled as weak, so they can be replaced as needed with new definition in `src/nrfx/hal/` This removes the need for duplicating code. Signed-off-by: Rubin Gerritsen <rubin.gerritsen@nordicsemi.no>
3 years ago
-Isrc/nrfx/mdk_replacements \
nrfx: Added 1st version of drivers/nrf_common.h As one of its macros will probably be used by the new Zephyr clock driver, add a cut down version fo this header. Also make all HAL headers include it just like in the real nrfx HAL. Signed-off-by: Alberto Escolar Piedras <alpi@oticon.com>
4 years ago
-Isrc/HW_models/ \
nrfx: Use actual nrfx instead of manually modified files Warning. This commit breaks backwards compatibility with Zephyr <= 2.4.0. With nrfx 2.3.0 it is possible to include the MDK files on non-ARM platforms. As the MDK has a depenency to cmsis core files, a simple mocked core_cm4.h has been provided. By defining NRF_DECLARE_ONLY and NRF_STATIC_INLINE to nothing, no functions are inlined. This ensures that it is possible to mock the peripherals. For a non-zephyr build, the application must provide the environment varianble NRFX_BASE. The user of the nRF MDK or nrfx must ensure that the peripheral pointers are redefined before they are used. This is done in nrfx_bsim_redef.h. Include this header after including nrf.h or similar. When using nrfx, this inclusion can be placed in nrfx_glue.h For non-zephyr builds, a nrfx_config and nrfx_glue is provided. Other builds should include nrfx_config_bsim.h and nrfx_glue_bsim.h in their config and glue files. The original implementation of the HAL APIs from the real nrfx is included in `nrf_hal_originals.c`. All these functions are labelled as weak, so they can be replaced as needed with new definition in `src/nrfx/hal/` This removes the need for duplicating code. Signed-off-by: Rubin Gerritsen <rubin.gerritsen@nordicsemi.no>
3 years ago
-Isrc/nrfx_config \
-Isrc/nrfx/nrfx_replacements \
-I${NRFX_BASE} \
-I${NRFX_BASE}/mdk
Makefile: Allow adding a sufix to the library name As we have more customers & uses for the NRF HW models, some of them may require some particular versions. At the same time a user may want to have several of these dependants all using the same bsim installation. The only thing complicating this, was that this Makefile produces the same library from each version. With this new option, users can add a suffix to the library name, either as an enviroment option, or a make option. for ex: export NRF_HW_MODELS_LIB_SUFFIX=.v1 ; make NRF_HW_MODELS_LIB_SUFFIX=.v2 make make NRF_HW_MODELS_LIB_SUFFIX=.v3 With this change, a user may fetch several copies(versions) of this component in separate component/ folders and keep them all in parallel building each into a separate library version. By default nothing is changed. So this is fully backwards compatible Signed-off-by: Alberto Escolar Piedras <alpi@oticon.com>
2 years ago
NRF_HW_MODELS_LIB_SUFFIX?=
LIB_NAME:=libNRF52_hw_models.32${NRF_HW_MODELS_LIB_SUFFIX}
First commit Signed-off-by: Alberto Escolar Piedras <alpi@oticon.com>
5 years ago
A_LIBS:=
A_LIBS32:=
SO_LIBS:=
DEBUG:=-g
OPT:=
ARCH:=-m32
WARNINGS:=-Wall -pedantic
COVERAGE:=
CFLAGS:=${ARCH} ${DEBUG} ${OPT} ${WARNINGS} -MMD -MP -std=c11 \
nrfx: Use actual nrfx instead of manually modified files Warning. This commit breaks backwards compatibility with Zephyr <= 2.4.0. With nrfx 2.3.0 it is possible to include the MDK files on non-ARM platforms. As the MDK has a depenency to cmsis core files, a simple mocked core_cm4.h has been provided. By defining NRF_DECLARE_ONLY and NRF_STATIC_INLINE to nothing, no functions are inlined. This ensures that it is possible to mock the peripherals. For a non-zephyr build, the application must provide the environment varianble NRFX_BASE. The user of the nRF MDK or nrfx must ensure that the peripheral pointers are redefined before they are used. This is done in nrfx_bsim_redef.h. Include this header after including nrf.h or similar. When using nrfx, this inclusion can be placed in nrfx_glue.h For non-zephyr builds, a nrfx_config and nrfx_glue is provided. Other builds should include nrfx_config_bsim.h and nrfx_glue_bsim.h in their config and glue files. The original implementation of the HAL APIs from the real nrfx is included in `nrf_hal_originals.c`. All these functions are labelled as weak, so they can be replaced as needed with new definition in `src/nrfx/hal/` This removes the need for duplicating code. Signed-off-by: Rubin Gerritsen <rubin.gerritsen@nordicsemi.no>
3 years ago
${INCLUDES} -fdata-sections -ffunction-sections \
Model a nrf52833 instead of a nrf52832 Motivation for the change: The nrf52833 is for the purpose of these models practically the same as a 52832, but it includes the HEADER_MASK register in the AES_CCM module which is needed for proper encrypted BIS support. Changing the version of the HW we model can cause minor trouble for users, i.e. require them to change the configuration of their SW, but at this point is believed most users will desire sooner or later full BLE ISO support. Change: * Changed version we compile as from NRF52832_XXAA to NRF52833_XXAA * Number of interrupts increased to 47 (32 was too low even for 52832) * Updated all documentation references to point to 52833 docs * Updated description of missing features (no new 52833 features implemented so far) ****************************************************************** Expect backwards/forward compatibility changes from/to this commit ****************************************************************** Signed-off-by: Alberto Escolar Piedras <alberto.escolar.piedras@nordicsemi.no>
2 months ago
-DNRF52833_XXAA
First commit Signed-off-by: Alberto Escolar Piedras <alpi@oticon.com>
5 years ago
LDFLAGS:=${ARCH} ${COVERAGE}
CPPFLAGS:=
include ${BSIM_BASE_PATH}/common/make.lib_a.inc