|
Re: Extending Error Codes
Zięcik, Piotr <piotr.ziecik@...>
toggle quoted messageShow quoted text
-----Original Message-----
From: Cufi, Carles Sent: Monday, May 07, 2018 11:57 AM To: Zięcik, Piotr <Piotr.Ziecik@...>; Puzdrowski, Andrzej <Andrzej.Puzdrowski@...>; devel@... Subject: RE: [Zephyr-devel] Extending Error Codes Hi.Hi.I agree. I think a single set of generic error codes that are flexible enough to convey the message are a better approach. I have looked into the error list available in ./lib/libc/minimal/include/errno.h and it looks that there are plenty of errors defined, however most of these defines are rather high-level. If this is not enough, I could recommend following the Linux approach, which in my opinion is pretty simple and gives some flexibility: We can divide the error lists in 2 parts, listed in 2 different files. The first file, will cover generic, high level errors (and could be provided by libc). The second file will be zephyr-specific. There should be also single errno.h header, which will include both libc and zephyr headers. What do you think? Best Regards, Piotr Zięcik.
|
|||
|
|
|||
|
Re: Usage of generated dts *_GPIO_FLAGS
Diego Sueiro
Hi Erwan, Having direct match between generated FLAGS/INT_CONF aliases and application symbols would be a good idea. I agree with you about using a more generic name (FLAGS). So basically we will need to update the "samples/basic/button/src/ Does anyone have a better idea? On 4 May 2018 at 09:34, Erwan Gouriou <erwan.gouriou@...> wrote:
|
|||
|
|
|||
|
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’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
Pulled master and went to build OpenThread echo server and get a ton of the following: __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: __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@... on behalf of Sebastian Boe" <devel@... on behalf of Sebastian.Boe@...> 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@... <devel@...> on behalf of Abderrezak Mekkaoui <ab.mekka@...> Sent: Monday, 7 May 2018 6:04:36 PM To: devel@... 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
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
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@... <devel@...> on behalf of Abderrezak Mekkaoui <ab.mekka@...> Sent: Monday, 7 May 2018 6:04:36 PM To: devel@... 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
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_SIZE = MBEDTLS_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
|
|||
|
|
|||
|
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@...> wrote: Hi,-- 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,
toggle quoted messageShow quoted text
-----Original Message-----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
|
|||
|
|
|||
|
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: __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
|
|||
|
|
|||
