Date   

NRF52: GPIOTE Static 400 µA

ismael fillonneau
 

To all Nordic team,

Is there a patch in the pipe to fix GPIOTE used in the same time as I2C interface?

cf nordic bug:

http://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.nrf52832.Rev2.errata%2Fdita%2Ferrata%2FnRF52832%2FRev2%2Flatest%2Fanomaly_832_89.html&cp=2_1_1_0_1_26

The pbm is that a lot of sensors are using I2C & interrupts(so GPIOTE) in the same time (ex: lsm6dsl, lis3mdl, hts221, lis2dh...) and NRF52 consumes 400uA statically.

Currently, nothing is done to desactivate I2C in the NRF52 but maybe someone has a PR coming soon.

Waiting your feedback.....


Regards,

Ismael Fillonneau


[RFC/RFT PATCH] Coccinelle: Add support for coccinelle infrastructure

Himanshu Jha <himanshujha199640@...>
 

'coccicheck' target is used to initiate Coccinelle tool
with four different modes:

* 'patch' proposes a fix, when possible.
* 'report' generates a list in the following format:
file:line:column-column: message
* 'context' highlights lines of interest and their context in a
diff-like style. Lines of interest are indicated with '-'.
* 'org' generates a report in the Org mode format of Emacs.

Cc: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: Himanshu Jha <himanshujha199640@gmail.com>
---
Makefile | 14 +
doc/scripts/coccinelle.rst | 503 ++++++++++++++++++++++++++
scripts/coccicheck | 206 +++++++++++
scripts/coccinelle/null/badzero.cocci | 238 ++++++++++++
scripts/ld-version.sh | 11 +
5 files changed, 972 insertions(+)
create mode 100644 doc/scripts/coccinelle.rst
create mode 100755 scripts/coccicheck
create mode 100644 scripts/coccinelle/null/badzero.cocci
create mode 100755 scripts/ld-version.sh

