Date   

Re: k_msgq_get_attrs declared 'static' but never defined???

Leandro Pereira
 

On 05/07/2018 02:29 PM, David Leach wrote:
Yes, that was it. I was being stupid and using ‘rm -rf *.*’ and not checking that the cmake files had been cleaned up… ‘rm -rf *’ does the job as does ‘ninja clean’
(back to my linux vm in my windows 10 machine… 😉 )
Although you can use the "clean" target, try using "git clean -xfd" in the build directory instead of "rm".

It's less prone to errors: it will only remove files not tracked by Git, and will remove everything else. If you run the command outside your build directory, or type it wrongly (I once typed ~ instead of *), the catastrophe will be reduced.

(Important to note as well that "rm -rf *.*" and "rm -rf *" are not equivalent: Unix file systems consider "." as part of file names, and it's perfectly fine for files to not have "." in their names.)


Leandro


Re: k_msgq_get_attrs declared 'static' but never defined???

David Leach
 

Yes, that was it. I was being stupid and using ‘rm -rf *.*’ and not checking that the cmake files had been cleaned up… ‘rm -rf *’ does the job as does ‘ninja clean’

 

(back to my linux vm in my windows 10 machine… 😉 )

 

Thanks

 

From: Boie, Andrew P [mailto:andrew.p.boie@...]
Sent: Monday, May 7, 2018 4:23 PM
To: David Leach <david.leach@...>; zephyr-devel@...
Subject: RE: [Zephyr-devel] k_msgq_get_attrs declared 'static' but never defined???

 

I can't reproduce this.

Does doing a clean build help?

Is this sample built by our CI?

 

Andrew

 

From: devel@... [mailto:devel@...] On Behalf Of David Leach
Sent: Sunday, May 6, 2018 6:49 PM
To: zephyr-devel@...
Subject: [Zephyr-devel] k_msgq_get_attrs declared 'static' but never defined???

 

Pulled master and went to build OpenThread echo server and get a ton of the following:

../../../../../include/kernel.h:3021:20: warning: ‘k_msgq_get_attrs’ declared ‘static’ but never defined [-Wunused-function]

__syscall void  k_msgq_get_attrs(struct k_msgq *q, struct k_msgq_attrs *attrs);

 

Not sure what changed from the last time I built the sample.

 

David Leach


Re: k_msgq_get_attrs declared 'static' but never defined???

Boie, Andrew P
 

I can't reproduce this.

Does doing a clean build help?

Is this sample built by our CI?

 

Andrew

 

From: devel@... [mailto:devel@...] On Behalf Of David Leach
Sent: Sunday, May 6, 2018 6:49 PM
To: zephyr-devel@...
Subject: [Zephyr-devel] k_msgq_get_attrs declared 'static' but never defined???

 

Pulled master and went to build OpenThread echo server and get a ton of the following:

../../../../../include/kernel.h:3021:20: warning: ‘k_msgq_get_attrs’ declared ‘static’ but never defined [-Wunused-function]

__syscall void  k_msgq_get_attrs(struct k_msgq *q, struct k_msgq_attrs *attrs);

 

Not sure what changed from the last time I built the sample.

 

David Leach


Kconfig changes on master

Carles Cufi
 

Hi all,

We have just merged PR #7293 [1], and this has a few implications for developers and users. With the end goal being removing the dependency to the C implementation of the different Kconfig tools in order to provide native support on all operating systems, including Windows, Ulf has contributed a Python "menuconfig" implementation that is now the only frontend available for browsing the Kconfig tree.

In practice this means:

* The gconfig and xconfig targets have been removed
* The menuconfig target now uses a Python implementation with curses as its backend
* There is a new Python requirement on Windows (windows-curses) that is part of requirements.txt

If anyone in the community wants to look into providing a graphical user interface for Kconfig to replace the ones that have been removed, a good starting point would be to:

* Use Qt and the PyQt [2] or PySide [3](recently announced for Qt 5) bindings
* Use scripts/kconfig/menuconfig.py as a reference on how to access the Kconfig tree data from Python

Regards,

Carles

[1] https://github.com/zephyrproject-rtos/zephyr/pull/7293
[2] https://wiki.python.org/moin/PyQt
[3] https://wiki.qt.io/PySide


Re: problems building a BME680 app: zephyr_prebuilt.elf uses VFP register arguments ....

Carles Cufi
 

On the same note, and to add to what Sebastian said, you should also know that you can change the floating point ABI in Zephyr by setting:

CONFIG_FP_SOFTABI=y
or
CONFIG_FP_HARDABI=y

in your prj.conf.

Carles

On 07/05/2018, 18:50, "devel@lists.zephyrproject.org on behalf of Sebastian Boe" <devel@lists.zephyrproject.org on behalf of Sebastian.Boe@nordicsemi.no> wrote:

Hi,

what the toolchain is saying is that it can't link

libgcc.a into zephyr_prebuilt.elf because they have an incompatible floating point ABI.

Perhaps

c:/program files (x86)/gnu tools arm embedded/7.0 2017q4/bin/../lib/gcc/arm-none-eabi/7.2.1/thumb/v7e-m\libgcc.a(_popcountsi2.o)

uses a soft float ABI. You can determine this by running

"readelf -a libgcc.a"

on the library and grepping for "Tag_FP",
you should see something like

Tag_FP_arch: VFPv2

If it is indeed a soft-float library you could run "find c:/program files (x86)/gnu tools arm embedded/7.0 2017q4 -name libgcc.a"
to see if your toolchain has another libgcc.a that is built for hard-float.

See the similair, but different issue: https://github.com/zephyrproject-rtos/zephyr/issues/5771

________________________________________
From: devel@lists.zephyrproject.org <devel@lists.zephyrproject.org> on behalf of Abderrezak Mekkaoui <ab.mekka@clevertsystems.com>
Sent: Monday, 7 May 2018 6:04:36 PM
To: devel@lists.zephyrproject.org
Subject: [Zephyr-devel] problems building a BME680 app: zephyr_prebuilt.elf uses VFP register arguments ....

Hi All,
I am having problems porting a BME680 app to Zephyr. This app uses a
pre-compiled library (libalgobsec.a) provided by Bosch.
It builds and runs correctly on mynewt (using the exact same tool chain
and the same flags). After solving few issues related to stdint I am
struggling with the last issues possibly related incompatibilities
between different libraries.
I think I am using the right compiler and linker flags (see below) but I
may be wrong.
Any hints/help would be greatly appreciated.
Regards
Abderrezak

P.S. I have other apps that build and run correctly using the same tool
chain (but use the default zephyr flags and have no need for an external
binary library). I am using a custom nrf52840 based board.



###########################################################################################################################################################
CMakelists.txt (latest flag settings, many other combinations all failed)

target_link_libraries(app libalgobsec.a)
target_link_libraries(app libm.a)

set(FPU_FOR_cortex-m4 fpv4-sp-d16)
target_link_libraries(app m.a)
zephyr_cc_option(-DFLOAT_ABI_HARD -mcpu=cortex-m4 -mthumb-interwork
-mthumb -mabi=aapcs -mfloat-abi=hard -mfpu=fpv4-sp-d16 -fno-exceptions
-ffunction-sections -fdata-sections )
zephyr_ld_options(-static -specs=nosys.specs -lgcc -Wl,--gc-sections
-nostartfiles -mthumb -mabi=aapcs -mfloat-abi=hard -mfpu=fpv4-sp-d16
-DFLOAT_ABI_HARD -lalgobsec -lm)
#

###########################################################################################################################################################
Error messages (only few lines)

/progra~2/gnutoo~1/70922~1.020/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/bin/ld.exe:
error: zephyr\zephyr_prebuilt.elf uses VFP register arguments,
c:/program files (x86)/gnu tools arm embedded/7.0
2017q4/bin/../lib/gcc/arm-none-eabi/7.2.1/thumb/v7e-m\libgcc.a(_popcountsi2.o)
does not
c:/progra~2/gnutoo~1/70922~1.020/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/bin/ld.exe:
failed to merge target specific data of file c:/program files (x86)/gnu
tools arm embedded/7.0
2017q4/bin/../lib/gcc/arm-none-eabi/7.2.1/thumb/v7e-m\libgcc.a(_popcountsi2.o)
c:/progra~2/gnutoo~1/70922~1.020/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/bin/ld.exe:
error: zephyr\zephyr_prebuilt.elf uses VFP register arguments,
c:/program files (x86)/gnu tools arm embedded/7.0
2017q4/bin/../lib/gcc/arm-none-eabi/7.2.1/thumb/v7e-m\libgcc.a(_udivmoddi4.o)
does not
c:/progra~2/gnutoo~1/70922~1.020/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/bin/ld.exe:
failed to merge target specific data of file c:/program files (x86)/gnu
tools arm embedded/7.0
2017q4/bin/../lib/gcc/arm-none-eabi/7.2.1/thumb/v7e-m\libgcc.a(_udivmoddi4.o)
c:/progra~2/gnutoo~1/70922~1.020/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/bin/ld.exe:
error: zephyr\zephyr_prebuilt.elf uses VFP register arguments,
c:/progra~2/gnutoo~1/70922~1.020/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/lib\libm.a(lib_a-sf_exp.o)
does not
c:/progra~2/gnutoo~1/70922~1.020/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/bin/ld.exe:
failed to merge target specific data of file
c:/progra~2/gnutoo~1/70922~1.020/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/lib\libm.a(lib_a-sf_exp.o)
c:/progra~2/gnutoo~1/70922~1.020/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/bin/ld.exe:
error: zephyr\zephyr_prebuilt.elf uses VFP register arguments,
c:/progra~2/gnutoo~1/70922~1.020/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/lib\libm.a(lib_a-sf_exp2_data.o)
does not
c:/progra~2/gnutoo~1/70922~1.020/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/bin/ld.exe:
failed to merge target specific data of file
c:/progra~2/gnutoo~1/70922~1.020/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/lib\libm.a(lib_a-sf_exp2_data.o)
c:/progra~2/gnutoo~1/70922~1.020/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/bin/ld.exe:
error: zephyr\zephyr_prebuilt.elf uses VFP register arguments,
c:/progra~2/gnutoo~1/70922~1.020/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/lib\libm.a(lib_a-sf_fabs.o)
does not
c:/progra~2/gnutoo~1/70922~1.020/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/bin/ld.exe:
failed to merge target specific data of file
c:/progra~2/gnutoo~1/70922~1.020/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/lib\libm.a(lib_a-sf_fabs.o)


Re: Strange Codecov info

Alberto Escolar Piedras <ALPI@...>
 

Hi,

That line keeps coming in and out of coverage every now and then.

But I do not have a good explanation as to why.

 

The issue we had fixed with timing was due to sanitycheck being responsible for killing the testcase process when it saw the PASS/FAIL string, while the testcases actually continued executing.

The fix was to have the testcase end on its own as soon as it was done (TC_END_REPORT is called), instead of letting whatever leftover threads it had continue executing ahead.

 

Now sanitycheck should only be responsible from killing sample apps which do not use ztest. So I would only expect those kind of problems in sample apps.

 

But pthread_attr_destroy() seems to be only called from tests/posix/ . And those seem to be all ztest cases.

 

Note that the POSIX arch code we excluded for coverage can actually execute or not depending on the exact scheduling of the host OS. But the POSIX arch itself ensures that all code over the arch executes in a deterministic manner, following normal Zephyr scheduling. So nothing inside the testcase itself should be non-deterministic (unless there is uninitialized variables/memory or somebody calls rand() or similar).

 

And note that lib/posix has nothing to do with the POSIX arch.

 

BR
Alberto

 

From: Nashif, Anas [mailto:anas.nashif@...]
Sent: Monday 7 May 2018 17:26
To: David Brown <david.brown@...>; Zephyr Devel <devel@...>
Cc: Alberto Escolar Piedras <ALPI@...>
Subject: RE: Strange Codecov info

 

Alberto might shed some light, but this is a timing issue that we keep seeing. We probably want to ignore this like we did with other spots in the native posix code.

 

This can be safely be ignored.

 

Anas

 

From: devel@... [mailto:devel@...] On Behalf Of David Brown
Sent: Monday, May 7, 2018 10:59 AM
To: Zephyr Devel <devel@...>
Cc: Nashif, Anas <anas.nashif@...>
Subject: [Zephyr-devel] Strange Codecov info

 

In https://github.com/zephyrproject-rtos/zephyr/pull/7352, I am seeing an unusual Codecov report. Although my change only affects a few files in the documentation, the Codecov report is showing an impact in lib/posix/pthread.c. Any idea what is going on here?

 

Thanks,

David

 


Re: problems building a BME680 app: zephyr_prebuilt.elf uses VFP register arguments ....

Sebastian Boe
 

Hi,

what the toolchain is saying is that it can't link

libgcc.a into zephyr_prebuilt.elf because they have an incompatible floating point ABI.

Perhaps

c:/program files (x86)/gnu tools arm embedded/7.0 2017q4/bin/../lib/gcc/arm-none-eabi/7.2.1/thumb/v7e-m\libgcc.a(_popcountsi2.o)

uses a soft float ABI. You can determine this by running

"readelf -a libgcc.a"

on the library and grepping for "Tag_FP",
you should see something like

Tag_FP_arch: VFPv2

If it is indeed a soft-float library you could run "find c:/program files (x86)/gnu tools arm embedded/7.0 2017q4 -name libgcc.a"
to see if your toolchain has another libgcc.a that is built for hard-float.

See the similair, but different issue: https://github.com/zephyrproject-rtos/zephyr/issues/5771

________________________________________
From: devel@lists.zephyrproject.org <devel@lists.zephyrproject.org> on behalf of Abderrezak Mekkaoui <ab.mekka@clevertsystems.com>
Sent: Monday, 7 May 2018 6:04:36 PM
To: devel@lists.zephyrproject.org
Subject: [Zephyr-devel] problems building a BME680 app: zephyr_prebuilt.elf uses VFP register arguments ....

Hi All,
I am having problems porting a BME680 app to Zephyr. This app uses a
pre-compiled library (libalgobsec.a) provided by Bosch.
It builds and runs correctly on mynewt (using the exact same tool chain
and the same flags). After solving few issues related to stdint I am
struggling with the last issues possibly related incompatibilities
between different libraries.
I think I am using the right compiler and linker flags (see below) but I
may be wrong.
Any hints/help would be greatly appreciated.
Regards
Abderrezak

P.S. I have other apps that build and run correctly using the same tool
chain (but use the default zephyr flags and have no need for an external
binary library). I am using a custom nrf52840 based board.



###########################################################################################################################################################
CMakelists.txt (latest flag settings, many other combinations all failed)

target_link_libraries(app libalgobsec.a)
target_link_libraries(app libm.a)

set(FPU_FOR_cortex-m4 fpv4-sp-d16)
target_link_libraries(app m.a)
zephyr_cc_option(-DFLOAT_ABI_HARD -mcpu=cortex-m4 -mthumb-interwork
-mthumb -mabi=aapcs -mfloat-abi=hard -mfpu=fpv4-sp-d16 -fno-exceptions
-ffunction-sections -fdata-sections )
zephyr_ld_options(-static -specs=nosys.specs -lgcc -Wl,--gc-sections
-nostartfiles -mthumb -mabi=aapcs -mfloat-abi=hard -mfpu=fpv4-sp-d16
-DFLOAT_ABI_HARD -lalgobsec -lm)
#

###########################################################################################################################################################
Error messages (only few lines)

/progra~2/gnutoo~1/70922~1.020/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/bin/ld.exe:
error: zephyr\zephyr_prebuilt.elf uses VFP register arguments,
c:/program files (x86)/gnu tools arm embedded/7.0
2017q4/bin/../lib/gcc/arm-none-eabi/7.2.1/thumb/v7e-m\libgcc.a(_popcountsi2.o)
does not
c:/progra~2/gnutoo~1/70922~1.020/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/bin/ld.exe:
failed to merge target specific data of file c:/program files (x86)/gnu
tools arm embedded/7.0
2017q4/bin/../lib/gcc/arm-none-eabi/7.2.1/thumb/v7e-m\libgcc.a(_popcountsi2.o)
c:/progra~2/gnutoo~1/70922~1.020/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/bin/ld.exe:
error: zephyr\zephyr_prebuilt.elf uses VFP register arguments,
c:/program files (x86)/gnu tools arm embedded/7.0
2017q4/bin/../lib/gcc/arm-none-eabi/7.2.1/thumb/v7e-m\libgcc.a(_udivmoddi4.o)
does not
c:/progra~2/gnutoo~1/70922~1.020/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/bin/ld.exe:
failed to merge target specific data of file c:/program files (x86)/gnu
tools arm embedded/7.0
2017q4/bin/../lib/gcc/arm-none-eabi/7.2.1/thumb/v7e-m\libgcc.a(_udivmoddi4.o)
c:/progra~2/gnutoo~1/70922~1.020/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/bin/ld.exe:
error: zephyr\zephyr_prebuilt.elf uses VFP register arguments,
c:/progra~2/gnutoo~1/70922~1.020/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/lib\libm.a(lib_a-sf_exp.o)
does not
c:/progra~2/gnutoo~1/70922~1.020/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/bin/ld.exe:
failed to merge target specific data of file
c:/progra~2/gnutoo~1/70922~1.020/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/lib\libm.a(lib_a-sf_exp.o)
c:/progra~2/gnutoo~1/70922~1.020/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/bin/ld.exe:
error: zephyr\zephyr_prebuilt.elf uses VFP register arguments,
c:/progra~2/gnutoo~1/70922~1.020/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/lib\libm.a(lib_a-sf_exp2_data.o)
does not
c:/progra~2/gnutoo~1/70922~1.020/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/bin/ld.exe:
failed to merge target specific data of file
c:/progra~2/gnutoo~1/70922~1.020/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/lib\libm.a(lib_a-sf_exp2_data.o)
c:/progra~2/gnutoo~1/70922~1.020/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/bin/ld.exe:
error: zephyr\zephyr_prebuilt.elf uses VFP register arguments,
c:/progra~2/gnutoo~1/70922~1.020/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/lib\libm.a(lib_a-sf_fabs.o)
does not
c:/progra~2/gnutoo~1/70922~1.020/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/bin/ld.exe:
failed to merge target specific data of file
c:/progra~2/gnutoo~1/70922~1.020/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/lib\libm.a(lib_a-sf_fabs.o)


problems building a BME680 app: zephyr_prebuilt.elf uses VFP register arguments ....

Abderrezak Mekkaoui
 

Hi All,
I am having problems porting a BME680 app to Zephyr. This app uses a pre-compiled library (libalgobsec.a) provided by Bosch.
It builds and runs correctly on mynewt (using the exact same tool chain and the same flags). After solving few issues related to stdint I am struggling with the last issues possibly related incompatibilities between different libraries.
I think I am using the right compiler and linker flags (see below) but I may be wrong.
Any hints/help would be greatly appreciated.
Regards
Abderrezak

P.S. I have other apps that  build and run correctly using the same tool chain (but use the default zephyr flags and have no need for an external binary library). I am using a custom nrf52840 based board.



###########################################################################################################################################################
CMakelists.txt (latest flag settings, many other combinations all failed)

target_link_libraries(app libalgobsec.a)
target_link_libraries(app libm.a)

set(FPU_FOR_cortex-m4      fpv4-sp-d16)
target_link_libraries(app m.a)
zephyr_cc_option(-DFLOAT_ABI_HARD -mcpu=cortex-m4 -mthumb-interwork -mthumb -mabi=aapcs -mfloat-abi=hard -mfpu=fpv4-sp-d16 -fno-exceptions -ffunction-sections -fdata-sections )
zephyr_ld_options(-static -specs=nosys.specs -lgcc -Wl,--gc-sections -nostartfiles -mthumb -mabi=aapcs -mfloat-abi=hard -mfpu=fpv4-sp-d16 -DFLOAT_ABI_HARD -lalgobsec -lm)
#

###########################################################################################################################################################
Error messages (only few lines)

/progra~2/gnutoo~1/70922~1.020/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/bin/ld.exe: error: zephyr\zephyr_prebuilt.elf uses VFP register arguments, c:/program files (x86)/gnu tools arm embedded/7.0 2017q4/bin/../lib/gcc/arm-none-eabi/7.2.1/thumb/v7e-m\libgcc.a(_popcountsi2.o) does not
c:/progra~2/gnutoo~1/70922~1.020/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/bin/ld.exe: failed to merge target specific data of file c:/program files (x86)/gnu tools arm embedded/7.0 2017q4/bin/../lib/gcc/arm-none-eabi/7.2.1/thumb/v7e-m\libgcc.a(_popcountsi2.o)
c:/progra~2/gnutoo~1/70922~1.020/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/bin/ld.exe: error: zephyr\zephyr_prebuilt.elf uses VFP register arguments, c:/program files (x86)/gnu tools arm embedded/7.0 2017q4/bin/../lib/gcc/arm-none-eabi/7.2.1/thumb/v7e-m\libgcc.a(_udivmoddi4.o) does not
c:/progra~2/gnutoo~1/70922~1.020/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/bin/ld.exe: failed to merge target specific data of file c:/program files (x86)/gnu tools arm embedded/7.0 2017q4/bin/../lib/gcc/arm-none-eabi/7.2.1/thumb/v7e-m\libgcc.a(_udivmoddi4.o)
c:/progra~2/gnutoo~1/70922~1.020/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/bin/ld.exe: error: zephyr\zephyr_prebuilt.elf uses VFP register arguments, c:/progra~2/gnutoo~1/70922~1.020/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/lib\libm.a(lib_a-sf_exp.o) does not
c:/progra~2/gnutoo~1/70922~1.020/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/bin/ld.exe: failed to merge target specific data of file c:/progra~2/gnutoo~1/70922~1.020/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/lib\libm.a(lib_a-sf_exp.o)
c:/progra~2/gnutoo~1/70922~1.020/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/bin/ld.exe: error: zephyr\zephyr_prebuilt.elf uses VFP register arguments, c:/progra~2/gnutoo~1/70922~1.020/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/lib\libm.a(lib_a-sf_exp2_data.o) does not
c:/progra~2/gnutoo~1/70922~1.020/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/bin/ld.exe: failed to merge target specific data of file c:/progra~2/gnutoo~1/70922~1.020/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/lib\libm.a(lib_a-sf_exp2_data.o)
c:/progra~2/gnutoo~1/70922~1.020/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/bin/ld.exe: error: zephyr\zephyr_prebuilt.elf uses VFP register arguments, c:/progra~2/gnutoo~1/70922~1.020/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/lib\libm.a(lib_a-sf_fabs.o) does not
c:/progra~2/gnutoo~1/70922~1.020/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/bin/ld.exe: failed to merge target specific data of file c:/progra~2/gnutoo~1/70922~1.020/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/lib\libm.a(lib_a-sf_fabs.o)


Re: Strange Codecov info

Nashif, Anas
 

Alberto might shed some light, but this is a timing issue that we keep seeing. We probably want to ignore this like we did with other spots in the native posix code.

 

This can be safely be ignored.

 

Anas

 

From: devel@... [mailto:devel@...] On Behalf Of David Brown
Sent: Monday, May 7, 2018 10:59 AM
To: Zephyr Devel <devel@...>
Cc: Nashif, Anas <anas.nashif@...>
Subject: [Zephyr-devel] Strange Codecov info

 

In https://github.com/zephyrproject-rtos/zephyr/pull/7352, I am seeing an unusual Codecov report. Although my change only affects a few files in the documentation, the Codecov report is showing an impact in lib/posix/pthread.c. Any idea what is going on here?

 

Thanks,

David

 


Strange Codecov info

David Brown
 

In https://github.com/zephyrproject-rtos/zephyr/pull/7352, I am seeing an unusual Codecov report. Although my change only affects a few files in the documentation, the Codecov report is showing an impact in lib/posix/pthread.c. Any idea what is going on here?

 

Thanks,

David

 


Re: fatal error: config-mini-tls1_2.h: No such file or directory

christian tavares
 

I was able to solve this problem by including in my CMakeLists.txt these lines below

zephyr_link_interface_ifdef(CONFIG_MBEDTLS mbedTLS)
zephyr_library_link_libraries_ifdef(CONFIG_MBEDTLS mbedTLS)

Thanks 


http_client_send_req doen't perform the callback function, using https support

christian tavares
 

Hello! 


I'm developing a library http_client. That library needs to download a flash image on the server and install the image on board.
However, I included https support on my library and now I can't download the flash image.  The function http_client_send_req doesn't call  the callback's function.
Below is how to call the start of http_client_init, http_client_set_tls and http_client_send_req:

RESULT_BUF_SIZEMBEDTLS_SSL_MAX_CONTENT_LEN (1500) 
#define HTTPS_STACK_SIZE (4096)
NET_STACK_DEFINE(HTTPS, https_stack, HTTPS_STACK_SIZE, HTTPS_STACK_SIZE);
NET_APP_TLS_POOL_DEFINE(ssl_pool, 10);
#define TCP_RECV_BUFFER_SIZE 1024 
#define APP_TIMEOUT K_SECONDS(10)

static u8_t https_result_buf[RESULT_BUF_SIZE];

ret = http_client_init(&ctx->http_client.http_ctx,
UPDATEHUB_SERVER,
UPDATEHUB_PORT, NULL,
APP_TIMEOUT);

ret = http_client_set_tls(&ctx->http_client.http_ctx,
https_result_buf,
RESULT_BUF_SIZE,
NULL,
NULL,
setup_cert,
NULL,
NULL,
&ssl_pool,
https_stack,
HTTPS_STACK_SIZE);

ret = http_client_send_req(&ctx->http_client.http_ctx,
   &ctx->http_client.req,
   install_update_cb ,
   ctx->http_client.tcp_buffer,
   TCP_RECV_BUFFER_SIZE, ctx,
   APP_TIMEOUT);

A timeout error occurs and the http_client_send_req function does not initialize my install_update_cb callback function.
I performed tests I realized that it can only get things from the size of https_result_buf (1500), but previously using HTTP, the install_update_cb function call occurred and the flash image in the size of (39000) was downloaded and stored on the card. Could someone help me how to solve my problem, and with https support hold the callback function call for items larger than https_result_buf?

For a better view I am sending the link from the library. The call occurs in function "updatehub_install_update"
https://github.com/OSSystems/zephyr/blob/master/subsys/updatehub/updatehub.c
github.com
zephyr - Primary GIT Repository for the Zephyr Project




Re: mbedtls problem

Paul Sokolovsky
 

Hello Clemence,

Unfortunately, it's very hard to tell why a TLS client and a TLS
server have a communication problem - TLS is a complex protocol, and
there can be dozens if not hundreds ways it can go wrong. And that's
not counting pure network issues, which can be dozens too.

As part of my work on
https://github.com/zephyrproject-rtos/zephyr/pull/5985 , I made
TLS/mbedTLS samples which work as expected and transfer megabytes of
data from a real-world server (which is hopefully enough to say "it
kinda works", though larger amount and coverage of testing is
definitely required).

The only scalable way to approach issues like you report is to take
known working reference sample(s), then step by step compare it with
your code, to see what you do differently.


Hope this helps.


On Mon, 7 May 2018 14:35:17 +0200
"clemence" <c.njamfa@overkiz.com> wrote:

Hi,

I am currently trying to integrate mbedtls to open a socket between a
bord NXP FRDM-K64F (client) and a server.

But the function "mbedtls_ssl_handshake" does not work.

The client send "client-hello".

The server receive "client-hello" and send : "server hello" + server
certification. But after 5s, the server send a message to close the
connection.

Why the server send the message to close the connection and what I
need to change in my client to fix it?


Thanks


Clemence
--
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


mbedtls problem

clemence
 

Hi,

I am currently trying to integrate mbedtls to open a socket between a bord NXP FRDM-K64F (client) and a server.

But the function "mbedtls_ssl_handshake" does not work.

The client send "client-hello".

The server receive "client-hello" and send : "server hello" + server certification. But after 5s, the server send a message to close the connection.

Why the server send the message to close the connection and what I need to change in my client to fix it?


Thanks


Clemence


Reminder: Zephyr API discussion weekly call tomorrow

Carles Cufi
 

Hi all,

Tomorrow we will have another API discussion call. Details on how to join:

https://github.com/zephyrproject-rtos/zephyr/wiki/Zephyr-Committee-and-Working-Group-Meetings#zephyr-api-discussion

We still need someone to take ownership of the I2C API at this point. The list of issues to address can be found summarized here:

https://github.com/zephyrproject-rtos/zephyr/issues/4040

If you think you can help out improving the I2C API please let us know.

As always, more information in the umbrella GitHub issue:

https://github.com/zephyrproject-rtos/zephyr/issues/5697

and in the meeting minutes:

https://docs.google.com/document/d/1lv-8B5QE2m4FjBcvfqAXFIgQfW5oz6306zJ7GIZIWCk

Thanks,

Carles


Re: Extending Error Codes

Carles Cufi
 

Hi Piotr,

-----Original Message-----
From: devel@lists.zephyrproject.org <devel@lists.zephyrproject.org> On
Behalf Of Ziecik, Piotr
Sent: 30 April 2018 16:20
To: Puzdrowski, Andrzej <Andrzej.Puzdrowski@nordicsemi.no>;
devel@lists.zephyrproject.org
Subject: Re: [Zephyr-devel] Extending Error Codes

Hi.

I do not think that per-module error codes are good idea.
I agree. I think a single set of generic error codes that are flexible enough to convey the message are a better approach.
That still leaves out how to extend errno.h for both newlib and minimal.

Should we have an extended errno-zephyr.h for Zephyr somewhere in include/?

Carles



First, you cannot to this:
foo_error_t foo(void)
{
boo_error_t error = boo();
if (error != BOO_SUCCESS)
return error; // Here you are changing the meaning of the
message. If the error will be propagated further the correct meaning
will dissolve and the error code will become useless.
}

To solve the problem shown above you will need a translation:
foo_error_t foo(void)
{
boo_error_t error = boo();

// Waste of space here: copy-paste to each function using BOO and
hard to maintain:
switch (error) {
case BOO_SUCCESS:
return FOO_SUCCESS;

case BOO_NOT_FOUND:
return FOO_NOT_FOUND;

default:
// Please maintain me 😊
__ASSERT(false);
}
}

IMHO the best solution is to extend the errno.h, but please remember
that all errors defined there must be generic (reusable across different
modules).

Best Regards,
Piotr Zięcik
Senior Firmware Engineer
M: +48 698 726 973



Nordic Semiconductor Poland sp. z o.o.
ul.Bratyslawska 1A, 31-201 Krakow, Poland www.nordicsemi.com



-----Original Message-----
From: devel@lists.zephyrproject.org
[mailto:devel@lists.zephyrproject.org] On Behalf Of Puzdrowski, Andrzej
Sent: Monday, April 30, 2018 3:53 PM
To: devel@lists.zephyrproject.org
Subject: Re: [Zephyr-devel] Extending Error Codes

I also see that error cods defined in <errno.h> are insufficient.
I think definition value-space for module specific codes are good idea
in general. But I'm afraid we can go down the road in case we relaxed
the line.
Also we can consider addition of generic codes to existing definitions
(which is better idea).

Andrzej

-----Original Message-----
From: devel@lists.zephyrproject.org
[mailto:devel@lists.zephyrproject.org] On Behalf Of laczenJMS
Sent: Friday, April 27, 2018 5:32 PM
To: devel@lists.zephyrproject.org
Subject: [Zephyr-devel] Extending Error Codes

Hello Zephyr Developers,

I recently had a request to change the error codes in a zephyr module to
use the standard supplied error codes. Doing so would reduce the
descriptiveness of the error codes so I did not really like this.
However in my module I was using error codes (-) 1 to 10, and I think
this was a bad idea. If someone needs to check the error code he/she
might end up looking at errno.h and finding a completely different
definition.

Would it not be a good idea to allow extending the standard error codes
with module (subsystem) specific error codes that can be as descriptive
as required by allowing modules to use error codes above a specific
value. E.g. any module can use it's own error codes starting from 0x7F00
to 0x7FFF. This way it is possible to avoid overlap between standard
errors and "user" errors.

What's your opinion ?

Kind regards,

Jehudi








k_msgq_get_attrs declared 'static' but never defined???

David Leach
 

Pulled master and went to build OpenThread echo server and get a ton of the following:

../../../../../include/kernel.h:3021:20: warning: ‘k_msgq_get_attrs’ declared ‘static’ but never defined [-Wunused-function]

__syscall void  k_msgq_get_attrs(struct k_msgq *q, struct k_msgq_attrs *attrs);

 

Not sure what changed from the last time I built the sample.

 

David Leach


Re: STM32 ADC shim

Justin
 

I was looking to do the same for NRF52 PWM driver.  I followed Erwan's suggestions.  Here's my PR https://github.com/zephyrproject-rtos/zephyr/pull/7334 if you're interested


Re: [Zephyr-users] What will be status of #BluetoothMesh in #LTS release ? #bluetoothmesh #lts

vikrant8051 <vikrant8051@...>
 

Hi Johan, 

Awesome, thanks for the info !!


On Sun, May 6, 2018, 10:55 AM Johan Hedberg <johan.hedberg@...> wrote:
Hi Vikrant,

On Thu, May 03, 2018, vikrant8051 wrote:
> What will be status of #BluetoothMesh in #LTS v.1.12.0 release?
>
> Will it be released as #Qualified stack?

There has been discussion of doing a qualification listing (perhaps two,
one for the core host stack and another for Mesh) for LTS releases under
the name of the Linux Foundation, but as far as I know there's no firm
committment to this yet (e.g. the funding of it). These would be
subsystem qualification listings, so you could combine them together
into a product listing (e.g. the controller qualification that Nordic
did is also a subsystem listing).

That said, both the core host stack (GAP, GATT, SM, L2CAP, etc) and mesh
are periodically run against the PTS, so there shouldn't be any major
surprises if you were to do the qualification process yourself.

> As of now, we can't save Provisioning, Configuration & other real time data
> (eg. message sequence Nos, states of Models etc. etc) on SoC flash. Will it
> be possible in #LTS release ?

If you follow the master branch, you'll have seen that the Bluetooth
stack has transitioned from the bt_storage API to the newly introduced
settings API (ported from MyNewt, where it's called "conf"). Currently
only pairing credentials (LTK, etc) are covered, but I have some patches
for Mesh that I'm hoping to send next week.

> How many Models (for eg. Generic, Lighting) will show case under #LTS ?

There's really not much "secret" stuff when it comes to the release,
i.e. something that would only be "revealed" at the last moment (the way
you make it sound). A lot of what you'll get is what you can see already
now in the master branch.

> What will be status of Friend & Low Power Nodes implementation ?

Both of those are complete and passing the PTS tests for them.

Johan


Re: [Zephyr-users] What will be status of #BluetoothMesh in #LTS release ? #bluetoothmesh #lts

Johan Hedberg
 

Hi Vikrant,

On Thu, May 03, 2018, vikrant8051 wrote:
What will be status of #BluetoothMesh in #LTS v.1.12.0 release?

Will it be released as #Qualified stack?
There has been discussion of doing a qualification listing (perhaps two,
one for the core host stack and another for Mesh) for LTS releases under
the name of the Linux Foundation, but as far as I know there's no firm
committment to this yet (e.g. the funding of it). These would be
subsystem qualification listings, so you could combine them together
into a product listing (e.g. the controller qualification that Nordic
did is also a subsystem listing).

That said, both the core host stack (GAP, GATT, SM, L2CAP, etc) and mesh
are periodically run against the PTS, so there shouldn't be any major
surprises if you were to do the qualification process yourself.

As of now, we can't save Provisioning, Configuration & other real time data
(eg. message sequence Nos, states of Models etc. etc) on SoC flash. Will it
be possible in #LTS release ?
If you follow the master branch, you'll have seen that the Bluetooth
stack has transitioned from the bt_storage API to the newly introduced
settings API (ported from MyNewt, where it's called "conf"). Currently
only pairing credentials (LTK, etc) are covered, but I have some patches
for Mesh that I'm hoping to send next week.

How many Models (for eg. Generic, Lighting) will show case under #LTS ?
There's really not much "secret" stuff when it comes to the release,
i.e. something that would only be "revealed" at the last moment (the way
you make it sound). A lot of what you'll get is what you can see already
now in the master branch.

What will be status of Friend & Low Power Nodes implementation ?
Both of those are complete and passing the PTS tests for them.

Johan

3501 - 3520 of 8033