Clarify the difference between the buffer length and threshold Kconfig
options available in the nRF5 entropy driver.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
Improve the documentation of entropy_nrf5.c by adding a comment that
clarifies it's characteristics.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
Selecting a choice symbol is always a no-op, and the latest version of
Kconfiglib prints a warning. This commit removes all selects of choice
symbols, which might make the Kconfig files a bit clearer and gets rid
of the warnings.
This is just a dumb removal. I did not try to guess the intent of each
select.
Fixes#6849
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Remove unnecessary header inclusion in nordic's nrf5 random
driver which added a dependency to ext/hal/nordic.
Signed-off-by: Alberto Escolar Piedras <alpi@oticon.com>
After porting the rand driver to drivers/entropy, replace the usage of
the old, Buetooth-specific driver with the generic entropy one.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
Signed-off-by: Vinayak Kariappa Chettimada <vich@nordicsemi.no>
The rand driver present in the BLE Link Layer is able to provide
entropy for both threads and ISRs, and so it is more suited to be used
as a generic nRF5x entropy driver instead of the current one. This will
allow applications and the Link Layer to use the same driver without
duplicating it.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
Signed-off-by: Vinayak Kariappa Chettimada <vich@nordicsemi.no>
Use "select USE_STM32_LL_RNG" to select the needed STM32 LL files,
instead of editing ext/hal/st/stm32cube/CMakeLists.txt
Signed-off-by: Erwin Rol <erwin@erwinrol.com>
It appears the STM32F411XE doesn't support RNG so remove enabling it
from the SoC defconfig and flag an error if attempting to build the
driver on that SoC.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
In STM32 family, RNG IP is available only on F4 and L4 series.
Besides STM32F401 does not support is neither.
Get entropy driver available on STM32 devices supporting it and
generate a compilation issue on STM32 devices that do not own
the RNG IP.
Solves #5448
Signed-Off-By: Erwan Gouriou <erwan.gouriou@linaro.org>
On STM32L4 SoCs RNG is clocked by 48MHz domain.
Hence, besides clock activation, it requires 48M
domain to be enabled.
Tested on:
*nucleo_l476rg
*stm32l476g_disco
*disco_l475_iot1
Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org>
Introducing CMake is an important step in a larger effort to make
Zephyr easy to use for application developers working on different
platforms with different development environment needs.
Simplified, this change retains Kconfig as-is, and replaces all
Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild
offers is replaced by a set of CMake extentions. These extentions have
either provided simple one-to-one translations of KBuild features or
introduced new concepts that replace KBuild concepts.
This is a breaking change for existing test infrastructure and build
scripts that are maintained out-of-tree. But for FW itself, no porting
should be necessary.
For users that just want to continue their work with minimal
disruption the following should suffice:
Install CMake 3.8.2+
Port any out-of-tree Makefiles to CMake.
Learn the absolute minimum about the new command line interface:
$ cd samples/hello_world
$ mkdir build && cd build
$ cmake -DBOARD=nrf52_pca10040 ..
$ cd build
$ make
PR: zephyrproject-rtos#4692
docs: http://docs.zephyrproject.org/getting_started/getting_started.html
Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
Instead of every hardware number generator driver providing an
implementation of this function, use the random device API to
centralize the implementation of this function.
This is a very simplistic function that can be seen as a stepping stone
to refactor the random number generation in Zephyr.
Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
This should clear up some of the confusion with random number
generators and drivers that obtain entropy from the hardware. Also,
many hardware number generators have limited bandwidth, so it's natural
for their output to be only used for seeding a random number generator.
Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
