summaryrefslogtreecommitdiffstats
path: root/bsp-howto/getentropy.rst
diff options
context:
space:
mode:
Diffstat (limited to 'bsp-howto/getentropy.rst')
-rw-r--r--bsp-howto/getentropy.rst4
1 files changed, 2 insertions, 2 deletions
diff --git a/bsp-howto/getentropy.rst b/bsp-howto/getentropy.rst
index 10303a3..840ba1e 100644
--- a/bsp-howto/getentropy.rst
+++ b/bsp-howto/getentropy.rst
@@ -31,10 +31,10 @@ that can only be reached with some extra hardware support. Some microcontrollers
integrate a true random number generator or something similar for cryptographic
applications. That is the preferred source of entropy for most BSPs. For example
the
-`atsam BSP uses the TRNG for its entropy source <https://git.rtems.org/rtems/tree/c/src/lib/libbsp/arm/atsam/startup/getentropy-trng.c>`_.
+`atsam BSP uses the TRNG for its entropy source <https://git.rtems.org/rtems/tree/bsps/arm/atsam/start/getentropy-trng.c>`_.
There is also a quite limited
-`default implementation based on the CPU counter <https://git.rtems.org/rtems/tree/c/src/lib/libbsp/shared/getentropy-cpucounter.c>`_.
+`default implementation based on the CPU counter <https://git.rtems.org/rtems/tree/bsps/shared/dev/getentropy/getentropy-cpucounter.c>`_.
Due to the fact that it is a time based source, the values provided by
:c:func:`getentropy` are quite predictable. This implementation is not
appropriate for any cryptographic applications but it is good enough for some