diff --git a/Makefile b/Makefile
index 88c6c2cda..f1479d18b 100644
--- a/Makefile
+++ b/Makefile
@@ -15,3 +15,17 @@ export Q
# ---------------------------------------------------------------------------
htmldocs:
$(Q)$(MAKE) -C doc htmldocs
+
+# SHELL used by kbuild
+CONFIG_SHELL := $(shell if [ -x "$$BASH" ]; then echo $$BASH; \
+ else if [ -x /bin/bash ]; then echo /bin/bash; \
+ else echo sh; fi ; fi)
+
+ifeq ("$(origin M)", "command line")
+ KBUILD_EXTMOD := $(M)
+endif
+
+export KBUILD_EXTMOD
+
+coccicheck:
+ $(Q)$(CONFIG_SHELL) $(ZEPHYR_BASE)/scripts/$@
diff --git a/doc/scripts/coccinelle.rst b/doc/scripts/coccinelle.rst
new file mode 100644
index 000000000..be2bba35b
--- /dev/null
+++ b/doc/scripts/coccinelle.rst
@@ -0,0 +1,503 @@
+.. Copyright 2010 Nicolas Palix <npalix@diku.dk>
+.. Copyright 2010 Julia Lawall <julia@diku.dk>
+.. Copyright 2010 Gilles Muller <Gilles.Muller@lip6.fr>
+
+.. highlight:: none
+
+Coccinelle
+==========
+
+Coccinelle is a tool for pattern matching and text transformation that has
+many uses in kernel development, including the application of complex,
+tree-wide patches and detection of problematic programming patterns.
+
+Getting Coccinelle
+-------------------
+
+The semantic patches included in the kernel use features and options
+which are provided by Coccinelle version 1.0.0-rc11 and above.
+Using earlier versions will fail as the option names used by
+the Coccinelle files and coccicheck have been updated.
+
+Coccinelle is available through the package manager
+of many distributions, e.g. :
+
+ - Debian
+ - Fedora
+ - Ubuntu
+ - OpenSUSE
+ - Arch Linux
+ - NetBSD
+ - FreeBSD
+
+Some distribution packages are obsolete and it is recommended
+to use the latest version released from the Coccinelle homepage at
+http://coccinelle.lip6.fr/
+
+Or from Github at:
+
+https://github.com/coccinelle/coccinelle
+
+Once you have it, run the following commands::
+
+ ./autogen
+ ./configure
+ make
+
+as a regular user, and install it with::
+
+ sudo make install
+
+More detailed installation instructions to build from source can be
+found at:
+
+https://github.com/coccinelle/coccinelle/blob/master/install.txt
+
+Supplemental documentation
+---------------------------
+
+For supplemental documentation refer to the wiki:
+
+https://bottest.wiki.kernel.org/coccicheck
+
+The wiki documentation always refers to the linux-next version of the script.
+
+For Semantic Patch Language(SmPL) grammar documentation refer to:
+
+http://coccinelle.lip6.fr/documentation.php
+
+Using Coccinelle on the Linux kernel
+------------------------------------
+
+A Coccinelle-specific target is defined in the top level
+Makefile. This target is named ``coccicheck`` and calls the ``coccicheck``
+front-end in the ``scripts`` directory.
+
+Four basic modes are defined: ``patch``, ``report``, ``context``, and
+``org``. The mode to use is specified by setting the MODE variable with
+``MODE=<mode>``.
+
+- ``patch`` proposes a fix, when possible.
+
+- ``report`` generates a list in the following format:
+ file:line:column-column: message
+
+- ``context`` highlights lines of interest and their context in a
+ diff-like style.Lines of interest are indicated with ``-``.
+
+- ``org`` generates a report in the Org mode format of Emacs.
+
+Note that not all semantic patches implement all modes. For easy use
+of Coccinelle, the default mode is "report".
+
+Two other modes provide some common combinations of these modes.
+
+- ``chain`` tries the previous modes in the order above until one succeeds.
+
+- ``rep+ctxt`` runs successively the report mode and the context mode.
+ It should be used with the C option (described later)
+ which checks the code on a file basis.
+
+Examples
+~~~~~~~~
+
+To make a report for every semantic patch, run the following command::
+
+ make coccicheck MODE=report
+
+To produce patches, run::
+
+ make coccicheck MODE=patch
+
+
+The coccicheck target applies every semantic patch available in the
+sub-directories of ``scripts/coccinelle`` to the entire Linux kernel.
+
+For each semantic patch, a commit message is proposed. It gives a
+description of the problem being checked by the semantic patch, and
+includes a reference to Coccinelle.
+
+As any static code analyzer, Coccinelle produces false
+positives. Thus, reports must be carefully checked, and patches
+reviewed.
+
+To enable verbose messages set the V= variable, for example::
+
+ make coccicheck MODE=report V=1
+
+Coccinelle parallelization
+---------------------------
+
+By default, coccicheck tries to run as parallel as possible. To change
+the parallelism, set the J= variable. For example, to run across 4 CPUs::
+
+ make coccicheck MODE=report J=4
+
+As of Coccinelle 1.0.2 Coccinelle uses Ocaml parmap for parallelization,
+if support for this is detected you will benefit from parmap parallelization.
+
+When parmap is enabled coccicheck will enable dynamic load balancing by using
+``--chunksize 1`` argument, this ensures we keep feeding threads with work
+one by one, so that we avoid the situation where most work gets done by only
+a few threads. With dynamic load balancing, if a thread finishes early we keep
+feeding it more work.
+
+When parmap is enabled, if an error occurs in Coccinelle, this error
+value is propagated back, the return value of the ``make coccicheck``
+captures this return value.
+
+Using Coccinelle with a single semantic patch
+---------------------------------------------
+
+The optional make variable COCCI can be used to check a single
+semantic patch. In that case, the variable must be initialized with
+the name of the semantic patch to apply.
+
+For instance::
+
+ make coccicheck COCCI=<my_SP.cocci> MODE=patch
+
+or::
+
+ make coccicheck COCCI=<my_SP.cocci> MODE=report
+
+
+Controlling Which Files are Processed by Coccinelle
+---------------------------------------------------
+
+By default the entire kernel source tree is checked.
+
+To apply Coccinelle to a specific directory, ``M=`` can be used.
+For example, to check drivers/net/wireless/ one may write::
+
+ make coccicheck M=drivers/net/wireless/
+
+To apply Coccinelle on a file basis, instead of a directory basis, the
+following command may be used::
+
+ make C=1 CHECK="scripts/coccicheck"
+
+To check only newly edited code, use the value 2 for the C flag, i.e.::
+
+ make C=2 CHECK="scripts/coccicheck"
+
+In these modes, which works on a file basis, there is no information
+about semantic patches displayed, and no commit message proposed.
+
+This runs every semantic patch in scripts/coccinelle by default. The
+COCCI variable may additionally be used to only apply a single
+semantic patch as shown in the previous section.
+
+The "report" mode is the default. You can select another one with the
+MODE variable explained above.
+
+Debugging Coccinelle SmPL patches
+---------------------------------
+
+Using coccicheck is best as it provides in the spatch command line
+include options matching the options used when we compile the kernel.
+You can learn what these options are by using V=1, you could then
+manually run Coccinelle with debug options added.
+
+Alternatively you can debug running Coccinelle against SmPL patches
+by asking for stderr to be redirected to stderr, by default stderr
+is redirected to /dev/null, if you'd like to capture stderr you
+can specify the ``DEBUG_FILE="file.txt"`` option to coccicheck. For
+instance::
+
+ rm -f cocci.err
+ make coccicheck COCCI=scripts/coccinelle/free/kfree.cocci MODE=report DEBUG_FILE=cocci.err
+ cat cocci.err
+
+You can use SPFLAGS to add debugging flags, for instance you may want to
+add both --profile --show-trying to SPFLAGS when debugging. For instance
+you may want to use::
+
+ rm -f err.log
+ export COCCI=scripts/coccinelle/misc/irqf_oneshot.cocci
+ make coccicheck DEBUG_FILE="err.log" MODE=report SPFLAGS="--profile --show-trying" M=./drivers/mfd/arizona-irq.c
+
+err.log will now have the profiling information, while stdout will
+provide some progress information as Coccinelle moves forward with
+work.
+
+DEBUG_FILE support is only supported when using coccinelle >= 1.0.2.
+
+.cocciconfig support
+--------------------
+
+Coccinelle supports reading .cocciconfig for default Coccinelle options that
+should be used every time spatch is spawned, the order of precedence for
+variables for .cocciconfig is as follows:
+
+- Your current user's home directory is processed first
+- Your directory from which spatch is called is processed next
+- The directory provided with the --dir option is processed last, if used
+
+Since coccicheck runs through make, it naturally runs from the kernel
+proper dir, as such the second rule above would be implied for picking up a
+.cocciconfig when using ``make coccicheck``.
+
+``make coccicheck`` also supports using M= targets. If you do not supply
+any M= target, it is assumed you want to target the entire kernel.
+The kernel coccicheck script has::
+
+ if [ "$KBUILD_EXTMOD" = "" ] ; then
+ OPTIONS="--dir $srctree $COCCIINCLUDE"
+ else
+ OPTIONS="--dir $KBUILD_EXTMOD $COCCIINCLUDE"
+ fi
+
+KBUILD_EXTMOD is set when an explicit target with M= is used. For both cases
+the spatch --dir argument is used, as such third rule applies when whether M=
+is used or not, and when M= is used the target directory can have its own
+.cocciconfig file. When M= is not passed as an argument to coccicheck the
+target directory is the same as the directory from where spatch was called.
+
+If not using the kernel's coccicheck target, keep the above precedence
+order logic of .cocciconfig reading. If using the kernel's coccicheck target,
+override any of the kernel's .coccicheck's settings using SPFLAGS.
+
+We help Coccinelle when used against Linux with a set of sensible defaults
+options for Linux with our own Linux .cocciconfig. This hints to coccinelle
+git can be used for ``git grep`` queries over coccigrep. A timeout of 200
+seconds should suffice for now.
+
+The options picked up by coccinelle when reading a .cocciconfig do not appear
+as arguments to spatch processes running on your system, to confirm what
+options will be used by Coccinelle run::
+
+ spatch --print-options-only
+
+You can override with your own preferred index option by using SPFLAGS. Take
+note that when there are conflicting options Coccinelle takes precedence for
+the last options passed. Using .cocciconfig is possible to use idutils, however
+given the order of precedence followed by Coccinelle, since the kernel now
+carries its own .cocciconfig, you will need to use SPFLAGS to use idutils if
+desired. See below section "Additional flags" for more details on how to use
+idutils.
+
+Additional flags
+----------------
+
+Additional flags can be passed to spatch through the SPFLAGS
+variable. This works as Coccinelle respects the last flags
+given to it when options are in conflict. ::
+
+ make SPFLAGS=--use-glimpse coccicheck
+
+Coccinelle supports idutils as well but requires coccinelle >= 1.0.6.
+When no ID file is specified coccinelle assumes your ID database file
+is in the file .id-utils.index on the top level of the kernel, coccinelle
+carries a script scripts/idutils_index.sh which creates the database with::
+
+ mkid -i C --output .id-utils.index
+
+If you have another database filename you can also just symlink with this
+name. ::
+
+ make SPFLAGS=--use-idutils coccicheck
+
+Alternatively you can specify the database filename explicitly, for
+instance::
+
+ make SPFLAGS="--use-idutils /full-path/to/ID" coccicheck
+
+See ``spatch --help`` to learn more about spatch options.
+
+Note that the ``--use-glimpse`` and ``--use-idutils`` options
+require external tools for indexing the code. None of them is
+thus active by default. However, by indexing the code with
+one of these tools, and according to the cocci file used,
+spatch could proceed the entire code base more quickly.
+
+SmPL patch specific options
+---------------------------
+
+SmPL patches can have their own requirements for options passed
+to Coccinelle. SmPL patch specific options can be provided by
+providing them at the top of the SmPL patch, for instance::
+
+ // Options: --no-includes --include-headers
+
+SmPL patch Coccinelle requirements
+----------------------------------
+
+As Coccinelle features get added some more advanced SmPL patches
+may require newer versions of Coccinelle. If an SmPL patch requires
+at least a version of Coccinelle, this can be specified as follows,
+as an example if requiring at least Coccinelle >= 1.0.5::
+
+ // Requires: 1.0.5
+
+Proposing new semantic patches
+-------------------------------
+
+New semantic patches can be proposed and submitted by kernel
+developers. For sake of clarity, they should be organized in the
+sub-directories of ``scripts/coccinelle/``.
+
+
+Detailed description of the ``report`` mode
+-------------------------------------------
+
+``report`` generates a list in the following format::
+
+ file:line:column-column: message
+
+Example
+~~~~~~~
+
+Running::
+
+ make coccicheck MODE=report COCCI=scripts/coccinelle/api/err_cast.cocci
+
+will execute the following part of the SmPL script::
+
+ <smpl>
+ @r depends on !context && !patch && (org || report)@
+ expression x;
+ position p;
+ @@
+
+ ERR_PTR@p(PTR_ERR(x))
+
+ @script:python depends on report@
+ p << r.p;
+ x << r.x;
+ @@
+
+ msg="ERR_CAST can be used with %s" % (x)
+ coccilib.report.print_report(p[0], msg)
+ </smpl>
+
+This SmPL excerpt generates entries on the standard output, as
+illustrated below::
+
+ /home/user/linux/crypto/ctr.c:188:9-16: ERR_CAST can be used with alg
+ /home/user/linux/crypto/authenc.c:619:9-16: ERR_CAST can be used with auth
+ /home/user/linux/crypto/xts.c:227:9-16: ERR_CAST can be used with alg
+
+
+Detailed description of the ``patch`` mode
+------------------------------------------
+
+When the ``patch`` mode is available, it proposes a fix for each problem
+identified.
+
+Example
+~~~~~~~
+
+Running::
+
+ make coccicheck MODE=patch COCCI=scripts/coccinelle/api/err_cast.cocci
+
+will execute the following part of the SmPL script::
+
+ <smpl>
+ @ depends on !context && patch && !org && !report @
+ expression x;
+ @@
+
+ - ERR_PTR(PTR_ERR(x))
+ + ERR_CAST(x)
+ </smpl>
+
+This SmPL excerpt generates patch hunks on the standard output, as
+illustrated below::
+
+ diff -u -p a/crypto/ctr.c b/crypto/ctr.c
+ --- a/crypto/ctr.c 2010-05-26 10:49:38.000000000 +0200
+ +++ b/crypto/ctr.c 2010-06-03 23:44:49.000000000 +0200
+ @@ -185,7 +185,7 @@ static struct crypto_instance *crypto_ct
+ alg = crypto_attr_alg(tb[1], CRYPTO_ALG_TYPE_CIPHER,
+ CRYPTO_ALG_TYPE_MASK);
+ if (IS_ERR(alg))
+ - return ERR_PTR(PTR_ERR(alg));
+ + return ERR_CAST(alg);
+
+ /* Block size must be >= 4 bytes. */
+ err = -EINVAL;
+
+Detailed description of the ``context`` mode
+--------------------------------------------
+
+``context`` highlights lines of interest and their context
+in a diff-like style.
+
+ **NOTE**: The diff-like output generated is NOT an applicable patch. The
+ intent of the ``context`` mode is to highlight the important lines
+ (annotated with minus, ``-``) and gives some surrounding context
+ lines around. This output can be used with the diff mode of
+ Emacs to review the code.
+
+Example
+~~~~~~~
+
+Running::
+
+ make coccicheck MODE=context COCCI=scripts/coccinelle/api/err_cast.cocci
+
+will execute the following part of the SmPL script::
+
+ <smpl>
+ @ depends on context && !patch && !org && !report@
+ expression x;
+ @@
+
+ * ERR_PTR(PTR_ERR(x))
+ </smpl>
+
+This SmPL excerpt generates diff hunks on the standard output, as
+illustrated below::
+
+ diff -u -p /home/user/linux/crypto/ctr.c /tmp/nothing
+ --- /home/user/linux/crypto/ctr.c 2010-05-26 10:49:38.000000000 +0200
+ +++ /tmp/nothing
+ @@ -185,7 +185,6 @@ static struct crypto_instance *crypto_ct
+ alg = crypto_attr_alg(tb[1], CRYPTO_ALG_TYPE_CIPHER,
+ CRYPTO_ALG_TYPE_MASK);
+ if (IS_ERR(alg))
+ - return ERR_PTR(PTR_ERR(alg));
+
+ /* Block size must be >= 4 bytes. */
+ err = -EINVAL;
+
+Detailed description of the ``org`` mode
+----------------------------------------
+
+``org`` generates a report in the Org mode format of Emacs.
+
+Example
+~~~~~~~
+
+Running::
+
+ make coccicheck MODE=org COCCI=scripts/coccinelle/api/err_cast.cocci
+
+will execute the following part of the SmPL script::
+
+ <smpl>
+ @r depends on !context && !patch && (org || report)@
+ expression x;
+ position p;
+ @@
+
+ ERR_PTR@p(PTR_ERR(x))
+
+ @script:python depends on org@
+ p << r.p;
+ x << r.x;
+ @@
+
+ msg="ERR_CAST can be used with %s" % (x)
+ msg_safe=msg.replace("[","@(").replace("]",")")
+ coccilib.org.print_todo(p[0], msg_safe)
+ </smpl>
+
+This SmPL excerpt generates Org entries on the standard output, as
+illustrated below::
+
+ * TODO [[view:/home/user/linux/crypto/ctr.c::face=ovl-face1::linb=188::colb=9::cole=16][ERR_CAST can be used with alg]]
+ * TODO [[view:/home/user/linux/crypto/authenc.c::face=ovl-face1::linb=619::colb=9::cole=16][ERR_CAST can be used with auth]]
+ * TODO [[view:/home/user/linux/crypto/xts.c::face=ovl-face1::linb=227::colb=9::cole=16][ERR_CAST can be used with alg]]
diff --git a/scripts/coccicheck b/scripts/coccicheck
new file mode 100755
index 000000000..081a0bf06
--- /dev/null
+++ b/scripts/coccicheck
@@ -0,0 +1,206 @@
+#!/bin/bash
+# SPDX-License-Identifier: GPL-2.0
+# Linux kernel coccicheck
+#
+# Read Documentation/dev-tools/coccinelle.rst
+#
+# This script requires at least spatch
+# version 1.0.0-rc11.
+
+DIR="$(dirname $(readlink -f $0))/.."
+SPATCH="`which ${SPATCH:=spatch}`"
+
+if [ ! -x "$SPATCH" ]; then
+ echo 'spatch is part of the Coccinelle project and is available at http://coccinelle.lip6.fr/'
+ exit 1
+fi
+
+SPATCH_VERSION=$($SPATCH --version | head -1 | awk '{print $3}')
+SPATCH_VERSION_NUM=$(echo $SPATCH_VERSION | ${DIR}/scripts/ld-version.sh)
+
+# The verbosity may be set by the environmental parameter V=
+# as for example with 'make V=1 coccicheck'
+
+if [ -n "$V" -a "$V" != "0" ]; then
+ VERBOSE="$V"
+else
+ VERBOSE=0
+fi
+
+FLAGS="--very-quiet"
+
+# You can use SPFLAGS to append extra arguments to coccicheck or override any
+# heuristics done in this file as Coccinelle accepts the last options when
+# options conflict.
+#
+# A good example for use of SPFLAGS is if you want to debug your cocci script,
+# you can for instance use the following:
+#
+# $ export COCCI=scripts/coccinelle/misc/irqf_oneshot.cocci
+# $ make coccicheck MODE=report DEBUG_FILE="all.err" SPFLAGS="--profile --show-trying" M=./drivers/mfd/arizona-irq.c
+#
+# "--show-trying" should show you what rule is being processed as it goes to
+# stdout, you do not need a debug file for that. The profile output will be
+# be sent to stdout, if you provide a DEBUG_FILE the profiling data can be
+# inspected there.
+#
+# --profile will not output if --very-quiet is used, so avoid it.
+echo $SPFLAGS | egrep -e "--profile|--show-trying" 2>&1 > /dev/null
+if [ $? -eq 0 ]; then
+ FLAGS="--quiet"
+fi
+
+# spatch only allows include directories with the syntax "-I include"
+# while gcc also allows "-Iinclude" and "-include include"
+COCCIINCLUDE=${LINUXINCLUDE//-I/-I }
+COCCIINCLUDE=${COCCIINCLUDE// -include/ --include}
+
+if [ "$KBUILD_EXTMOD" = "" ] ; then
+ OPTIONS="--dir $ZEPHYR_BASE $COCCIINCLUDE"
+else
+ OPTIONS="--dir $KBUILD_EXTMOD $COCCIINCLUDE"
+fi
+
+if [ -z "$J" ]; then
+ NPROC=$(getconf _NPROCESSORS_ONLN)
+else
+ NPROC="$J"
+fi
+
+if [ "$KBUILD_EXTMOD" != "" ] ; then
+ OPTIONS="--patch $ZEPHYR_BASE $OPTIONS"
+fi
+
+# You can override by using SPFLAGS
+if [ "$NPROC" != "1" ]; then
+ # Using 0 should work as well, refer to _SC_NPROCESSORS_ONLN use on
+ # https://github.com/rdicosmo/parmap/blob/master/setcore_stubs.c
+ OPTIONS="$OPTIONS --jobs $NPROC --chunksize 1"
+fi
+
+if [ "$MODE" = "" ] ; then
+ echo 'You have not explicitly specified the mode to use. Using default "report" mode.'
+ echo 'Available modes are the following: patch, report, context, org'
+ echo 'You can specify the mode with "make coccicheck MODE=<mode>"'
+ echo 'Note however that some modes are not implemented by some semantic patches.'
+ MODE="report"
+fi
+
+if [ "$MODE" = "chain" ] ; then
+ echo 'You have selected the "chain" mode.'
+ echo 'All available modes will be tried (in that order): patch, report, context, org'
+elif [ "$MODE" = "report" -o "$MODE" = "org" ] ; then
+ FLAGS="--no-show-diff $FLAGS"
+fi
+
+ echo ''
+ echo 'Please check for false positives in the output before submitting a patch.'
+ echo 'When using "patch" mode, carefully review the patch before submitting it.'
+ echo ''
+
+run_cmd_parmap() {
+ if [ $VERBOSE -ne 0 ] ; then
+ echo "Running ($NPROC in parallel): $@"
+ fi
+ echo $@ >>$DEBUG_FILE
+ $@ 2>>$DEBUG_FILE
+ err=$?
+ if [[ $err -ne 0 ]]; then
+ echo "coccicheck failed"
+ exit $err
+ fi
+}
+
+# You can override heuristics with SPFLAGS, these must always go last
+OPTIONS="$OPTIONS $SPFLAGS"
+
+coccinelle () {
+ COCCI="$1"
+
+ OPT=`grep "Options:" $COCCI | cut -d':' -f2`
+ REQ=`grep "Requires:" $COCCI | cut -d':' -f2 | sed "s| ||"`
+ REQ_NUM=$(echo $REQ | ${DIR}/scripts/ld-version.sh)
+ if [ "$REQ_NUM" != "0" ] ; then
+ if [ "$SPATCH_VERSION_NUM" -lt "$REQ_NUM" ] ; then
+ echo "Skipping coccinelle SmPL patch: $COCCI"
+ echo "You have coccinelle: $SPATCH_VERSION"
+ echo "This SmPL patch requires: $REQ"
+ return
+ fi
+ fi
+
+# The option '--parse-cocci' can be used to syntactically check the SmPL files.
+#
+# $SPATCH -D $MODE $FLAGS -parse_cocci $COCCI $OPT > /dev/null
+
+ if [ $VERBOSE -ne 0 ] ; then
+
+ FILE=${COCCI#$ZEPHYR_BASE/}
+
+ echo "Processing `basename $COCCI`"
+ echo "with option(s) \"$OPT\""
+ echo ''
+ echo 'Message example to submit a patch:'
+
+ sed -ne 's|^///||p' $COCCI
+
+ if [ "$MODE" = "patch" ] ; then
+ echo ' The semantic patch that makes this change is available'
+ elif [ "$MODE" = "report" ] ; then
+ echo ' The semantic patch that makes this report is available'
+ elif [ "$MODE" = "context" ] ; then
+ echo ' The semantic patch that spots this code is available'
+ elif [ "$MODE" = "org" ] ; then
+ echo ' The semantic patch that makes this Org report is available'
+ else
+ echo ' The semantic patch that makes this output is available'
+ fi
+ echo " in $FILE."
+ echo ''
+ echo ' More information about semantic patching is available at'
+ echo ' http://coccinelle.lip6.fr/'
+ echo ''
+
+ if [ "`sed -ne 's|^//#||p' $COCCI`" ] ; then
+ echo 'Semantic patch information:'
+ sed -ne 's|^//#||p' $COCCI
+ echo ''
+ fi
+ fi
+
+ if [ "$MODE" = "chain" ] ; then
+ run_cmd_parmap $SPATCH -D patch \
+ $FLAGS --cocci-file $COCCI $OPT $OPTIONS || \
+ run_cmd_parmap $SPATCH -D report \
+ $FLAGS --cocci-file $COCCI $OPT $OPTIONS --no-show-diff || \
+ run_cmd_parmap $SPATCH -D context \
+ $FLAGS --cocci-file $COCCI $OPT $OPTIONS || \
+ run_cmd_parmap $SPATCH -D org \
+ $FLAGS --cocci-file $COCCI $OPT $OPTIONS --no-show-diff || exit 1
+ elif [ "$MODE" = "rep+ctxt" ] ; then
+ run_cmd_parmap $SPATCH -D report \
+ $FLAGS --cocci-file $COCCI $OPT $OPTIONS --no-show-diff && \
+ run_cmd_parmap $SPATCH -D context \
+ $FLAGS --cocci-file $COCCI $OPT $OPTIONS || exit 1
+ else
+ run_cmd_parmap $SPATCH -D $MODE $FLAGS --cocci-file $COCCI $OPT $OPTIONS || exit 1
+ fi
+
+}
+
+if [ "$DEBUG_FILE" != "/dev/null" -a "$DEBUG_FILE" != "" ]; then
+ if [ -f $DEBUG_FILE ]; then
+ echo "Debug file $DEBUG_FILE exists, bailing"
+ exit
+ fi
+else
+ DEBUG_FILE="/dev/null"
+fi
+
+if [ "$COCCI" = "" ] ; then
+ for f in `find $ZEPHYR_BASE/scripts/coccinelle/ -name '*.cocci' -type f | sort`; do
+ coccinelle $f
+ done
+else
+ coccinelle $COCCI
+fi
diff --git a/scripts/coccinelle/null/badzero.cocci b/scripts/coccinelle/null/badzero.cocci
new file mode 100644
index 000000000..f597c8007
--- /dev/null
+++ b/scripts/coccinelle/null/badzero.cocci
@@ -0,0 +1,238 @@
+/// Compare pointer-typed values to NULL rather than 0
+///
+//# This makes an effort to choose between !x and x == NULL. !x is used
+//# if it has previously been used with the function used to initialize x.
+//# This relies on type information. More type information can be obtained
+//# using the option -all_includes and the option -I to specify an
+//# include path.
+//
+// Confidence: High
+// Copyright: (C) 2012 Julia Lawall, INRIA/LIP6. GPLv2.
+// Copyright: (C) 2012 Gilles Muller, INRIA/LiP6. GPLv2.
+// URL: http://coccinelle.lip6.fr/
+// Requires: 1.0.0
+// Options:
+
+virtual patch
+virtual context
+virtual org
+virtual report
+
+@initialize:ocaml@
+@@
+let negtable = Hashtbl.create 101
+
+@depends on patch@
+expression *E;
+identifier f;
+@@
+
+(
+ (E = f(...)) ==
+- 0
++ NULL
+|
+ (E = f(...)) !=
+- 0
++ NULL
+|
+- 0
++ NULL
+ == (E = f(...))
+|
+- 0
++ NULL
+ != (E = f(...))
+)
+
+
+@t1 depends on !patch@
+expression *E;
+identifier f;
+position p;
+@@
+
+(
+ (E = f(...)) ==
+* 0@p
+|
+ (E = f(...)) !=
+* 0@p
+|
+* 0@p
+ == (E = f(...))
+|
+* 0@p
+ != (E = f(...))
+)
+
+@script:python depends on org@
+p << t1.p;
+@@
+
+coccilib.org.print_todo(p[0], "WARNING comparing pointer to 0")
+
+@script:python depends on report@
+p << t1.p;
+@@
+
+coccilib.report.print_report(p[0], "WARNING comparing pointer to 0")
+
+// Tests of returned values
+
+@s@
+identifier f;
+expression E,E1;
+@@
+
+ E = f(...)
+ ... when != E = E1
+ !E
+
+@script:ocaml depends on s@
+f << s.f;
+@@
+
+try let _ = Hashtbl.find negtable f in ()
+with Not_found -> Hashtbl.add negtable f ()
+
+@ r disable is_zero,isnt_zero exists @
+expression *E;
+identifier f;
+@@
+
+E = f(...)
+...
+(E == 0
+|E != 0
+|0 == E
+|0 != E
+)
+
+@script:ocaml@
+f << r.f;
+@@
+
+try let _ = Hashtbl.find negtable f in ()
+with Not_found -> include_match false
+
+// This rule may lead to inconsistent path problems, if E is defined in two
+// places
+@ depends on patch disable is_zero,isnt_zero @
+expression *E;
+expression E1;
+identifier r.f;
+@@
+
+E = f(...)
+<...
+(
+- E == 0
++ !E
+|
+- E != 0
++ E
+|
+- 0 == E
++ !E
+|
+- 0 != E
++ E
+)
+...>
+?E = E1
+
+@t2 depends on !patch disable is_zero,isnt_zero @
+expression *E;
+expression E1;
+identifier r.f;
+position p1;
+position p2;
+@@
+
+E = f(...)
+<...
+(
+* E == 0@p1
+|
+* E != 0@p2
+|
+* 0@p1 == E
+|
+* 0@p1 != E
+)
+...>
+?E = E1
+
+@script:python depends on org@
+p << t2.p1;
+@@
+
+coccilib.org.print_todo(p[0], "WARNING comparing pointer to 0, suggest !E")
+
+@script:python depends on org@
+p << t2.p2;
+@@
+
+coccilib.org.print_todo(p[0], "WARNING comparing pointer to 0")
+
+@script:python depends on report@
+p << t2.p1;
+@@
+
+coccilib.report.print_report(p[0], "WARNING comparing pointer to 0, suggest !E")
+
+@script:python depends on report@
+p << t2.p2;
+@@
+
+coccilib.report.print_report(p[0], "WARNING comparing pointer to 0")
+
+@ depends on patch disable is_zero,isnt_zero @
+expression *E;
+@@
+
+(
+ E ==
+- 0
++ NULL
+|
+ E !=
+- 0
++ NULL
+|
+- 0
++ NULL
+ == E
+|
+- 0
++ NULL
+ != E
+)
+
+@ t3 depends on !patch disable is_zero,isnt_zero @
+expression *E;
+position p;
+@@
+
+(
+* E == 0@p
+|
+* E != 0@p
+|
+* 0@p == E
+|
+* 0@p != E
+)
+
+@script:python depends on org@
+p << t3.p;
+@@
+
+coccilib.org.print_todo(p[0], "WARNING comparing pointer to 0")
+
+@script:python depends on report@
+p << t3.p;
+@@
+
+coccilib.report.print_report(p[0], "WARNING comparing pointer to 0")
diff --git a/scripts/ld-version.sh b/scripts/ld-version.sh
new file mode 100755
index 000000000..f2be0ff9a
--- /dev/null
+++ b/scripts/ld-version.sh
@@ -0,0 +1,11 @@
+#!/usr/bin/awk -f
+# SPDX-License-Identifier: GPL-2.0
+# extract linker version number from stdin and turn into single number
+ {
+ gsub(".*\\)", "");
+ gsub(".*version ", "");
+ gsub("-.*", "");
+ split($1,a, ".");
+ print a[1]*100000000 + a[2]*1000000 + a[3]*10000;
+ exit
+ }
--
2.17.1


Re: 回复:[Zephyr-devel] hciconfig tools error with nrf52832 running zephyr

Serafin
 

Hi


Well it should not be a big deal to compile a more modern Linux Kernel for i.mx6. Most things are mainline. 4.1 is EOL anyway.


Best regards

Serafin


On 27/08/18 18:16, sxzxchen@... wrote:
imx6ull,with linux kernel version 4.15

发自我的华为手机


-------- 原始邮件 --------
主题:Re: [Zephyr-devel] hciconfig tools error with nrf52832 running zephyr
发件人:Maureen Helm
收件人:sxzxchen@...,Johan Hedberg
抄送:devel@...


Which NXP device are you running embedded Linux? I can check to see if we have plans to update the kernel version.

 

From: devel@... <devel@...> On Behalf Of sxzxchen@...
Sent: Monday, August 27, 2018 7:28 AM
To: Johan Hedberg <johan.hedberg@...>
Cc: devel@...
Subject: Re: [Zephyr-devel] hciconfig tools error with nrf52832 running zephyr

 

Thanks for your explanation.since the embedded linux version is bound  with the chip, I cannot update it easily.So is there any ways to solve this problem without updating linux version ?  




 


At 2018-08-24 13:24:28, "Johan Hedberg" <johan.hedberg@...> wrote:
>Hi,
>On Thu, Aug 23, 2018, sxzxchen@... wrote:
>> I bought a official nrf52832 development kits and ported zephyr
>> project successfully. It runs fine with my ubuntu host,via btattach
>> and btmgmt tools.But it didn't work with my nxp embedded linux,the
>> linux version is 4.1.15 and supports hciattach hciconfig tools
>> only.When I tried to bring the bluetooth module up with hciconfig hci0
>> up,an error comes up:
>The 4.1 kernel is too old to support controllers without a public
>address. IIRC you need at least a 4.4 kernel, but ideally something much
>newer than that.
>Johan

 

 



Re: NRF52 : use of NFFS file system

Carles Cufi
 

Hi Laurence,

 

I am copying a couple of people that might be able to help with NFFS config.

 

Carles

 

From: users@... <users@...> On Behalf Of Laurence Pasteau
Sent: 27 August 2018 10:06
To: users@...; devel@...
Subject: [Zephyr-users] NRF52 : use of NFFS file system

 

Hi everybody,

 

I worked on a board including a NRF52 and use the file system with NFFS but I never succeed in using it correctly.

 

I have a lot of errors depending on the configuration parameters that I set.

I reduce my problem to a little test that only writes in a loop 12 bytes in a single file. It fails very quickly.

Sometimes the operation seems good when checking the return value. However the file became a file of size null and a new file with another name appears with the previous file. Then some loops later, there is an error in a return value of the write function.

 

I tried to modify NFFS configuration.

In the two cases when  the CONFIG_NFFS_FILESYSTEM_MAX_BLOCK_SIZE is higher and when the global size of the file system is higher ; the test is good during a longer time before failing.

If I write 24 instead of 12 bytes or if I write in two files instead of one, the issue comes sooner.

 

I think something in my configuration (or in my software) is wrong. If someone can help me it would be very helpful.

 

Attached is the little test and the conf file. To reduce the time before failing, I change the file system size to 0x2000.

 

 

Here is my configuration (I don't use MCU_BOOT) :

 

In the dts file :

    partitions {
        compatible = "fixed-partitions";
        #address-cells = <1>;
        #size-cells = <1>;

        boot_partition: partition@0 {
            label = "mcuboot";
            reg = <0x00000000 0xc000>;
        };
        slot0_partition: partition@c000 {
            label = "image-0";
            reg = <0x0000C000 0x32000>;
        };
        slot1_partition: partition@3e000 {
            label = "image-1";
            reg = <0x0003E000 0x32000>;
        };
        scratch_partition: partition@70000 {
            label = "image-scratch";
            reg = <0x00070000 0xa000>;
        };

#if defined(CONFIG_FS_FLASH_STORAGE_PARTITION)
        storage_partition: partition@7a000 {
            label = "storage";
            reg = <0x0007a000 0x00002000>;
        };
#endif
    };

 

In the conf file :

CONFIG_SOC_FLASH_NRF=y
CONFIG_FS_NFFS_NUM_BLOCKS=1024
CONFIG_FS_NFFS_NUM_INODES=1024
CONFIG_FS_NFFS_NUM_CACHE_BLOCKS=1
CONFIG_FS_NFFS_NUM_CACHE_INODES=1
CONFIG_FS_NFFS_NUM_DIRS=4
CONFIG_FS_NFFS_NUM_FILES=4
CONFIG_FS_NFFS_NUM_INODES=64
CONFIG_HEAP_MEM_POOL_SIZE=4096
CONFIG_MAIN_STACK_SIZE=4096
CONFIG_NFFS_FILESYSTEM_MAX_AREAS=12
CONFIG_NFFS_FILESYSTEM_MAX_BLOCK_SIZE=128
CONFIG_FS_FLASH_STORAGE_PARTITION=y
CONFIG_SOC_FLASH_NRF_RADIO_SYNC=y

 

 

In the CMakeLists.txt :

set(BOARD nrf52_pca10040)

target_include_directories(app PRIVATE $ENV{ZEPHYR_BASE}/ext/fs/nffs/include)
target_link_libraries(app NFFS)

 

 

Thanks in advance for any help.

 

Regards,

Laurence

 

 

 

 


Re: Error compiling sample Hello World

Carles Cufi
 

Hi there,

 

Sounds like there’s an issue with DTC and a 32-bit host. While we do support a 32-bit version of it, I’ve never tested it myself since I don’t have access to a 32-bit Windows installation.

Did you install dtc using Chocolatey?

Could you try perhaps running dtc manually? Open a command prompt and then:

 

C:\Users\Carles>dtc --version

Version: DTC 1.4.4-ga81d4ca0-dirty

 

Thanks,

 

Carles

 

From: devel@... <devel@...> On Behalf Of IosuGorostiza
Sent: 28 August 2018 14:30
To: devel@...
Subject: [Zephyr-devel] Error compiling sample Hello World

 

Hi everybody:
I´m trying to compile the example hello_world as described in the Getting Started Guide. I follow every step of the guide but I´m not able to compile. I deleted everything and start again from the beggining several times and always get the same error. The steps I followed was for ARM.
I´m using the board nrf52_pca10040 in a PC with Windows 8.1 Enterprise 32bits.
Next, I paste what I obtained after executing the compiling instruction:

C:\Users\balcalde\zephyr\samples\hello_world\build>cmake -GNinja -DBOARD=nrf52_pca10040 ..

-- Found PythonInterp: C:/Python37/python.exe (found suitable version "3.7", minimum required is "3.4")

-- Selected BOARD nrf52_pca10040

Zephyr version: 1.13.0

Parsing Kconfig tree in C:/Users/balcalde/zephyr//Kconfig

Using C:/Users/balcalde/zephyr/boards/arm/nrf52_pca10040/nrf52_pca10040_defconfig as base

Merging C:/Users/balcalde/zephyr/samples/hello_world/prj.conf

-- Generating zephyr/include/generated/generated_dts_board.h

CMake Error at C:/Users/balcalde/zephyr/cmake/dts.cmake:84 (message):command failed with return code: Exit code 0xc0000135

 

Call Stack (most recent call first):

  C:/Users/balcalde/zephyr/cmake/app/boilerplate.cmake:278 (include)

  CMakeLists.txt:3 (include)

-- Configuring incomplete, errors occurred!

I spent many hours searching trough the web and reading zephyr documentation but I didn´t found anything that help me to solve that error.

I apprecite any help.
Thanks, best regards

 

 



 

 


Error compiling sample Hello World

IosuGorostiza <balcalde@...>
 

Hi everybody:
I´m trying to compile the example hello_world as described in the Getting Started Guide. I follow every step of the guide but I´m not able to compile. I deleted everything and start again from the beggining several times and always get the same error. The steps I followed was for ARM.
I´m using the board nrf52_pca10040 in a PC with Windows 8.1 Enterprise 32bits.
Next, I paste what I obtained after executing the compiling instruction:

C:\Users\balcalde\zephyr\samples\hello_world\build>cmake -GNinja -DBOARD=nrf52_pca10040 ..
-- Found PythonInterp: C:/Python37/python.exe (found suitable version "3.7", minimum required is "3.4")
-- Selected BOARD nrf52_pca10040
Zephyr version: 1.13.0
Parsing Kconfig tree in C:/Users/balcalde/zephyr//Kconfig
Using C:/Users/balcalde/zephyr/boards/arm/nrf52_pca10040/nrf52_pca10040_defconfig as base
Merging C:/Users/balcalde/zephyr/samples/hello_world/prj.conf
-- Generating zephyr/include/generated/generated_dts_board.h
CMake Error at C:/Users/balcalde/zephyr/cmake/dts.cmake:84 (message):command failed with return code: Exit code 0xc0000135
 
Call Stack (most recent call first):
  C:/Users/balcalde/zephyr/cmake/app/boilerplate.cmake:278 (include)
  CMakeLists.txt:3 (include)

-- Configuring incomplete, errors occurred!

I spent many hours searching trough the web and reading zephyr documentation but I didn´t found anything that help me to solve that error.

I apprecite any help.
Thanks, best regards
 
 



 
 


How to use MCUmgr for FOTA updates over BLE?

Junghwan Sung <superstar9999999@...>
 

Hi,

I am going to use Zephyr on another platforms (NOT Nordic's) for DFU over BLE.

In case of Nordic platforms, can be used nRF tools on mobile or nRF utils on PC for send a firmware or etc to target device working on Zephyr OS.
Also, The target device working on Zephyr OS is Nordic's platform, and this would be start DFU mode if press a button to start boot loader.

By the way, Zephyr released MCUmgr and MCUboot since release 1.11.0.
  • Firmware over-the-air (FOTA) updates over BLE using MCUmgr.
I think MCUmgr and MCUboot could be used another platforms NOT Nordic's.


So, There are questions about this.


Q1. Is the following sequence is right?




If it is wrong, please let me know right sequence.


If the above sequence is right,


Q2. 
In Shell of zephyr device via uart console application such as teraterm: 
sudo mcumgr --conntype ble --connstring ctlr_name=hci0,peer_name='Zephyr' image upload singed.bin

Q3.
To enter the DFU mode, could it be button like Nordic's? 

Q4.
Should SMP server application be always running for DFU over BLE?

Q5.
Is there documents more user friendly or video about SMP Server Sample? 
I think it seems great example to understand how DFU over BLE works.

I will wait for your reply.

BR,
June Sung


Re: Enable SPI driver on nrf52840

Chettimada, Vinayak Kariappa
 

https://youtu.be/vioi4OsmB_U

Hope the above video helps :-)

Summary: Kconfig options for one board may require new dependencies be met for another board.

- Vinayak

PS: added users mailing list, hope helps them too.

On 28 Aug 2018, at 04:07, cpmcparland@... wrote:

Vinayak,

Thanks.  I thought that the creation the driver source directories was only done at cmake time.... so that's where I was looking
for a problem.  Clearly I was wrong about that.  Did just what you suggested using the arduino_101 board as target (that seems
to be the example always used) and things worked as you desicribed.  However all is not well yet with the nrf pca10056, so I
have taken a page from your note and am trying again from a clean dist.

I just cloned rc13 and am attempting to build the i2c_fujitsu_fram sample program.  Sourced the appropriate
zephyr_end.sh script.  Created build/arduino_101 in the sample
directory and executed cmake -DBOARD=arduino_101 ../..    All went well.  Also issued make command and sample
compiled and linked without a problem.  NO changes to anything in the repo - just cmake and make.

Then created a clean build/nrf52840_pca10056 directory in the sample directory and executed cmake -DBOARD=nrf52840_pca10056.
NO changes to the repo - just create directories and executed cmake.  REceived the following output and error:

cmake -DBOARD=nrf52840_pca10056 ../..
-- Found PythonInterp: /usr/bin/python3 (found suitable version "3.5.3", minimum required is "3.4")
-- Selected BOARD nrf52840_pca10056
Zephyr version: 1.13.0
Parsing Kconfig tree in /home/mcp/ZephyrProjects/zephyr_1.1.2/zephyr_latest/Kconfig
Using /home/mcp/ZephyrProjects/zephyr_1.1.2/zephyr_latest/boards/arm/nrf52840_pca10056/nrf52840_pca10056_defconfig as base
Merging /home/mcp/ZephyrProjects/zephyr_1.1.2/zephyr_latest/samples/drivers/i2c_fujitsu_fram/prj.conf
-- Generating zephyr/include/generated/generated_dts_board.h
-- Cache files will be written to: /home/mcp/.cache/zephyr
-- The C compiler identification is GNU 6.2.0
-- The CXX compiler identification is GNU 6.2.0
-- The ASM compiler identification is GNU
-- Found assembler: /opt/zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/bin/arm-zephyr-eabi/arm-zephyr-eabi-gcc
-- Performing Test toolchain_is_ok
-- Performing Test toolchain_is_ok - Success
CMake Error at ../../../CMakeLists.txt:527 (message):
  The Zephyr library 'drivers__i2c' was created without source files.  Empty
  (non-imported) libraries are not supported.  Either make sure that the
  library has the sources it should have, or make sure it is not created when
  it has no source files.


-- Configuring incomplete, errors occurred!

Any comments would be welcome.  Also, thanks for posting the menuconfig issue...am following that
closely.

Regards,
Chuck


Re: Enable SPI driver on nrf52840

cpmcparland@...
 

Vinayak,

Thanks.  I thought that the creation the driver source directories was only done at cmake time.... so that's where I was looking
for a problem.  Clearly I was wrong about that.  Did just what you suggested using the arduino_101 board as target (that seems
to be the example always used) and things worked as you desicribed.  However all is not well yet with the nrf pca10056, so I
have taken a page from your note and am trying again from a clean dist.

I just cloned rc13 and am attempting to build the i2c_fujitsu_fram sample program.  Sourced the appropriate
zephyr_end.sh script.  Created build/arduino_101 in the sample
directory and executed cmake -DBOARD=arduino_101 ../..    All went well.  Also issued make command and sample
compiled and linked without a problem.  NO changes to anything in the repo - just cmake and make.

Then created a clean build/nrf52840_pca10056 directory in the sample directory and executed cmake -DBOARD=nrf52840_pca10056.
NO changes to the repo - just create directories and executed cmake.  REceived the following output and error:

cmake -DBOARD=nrf52840_pca10056 ../..
-- Found PythonInterp: /usr/bin/python3 (found suitable version "3.5.3", minimum required is "3.4")
-- Selected BOARD nrf52840_pca10056
Zephyr version: 1.13.0
Parsing Kconfig tree in /home/mcp/ZephyrProjects/zephyr_1.1.2/zephyr_latest/Kconfig
Using /home/mcp/ZephyrProjects/zephyr_1.1.2/zephyr_latest/boards/arm/nrf52840_pca10056/nrf52840_pca10056_defconfig as base
Merging /home/mcp/ZephyrProjects/zephyr_1.1.2/zephyr_latest/samples/drivers/i2c_fujitsu_fram/prj.conf
-- Generating zephyr/include/generated/generated_dts_board.h
-- Cache files will be written to: /home/mcp/.cache/zephyr
-- The C compiler identification is GNU 6.2.0
-- The CXX compiler identification is GNU 6.2.0
-- The ASM compiler identification is GNU
-- Found assembler: /opt/zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/bin/arm-zephyr-eabi/arm-zephyr-eabi-gcc
-- Performing Test toolchain_is_ok
-- Performing Test toolchain_is_ok - Success
CMake Error at ../../../CMakeLists.txt:527 (message):
  The Zephyr library 'drivers__i2c' was created without source files.  Empty
  (non-imported) libraries are not supported.  Either make sure that the
  library has the sources it should have, or make sure it is not created when
  it has no source files.


-- Configuring incomplete, errors occurred!

Any comments would be welcome.  Also, thanks for posting the menuconfig issue...am following that
closely.

Regards,
Chuck


[RFC] Thinking about extended poll support in Zephyr

Paul Sokolovsky
 

Hello,

Soon we'll need to wave bye-bye to the bloaty [1][2] k_poll(). I'm
pondering about submitting a "k_epoll" RFC some time when 1.13 heat
subsides, but just came by an article that Linux was adding yet another
advanced poll feature: https://lwn.net/Articles/743714/

So, reading thru it (and not anything else), they're not too shy to go
for complete "zero copy" by pushing poll results straight into the
userspace memory.

I personally don't think that it would affect plans for going to a
well-known epoll design, but pushing results asynchronously into the
userspace is also an interesting, if not brave, pattern we might keep
in mind trying to optimize kernel/userspace split overheads.

Btw, another point is that they not too shy to do following in the very
bloated OS:

One potential limitation built into this API is that there can only
be a single wait queue that receives notifications for a given file.
We may revisit that too, to see what are real usecases to put the same
object into multiple pollers (for a new implementation, I mean).

[1]
https://github.com/zephyrproject-rtos/zephyr/blob/master/include/kernel.h#L4411
[2]
https://github.com/zephyrproject-rtos/zephyr/blob/master/subsys/net/lib/sockets/sockets.c#L687

--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog


Re: nrf52840_pca10059 startup

Henrik Brix Andersen
 

Hi,

I am not using the NRF52832 configuration on the NRF52840 SoC; I merely noted that I have successfully used the same programmer (Atmel-ICE) for interacting with NRF52832 SoCs.

Yes, my application is samples/basic/blinky (and all other samples). I have tried the samples/bluetooth/peripheral sample; same issue.
When I initially flash the sample it starts up and everything works as intended. If I then disconnect USB power and reconnect it, nothing starts up (BLE scanner does not show the peripheral anymore).
A simple no-op SWD connection then does the trick; the application springs to life (without flashing a new binary).

I have tried a few of the USB samples as well; none of them shows up as a device on the USB bus.

Do you know if the original firmware binary (the one present on the device when shipping) for the PCA10059 is available anywhere? It could be interesting to see if that behaves correctly.
Are you able to share your locally built zephyr.bin file for the blinky sample with me?

Best regards,
Brix
--
Henrik Brix Andersen

On 27 Aug 2018, at 22.06, Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@nordicsemi.no> wrote:

Something you mention about using NRF52832 configuration, why would you want to use that on nRF52840 SoC?

You mention blinky as the example, is that the application you have trouble with? We tried that on our dongle, and see no issues.

I have tried BLE peripheral sample and hci_usb sample on nRF52840 merely powered from nRF USB interface, and see no issues.

Please confirm, that your application is samples/basic/blinky… also please try the samples/bluetooth/peripheral and let me know if you don’t see BLE advertising.

Regards,
Vinayak

On 27 Aug 2018, at 18:42, Henrik Brix Andersen <henrik@brixandersen.dk> wrote:

Hi Vinayak,

Thank you for getting back to me. I just tried reverting commit 26d22b0075cf5a71f13958ec1f2727ac7167eca4, but it does not fix the application behaviour.

Any other ideas are most welcome.

Best regards,
Brix

--
Henrik Brix Andersen

On 27 Aug 2018, at 12.52, Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@nordicsemi.no> wrote:

Hi,

I may have introduced a regression (bisected to) in 26d22b0075cf5a71f13958ec1f2727ac7167eca4

I notice that hci_usb sample fails to enumerate the bluetooth class device.

Will get back when I have something. Meanwhile, revert the above mentioned commit and do let me know if your application functions as expected.

Regards,
Vinayak


On 26 Aug 2018, at 19:18, Henrik Brix Andersen <henrik@brixandersen.dk> wrote:

Hi,

I am flashing the board using an Atmel-ICE debugger (using pyOCD 0.11.2) connected to a 10-pin debug connector soldered to the P1 footprint on the bottom of the board.

I am using the same configuration for several NRF52832 boards without issues.

Best regards,
Brix

--
Henrik Brix Andersen

On 26 Aug 2018, at 19.01, Cufi, Carles <Carles.Cufi@nordicsemi.no> wrote:

Hi there,

Can you tell us how you're flashing the board? Another Nordic Devkit, or a separate debug IC?

Also copying Emanuele who's doing most of the work on this board.

Regards,

Carles

On 26/08/2018, 18:07, "devel@lists.zephyrproject.org on behalf of Henrik Brix Andersen" <devel@lists.zephyrproject.org on behalf of henrik@brixandersen.dk> wrote:

Hi,

I have just acquired an NRF52840 Dongle (nrf52840_pca10059) and I am facing some difficulties with board startup.

When I flash a zephyr binary to the board (e.g. samples/basic/blinky) the board starts up fine and starts the application.
But when I disconnect the board from USB power and reconnect it, the application no longer starts (and the internal DC-DC converter does not seem to start-up either).

If I run no-op pyOCD command (e.g. pyocd-flashtool -t nrf52840) the application springs to life (e.g. for blinky, the LED starts to blink).
I am not using mcuboot or any other bootloader; just the bare-bone sample application.

What am I missing here?

Best regards,
Brix
--
Henrik Brix Andersen










Re: nrf52840_pca10059 startup

Chettimada, Vinayak Kariappa
 

Something you mention about using NRF52832 configuration, why would you want to use that on nRF52840 SoC?

You mention blinky as the example, is that the application you have trouble with? We tried that on our dongle, and see no issues.

I have tried BLE peripheral sample and hci_usb sample on nRF52840 merely powered from nRF USB interface, and see no issues.

Please confirm, that your application is samples/basic/blinky… also please try the samples/bluetooth/peripheral and let me know if you don’t see BLE advertising.

Regards,
Vinayak

On 27 Aug 2018, at 18:42, Henrik Brix Andersen <henrik@brixandersen.dk> wrote:

Hi Vinayak,

Thank you for getting back to me. I just tried reverting commit 26d22b0075cf5a71f13958ec1f2727ac7167eca4, but it does not fix the application behaviour.

Any other ideas are most welcome.

Best regards,
Brix

--
Henrik Brix Andersen

On 27 Aug 2018, at 12.52, Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@nordicsemi.no> wrote:

Hi,

I may have introduced a regression (bisected to) in 26d22b0075cf5a71f13958ec1f2727ac7167eca4

I notice that hci_usb sample fails to enumerate the bluetooth class device.

Will get back when I have something. Meanwhile, revert the above mentioned commit and do let me know if your application functions as expected.

Regards,
Vinayak


On 26 Aug 2018, at 19:18, Henrik Brix Andersen <henrik@brixandersen.dk> wrote:

Hi,

I am flashing the board using an Atmel-ICE debugger (using pyOCD 0.11.2) connected to a 10-pin debug connector soldered to the P1 footprint on the bottom of the board.

I am using the same configuration for several NRF52832 boards without issues.

Best regards,
Brix

--
Henrik Brix Andersen

On 26 Aug 2018, at 19.01, Cufi, Carles <Carles.Cufi@nordicsemi.no> wrote:

Hi there,

Can you tell us how you're flashing the board? Another Nordic Devkit, or a separate debug IC?

Also copying Emanuele who's doing most of the work on this board.

Regards,

Carles

On 26/08/2018, 18:07, "devel@lists.zephyrproject.org on behalf of Henrik Brix Andersen" <devel@lists.zephyrproject.org on behalf of henrik@brixandersen.dk> wrote:

Hi,

I have just acquired an NRF52840 Dongle (nrf52840_pca10059) and I am facing some difficulties with board startup.

When I flash a zephyr binary to the board (e.g. samples/basic/blinky) the board starts up fine and starts the application.
But when I disconnect the board from USB power and reconnect it, the application no longer starts (and the internal DC-DC converter does not seem to start-up either).

If I run no-op pyOCD command (e.g. pyocd-flashtool -t nrf52840) the application springs to life (e.g. for blinky, the LED starts to blink).
I am not using mcuboot or any other bootloader; just the bare-bone sample application.

What am I missing here?

Best regards,
Brix
--
Henrik Brix Andersen










回复:回复:[Zephyr-devel] hciconfig tools error with nrf52832 running zephyr

icephyr
 

oh,sorry that I missed the dot.it is 4.1.15 actually

发自我的华为手机


-------- 原始邮件 --------
主题:Re: 回复:[Zephyr-devel] hciconfig tools error with nrf52832 running zephyr
发件人:Johan Hedberg
收件人:sxzxchen@...
抄送:Maureen Helm ,devel@...


Earlier you said it was 4.1.15. Which one was a typo? :)

Johan

On Tue, Aug 28, 2018, sxzxchen@... wrote:
> imx6ull,with linux kernel version 4.15
>
> 发自我的华为手机
>
>
> -------- 原始邮件 --------
> 主题:Re: [Zephyr-devel] hciconfig tools error with nrf52832 running zephyr
> 发件人:Maureen Helm
> 收件人:sxzxchen@...,Johan Hedberg
> 抄送:devel@...
>
>
>
>
> Which NXP device are you running embedded Linux? I can check to see if we
> have plans to update the kernel version.
>
>
>
> From: devel@... On
> Behalf Of sxzxchen@...
> Sent: Monday, August 27, 2018 7:28 AM
> To: Johan Hedberg
> Cc: devel@...
> Subject: Re: [Zephyr-devel] hciconfig tools error with nrf52832 running
> zephyr
>
>
>
> Thanks for your explanation.since the embedded linux version is bound with
> the chip, I cannot update it easily.So is there any ways to solve this
> problem without updating linux version ?
>
>
>
>
>
>
>
> At 2018-08-24 13:24:28, "Johan Hedberg" wrote:
>
> >Hi,
>
> >
>
> >On Thu, Aug 23, 2018, sxzxchen@... wrote:
>
> >> I bought a official nrf52832 development kits and ported zephyr
>
> >> project successfully. It runs fine with my ubuntu host,via btattach
>
> >> and btmgmt tools.But it didn't work with my nxp embedded linux,the
>
> >> linux version is 4.1.15 and supports hciattach hciconfig tools
>
> >> only.When I tried to bring the bluetooth module up with hciconfig hci0
>
> >> up,an error comes up:
>
> >
>
> >The 4.1 kernel is too old to support controllers without a public
>
> >address. IIRC you need at least a 4.4 kernel, but ideally something much
>
> >newer than that.
>
> >
>
> >Johan
>
>
>
>
>
>
>



Re: nrf52840_pca10059 startup

Henrik Brix Andersen
 

Hi Vinayak,

Thank you for getting back to me. I just tried reverting commit 26d22b0075cf5a71f13958ec1f2727ac7167eca4, but it does not fix the application behaviour.

Any other ideas are most welcome.

Best regards,
Brix

--
Henrik Brix Andersen

On 27 Aug 2018, at 12.52, Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@nordicsemi.no> wrote:

Hi,

I may have introduced a regression (bisected to) in 26d22b0075cf5a71f13958ec1f2727ac7167eca4

I notice that hci_usb sample fails to enumerate the bluetooth class device.

Will get back when I have something. Meanwhile, revert the above mentioned commit and do let me know if your application functions as expected.

Regards,
Vinayak


On 26 Aug 2018, at 19:18, Henrik Brix Andersen <henrik@brixandersen.dk> wrote:

Hi,

I am flashing the board using an Atmel-ICE debugger (using pyOCD 0.11.2) connected to a 10-pin debug connector soldered to the P1 footprint on the bottom of the board.

I am using the same configuration for several NRF52832 boards without issues.

Best regards,
Brix

--
Henrik Brix Andersen

On 26 Aug 2018, at 19.01, Cufi, Carles <Carles.Cufi@nordicsemi.no> wrote:

Hi there,

Can you tell us how you're flashing the board? Another Nordic Devkit, or a separate debug IC?

Also copying Emanuele who's doing most of the work on this board.

Regards,

Carles

On 26/08/2018, 18:07, "devel@lists.zephyrproject.org on behalf of Henrik Brix Andersen" <devel@lists.zephyrproject.org on behalf of henrik@brixandersen.dk> wrote:

Hi,

I have just acquired an NRF52840 Dongle (nrf52840_pca10059) and I am facing some difficulties with board startup.

When I flash a zephyr binary to the board (e.g. samples/basic/blinky) the board starts up fine and starts the application.
But when I disconnect the board from USB power and reconnect it, the application no longer starts (and the internal DC-DC converter does not seem to start-up either).

If I run no-op pyOCD command (e.g. pyocd-flashtool -t nrf52840) the application springs to life (e.g. for blinky, the LED starts to blink).
I am not using mcuboot or any other bootloader; just the bare-bone sample application.

What am I missing here?

Best regards,
Brix
--
Henrik Brix Andersen










Re: 回复:[Zephyr-devel] hciconfig tools error with nrf52832 running zephyr

Johan Hedberg
 

Earlier you said it was 4.1.15. Which one was a typo? :)

Johan

On Tue, Aug 28, 2018, sxzxchen@163.com wrote:
imx6ull,with linux kernel version 4.15

发自我的华为手机


-------- 原始邮件 --------
主题:Re: [Zephyr-devel] hciconfig tools error with nrf52832 running zephyr
发件人:Maureen Helm
收件人:sxzxchen@163.com,Johan Hedberg
抄送:devel@lists.zephyrproject.org




Which NXP device are you running embedded Linux? I can check to see if we
have plans to update the kernel version.



From: devel@lists.zephyrproject.org <devel@lists.zephyrproject.org> On
Behalf Of sxzxchen@163.com
Sent: Monday, August 27, 2018 7:28 AM
To: Johan Hedberg <johan.hedberg@intel.com>
Cc: devel@lists.zephyrproject.org
Subject: Re: [Zephyr-devel] hciconfig tools error with nrf52832 running
zephyr



Thanks for your explanation.since the embedded linux version is bound with
the chip, I cannot update it easily.So is there any ways to solve this
problem without updating linux version ?







At 2018-08-24 13:24:28, "Johan Hedberg" <johan.hedberg@intel.com> wrote:

>Hi,

>

>On Thu, Aug 23, 2018, sxzxchen@163.com wrote:

>> I bought a official nrf52832 development kits and ported zephyr

>> project successfully. It runs fine with my ubuntu host,via btattach

>> and btmgmt tools.But it didn't work with my nxp embedded linux,the

>> linux version is 4.1.15 and supports hciattach hciconfig tools

>> only.When I tried to bring the bluetooth module up with hciconfig hci0

>> up,an error comes up:

>

>The 4.1 kernel is too old to support controllers without a public

>address. IIRC you need at least a 4.4 kernel, but ideally something much

>newer than that.

>

>Johan







回复:[Zephyr-devel] hciconfig tools error with nrf52832 running zephyr

icephyr
 

imx6ull,with linux kernel version 4.15

发自我的华为手机


-------- 原始邮件 --------
主题:Re: [Zephyr-devel] hciconfig tools error with nrf52832 running zephyr
发件人:Maureen Helm
收件人:sxzxchen@...,Johan Hedberg
抄送:devel@...


Which NXP device are you running embedded Linux? I can check to see if we have plans to update the kernel version.

 

From: devel@... <devel@...> On Behalf Of sxzxchen@...
Sent: Monday, August 27, 2018 7:28 AM
To: Johan Hedberg <johan.hedberg@...>
Cc: devel@...
Subject: Re: [Zephyr-devel] hciconfig tools error with nrf52832 running zephyr

 

Thanks for your explanation.since the embedded linux version is bound  with the chip, I cannot update it easily.So is there any ways to solve this problem without updating linux version ?  




 


At 2018-08-24 13:24:28, "Johan Hedberg" <johan.hedberg@...> wrote:
>Hi,
>On Thu, Aug 23, 2018, sxzxchen@... wrote:
>> I bought a official nrf52832 development kits and ported zephyr
>> project successfully. It runs fine with my ubuntu host,via btattach
>> and btmgmt tools.But it didn't work with my nxp embedded linux,the
>> linux version is 4.1.15 and supports hciattach hciconfig tools
>> only.When I tried to bring the bluetooth module up with hciconfig hci0
>> up,an error comes up:
>The 4.1 kernel is too old to support controllers without a public
>address. IIRC you need at least a 4.4 kernel, but ideally something much
>newer than that.
>Johan

 

 


Re: hciconfig tools error with nrf52832 running zephyr

Maureen Helm
 

Which NXP device are you running embedded Linux? I can check to see if we have plans to update the kernel version.

 

From: devel@... <devel@...> On Behalf Of sxzxchen@...
Sent: Monday, August 27, 2018 7:28 AM
To: Johan Hedberg <johan.hedberg@...>
Cc: devel@...
Subject: Re: [Zephyr-devel] hciconfig tools error with nrf52832 running zephyr

 

Thanks for your explanation.since the embedded linux version is bound  with the chip, I cannot update it easily.So is there any ways to solve this problem without updating linux version ?  




 


At 2018-08-24 13:24:28, "Johan Hedberg" <johan.hedberg@...> wrote:
>Hi,
>On Thu, Aug 23, 2018, sxzxchen@... wrote:
>> I bought a official nrf52832 development kits and ported zephyr
>> project successfully. It runs fine with my ubuntu host,via btattach
>> and btmgmt tools.But it didn't work with my nxp embedded linux,the
>> linux version is 4.1.15 and supports hciattach hciconfig tools
>> only.When I tried to bring the bluetooth module up with hciconfig hci0
>> up,an error comes up:
>The 4.1 kernel is too old to support controllers without a public
>address. IIRC you need at least a 4.4 kernel, but ideally something much
>newer than that.
>Johan

 

 


Re: hciconfig tools error with nrf52832 running zephyr

icephyr
 

Thanks for your explanation.since the embedded linux version is bound  with the chip, I cannot update it easily.So is there any ways to solve this problem without updating linux version ?  






At 2018-08-24 13:24:28, "Johan Hedberg" <johan.hedberg@...> wrote: >Hi, > >On Thu, Aug 23, 2018, sxzxchen@... wrote: >> I bought a official nrf52832 development kits and ported zephyr >> project successfully. It runs fine with my ubuntu host,via btattach >> and btmgmt tools.But it didn't work with my nxp embedded linux,the >> linux version is 4.1.15 and supports hciattach hciconfig tools >> only.When I tried to bring the bluetooth module up with hciconfig hci0 >> up,an error comes up: > >The 4.1 kernel is too old to support controllers without a public >address. IIRC you need at least a 4.4 kernel, but ideally something much >newer than that. > >Johan


 


Re: nrf52840_pca10059 startup

Chettimada, Vinayak Kariappa
 

Hi,

I may have introduced a regression (bisected to) in 26d22b0075cf5a71f13958ec1f2727ac7167eca4

I notice that hci_usb sample fails to enumerate the bluetooth class device.

Will get back when I have something. Meanwhile, revert the above mentioned commit and do let me know if your application functions as expected.

Regards,
Vinayak


On 26 Aug 2018, at 19:18, Henrik Brix Andersen <henrik@...> wrote:

Hi,

I am flashing the board using an Atmel-ICE debugger (using pyOCD 0.11.2) connected to a 10-pin debug connector soldered to the P1 footprint on the bottom of the board.

I am using the same configuration for several NRF52832 boards without issues.

Best regards,
Brix

--
Henrik Brix Andersen

On 26 Aug 2018, at 19.01, Cufi, Carles <Carles.Cufi@...> wrote:

Hi there,

Can you tell us how you're flashing the board? Another Nordic Devkit, or a separate debug IC?

Also copying Emanuele who's doing most of the work on this board.

Regards,

Carles

On 26/08/2018, 18:07, "devel@... on behalf of Henrik Brix Andersen" <devel@... on behalf of henrik@...> wrote:

  Hi,

  I have just acquired an NRF52840 Dongle (nrf52840_pca10059) and I am facing some difficulties with board startup.

  When I flash a zephyr binary to the board (e.g. samples/basic/blinky) the board starts up fine and starts the application.
  But when I disconnect the board from USB power and reconnect it, the application no longer starts (and the internal DC-DC converter does not seem to start-up either).

  If I run no-op pyOCD command (e.g. pyocd-flashtool -t nrf52840) the application springs to life (e.g. for blinky, the LED starts to blink).
  I am not using mcuboot or any other bootloader; just the bare-bone sample application.

  What am I missing here?

  Best regards,
  Brix
  --
  Henrik Brix Andersen













NRF52 : use of NFFS file system

Laurence Pasteau
 

Hi everybody,


I worked on a board including a NRF52 and use the file system with NFFS but I never succeed in using it correctly.


I have a lot of errors depending on the configuration parameters that I set.

I reduce my problem to a little test that only writes in a loop 12 bytes in a single file. It fails very quickly.

Sometimes the operation seems good when checking the return value. However the file became a file of size null and a new file with another name appears with the previous file. Then some loops later, there is an error in a return value of the write function.


I tried to modify NFFS configuration.

In the two cases when  the CONFIG_NFFS_FILESYSTEM_MAX_BLOCK_SIZE is higher and when the global size of the file system is higher ; the test is good during a longer time before failing.

If I write 24 instead of 12 bytes or if I write in two files instead of one, the issue comes sooner.


I think something in my configuration (or in my software) is wrong. If someone can help me it would be very helpful.


Attached is the little test and the conf file. To reduce the time before failing, I change the file system size to 0x2000.



Here is my configuration (I don't use MCU_BOOT) :


In the dts file :

    partitions {
        compatible = "fixed-partitions";
        #address-cells = <1>;
        #size-cells = <1>;

        boot_partition: partition@0 {
            label = "mcuboot";
            reg = <0x00000000 0xc000>;
        };
        slot0_partition: partition@c000 {
            label = "image-0";
            reg = <0x0000C000 0x32000>;
        };
        slot1_partition: partition@3e000 {
            label = "image-1";
            reg = <0x0003E000 0x32000>;
        };
        scratch_partition: partition@70000 {
            label = "image-scratch";
            reg = <0x00070000 0xa000>;
        };

#if defined(CONFIG_FS_FLASH_STORAGE_PARTITION)
        storage_partition: partition@7a000 {
            label = "storage";
            reg = <0x0007a000 0x00002000>;
        };
#endif
    };


In the conf file :

CONFIG_SOC_FLASH_NRF=y
CONFIG_FS_NFFS_NUM_BLOCKS=1024
CONFIG_FS_NFFS_NUM_INODES=1024
CONFIG_FS_NFFS_NUM_CACHE_BLOCKS=1
CONFIG_FS_NFFS_NUM_CACHE_INODES=1
CONFIG_FS_NFFS_NUM_DIRS=4
CONFIG_FS_NFFS_NUM_FILES=4
CONFIG_FS_NFFS_NUM_INODES=64
CONFIG_HEAP_MEM_POOL_SIZE=4096
CONFIG_MAIN_STACK_SIZE=4096
CONFIG_NFFS_FILESYSTEM_MAX_AREAS=12
CONFIG_NFFS_FILESYSTEM_MAX_BLOCK_SIZE=128
CONFIG_FS_FLASH_STORAGE_PARTITION=y
CONFIG_SOC_FLASH_NRF_RADIO_SYNC=y


In the CMakeLists.txt :

set(BOARD nrf52_pca10040)

target_include_directories(app PRIVATE $ENV{ZEPHYR_BASE}/ext/fs/nffs/include)
target_link_libraries(app NFFS)


Thanks in advance for any help.


Regards,

Laurence





2661 - 2680 of 7688