devel@lists.zephyrproject.org

1.12 merge window closing soon

Maureen Helm

#2165

The Zephyr 1.12 release feature merge window is due to close soon. Our original schedule had this milestone set for today, but the TSC agreed to extend the merge window by one week to allow a few remaining 1.12 roadmap features to make it in. These features include OpenAMP (#3065) and full persistent storage for Bluetooth (#7073).

If you have any new features in the works that you would like to get into the 1.12 release, please submit a PR as soon as possible. After the feature merge window closes on Friday May 18, we will only merge bug fixes and documentation until the release. Please also help out by reviewing PRs from other contributors. Even if you do not have merge privileges, it is a big help if you review and vote on PRs.

Thanks for all your contributions!

Schedule:

https://github.com/zephyrproject-rtos/zephyr/wiki/Program-Management

Roadmap:

https://github.com/zephyrproject-rtos/zephyr/projects/9

smime.p7s

Can't download in chuncks using https

christian tavares

#2164

I'm developing an http_client library, this library needs to download a flash image on the server and install the image on the card.

When I download the flash image from the server if it is larger than the request_buf of the http_client_set_tls function, an error occurs to save the encrypted packets on the stack. I would like to know if you have a way to download the larger image by checking the encryption in pieces?

I've been researching a lot how to solve this case, but I have not found a solution. I'll be grateful if anyone can find a solution. Below I am sending what happens.

[https/client] [DBG] on_status: (0x2000d1c4): HTTP response status OK

[https/client] [DBG] print_header_field: (0x2000d1c4): [12] X-Powered-By

[https/client] [DBG] print_header_field: (0x2000d1c4): [7] Express

[https/client] [DBG] print_header_field: (0x2000d1c4): [13] Accept-Ranges

[https/client] [DBG] print_header_field: (0x2000d1c4): [5] bytes

[https/client] [DBG] print_header_field: (0x2000d1c4): [13] Cache-Control

[https/client] [DBG] print_header_field: (0x2000d1c4): [17] public, max-age=0

[https/client] [DBG] print_header_field: (0x2000d1c4): [13] Last-Modified

[https/client] [DBG] print_header_field: (0x2000d1c4): [29] Thu, 08 Mar 2018 19:14:53 GMT

[https/client] [DBG] print_header_field: (0x2000d1c4): [4] ETag

[https/client] [DBG] print_header_field: (0x2000d1c4): [21] W/"60000-16207099be3"

[https/client] [DBG] print_header_field: (0x2000d1c4): [12] Content-Type

[https/client] [DBG] print_header_field: (0x2000d1c4): [24] application/octet-stream

[https/client] [DBG] print_header_field: (0x2000d1c4): [14] Content-Length

[https/client] [DBG] print_header_field: (0x2000d1c4): [6] 393216

[https/client] [DBG] print_header_field: (0x2000d1c4): [4] Date

[https/client] [DBG] print_header_field: (0x2000d1c4): [29] Tue, 08 May 2018 21:02:56 GMT

[https/client] [DBG] print_header_field: (0x2000d1c4): [10] Connection

[https/client] [DBG] print_header_field: (0x2000d1c4): [5] close

[https/client] [DBG] on_headers_complete: (0x2000d1c4): Headers complete

[net/app] [DBG] _net_app_tls_received: (0x2000be5c): Encrypted data received in pkt 0x2000f714

[net/app] [DBG] _net_app_ssl_mux: (0x2000d1c4): Receiving encrypted data in pkt 0x2000f714 (len 576)

[net/app] [DBG] my_debug: (0x2000d1c4): ssl_tls.c:3572: |1| bad message length

[net/app] [DBG] my_debug: (0x2000d1c4): ssl_tls.c:3783: |1| mbedtls_ssl_read_record_layer() returned -29184 (-0x7200)

[net/app] [DBG] my_debug: (0x2000d1c4): ssl_tls.c:6944: |1| mbedtls_ssl_read_record() returned -29184 (-0x7200)

[net/app] [ERR] _net_app_ssl_mainloop: mbedtls_ssl_read returned -0x7200 (SSL - An invalid SSL record was received)

[net/app] [ERR] _net_app_ssl_mainloop: Closing connection -0x7200 (SSL - An invalid SSL record was received)

[net/app] [ERR] tls_client_handler: TLS mainloop startup failed (-29184)

[net/app] [DBG] tls_client_handler: (0x2000d1c4): Shutting down TLS handler

[https/client] [DBG] http_closed: (0x2000d1c4): [0x2000d118] connection closed

[net/app] [DBG] _net_app_tls_handler_stop: (0x2000d1c4): TLS thread 0x2000d1c4 stopped

[net/app] [DBG] _net_app_tls_received: (0x2000be5c): Encrypted data received in pkt 0x2000f768

[net/app] [DBG] _net_app_tls_received: (0x2000be5c): Encrypted data received in pkt 0x2000f714

[net/app] [DBG] _net_app_tls_received: (0x2000be5c): Encrypted data received in pkt 0x2000f6c0

[net/app] [DBG] _net_app_tls_received: (0x2000be5c): Encrypted data received in pkt 0x2000f66c

[net/app] [DBG] _net_app_tls_received: (0x2000be5c): Encrypted data received in pkt 0x2000f618

[net/app] [DBG] _net_app_tls_received: (0x2000be5c): Encrypted data received in pkt 0x2000f5c4

[net/app] [DBG] _net_app_tls_received: (0x2000be5c): Encrypted data received in pkt 0x2000f570

[net/app] [DBG] _net_app_tls_received: (0x2000be5c): Encrypted data received in pkt 0x2000f51c

[net/app] [DBG] _net_app_tls_received: (0x2000be5c): Encrypted data received in pkt 0x2000f4c8

[net/app] [DBG] _net_app_tls_received: (0x2000be5c): Encrypted data received in pkt 0x2000f474

[net/app] [DBG] _net_app_tls_received: (0x2000be5c): Encrypted data received in pkt 0x2000f420

[net/app] [DBG] _net_app_tls_received: (0x2000be5c): Encrypted data received in pkt 0x2000f3cc

[net/app] [DBG] _net_app_tls_received: (0x2000be5c): Encrypted data received in pkt 0x2000f378

[net/app] [DBG] _net_app_tls_received: (0x2000be5c): Encrypted data received in pkt 0x2000f324

Here shows the size that defined the variables used by the functions:

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,

setup_cert,

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);

The install_update_cb function is responsible for downloading parts of the image and saving this image in flash area 1.

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: Kconfig changes on master

Carles Cufi

#2163

Hi there,

CMake is the build system, Kconfig is the configuration system. Kconfig is run by CMake as one of the first things it does in order to figure out what needs to be built and how.

More information can be found here:

http://docs.zephyrproject.org/application/application.html#cmake-details

http://docs.zephyrproject.org/application/application.html#application-configuration

Regards,

Carles

Show quoted text

From: jack ma <assangema@...>
Sent: 08 May 2018 12:29
To: Cufi, Carles <carles.cufi@...>
Cc: devel@...; users@...
Subject: Re: [Zephyr-devel] Kconfig changes on master

Hi,

What is the relationship cmake and kconfig ? both of them can be used to configure Zephyr ?

Are they alternative or dependent?

Thanks.

2018-05-08 4:02 GMT+08:00 Cufi, Carles <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: Kconfig changes on master

jack ma

#2162

Hi,

What is the relationship cmake and kconfig ? both of them can be used to configure Zephyr ?

Are they alternative or dependent?

Thanks.

2018-05-08 4:02 GMT+08:00 Cufi, Carles <carles.cufi@...>:

Show quoted text

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: Extending Error Codes

Zięcik, Piotr <piotr.ziecik@...>

#2161

Show 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.

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/? Hi.

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

#2160

Hi Erwan,

Having direct match between generated FLAGS/INT_CONF aliases and application symbols would be a good idea.
Though not sure which should converge to the other.
INT_CONF (Interrupt configuration I guess) is more restrictive than FLAGS.
Impacted field is used to configure GPIO in general, not interrupt only, so a more generic name might be a better choice.

I agree with you about using a more generic name (FLAGS). So basically we will need to update the "samples/basic/button/src/main.c" (SW0_GPIO_INT_CONF ->SW0_GPIO_FLAGS) application and move all SW0_GPIO_INT_CONF definitions from board.h to the respective dts file?

Does anyone have a better idea?

Regards,

--
*dS
Diego Sueiro

CEO do Embarcados

www.embarcados.com.br

/*long live rock 'n roll*/

On 4 May 2018 at 09:34, Erwan Gouriou <erwan.gouriou@...> wrote:

Hi Diego,

Having direct match between generated FLAGS/INT_CONF aliases and application symbols would be a good idea.
Though not sure which should converge to the other.
INT_CONF (Interrupt configuration I guess) is more restrictive than FLAGS.
Impacted field is used to configure GPIO in general, not interrupt only, so a more generic name might be a better choice.

Erwan

On 4 May 2018 at 07:33, Diego Sueiro <diego.sueiro@...> wrote:
Hello,

I'd like to know what is the usage of the *_GPIO_FLAGS macro.

For example in "dts/bindings/gpio/nxp,kinetis-gpio.yaml" file:

cell_string: GPIO
"#cells":
- pin
- flags

And "boards/arm/frdm_k64f/frdm_k64f.dts" file we have
gpios = <&gpioa 4 GPIO_INT_ACTIVE_LOW>;

This will generate in "zephyr/include/generated/generated_dts_board.h":
#define GPIO_KEYS_1_GPIO_CONTROLLER "GPIO_0"
#define GPIO_KEYS_1_GPIO_FLAGS_0 0
#define GPIO_KEYS_1_GPIO_PIN_0 4
#define GPIO_KEYS_1_LABEL "User SW3"
#define GPIO_KEYS_1_GPIO_FLAGS GPIO_KEYS_1_GPIO_FLAGS_0
#define GPIO_KEYS_1_GPIO_PIN GPIO_KEYS_1_GPIO_PIN_0
#define SW0_GPIO_CONTROLLER GPIO_KEYS_1_GPIO_CONTROLLER
#define SW0_GPIO_FLAGS GPIO_KEYS_1_GPIO_FLAGS
#define SW0_GPIO_PIN GPIO_KEYS_1_GPIO_PIN
#define SW0_LABEL GPIO_KEYS_1_LABEL

In this example SW0_GPIO_FLAGS is not "consumed" by any source code, but "samples/basic/button/src/main.c" application is using SW0_GPIO_CONTROLLER, SW0_GPIO_PIN and SW0_GPIO_INT_CONF.

I think we should name this gpio dts cell as "int_conf" instead of "flags", this way the dts configuration will be used in the button application, for example.

Regards,

--
*dS
Diego Sueiro

CEO do Embarcados
www.embarcados.com.br

/*long live rock 'n roll*/

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

Leandro Pereira

#2159

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

#2158

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

Show quoted text

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

#2157

I can't reproduce this.

Does doing a clean build help?

Is this sample built by our CI?

Andrew

Show quoted text

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

#2156

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

#2155

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@...>

#2154

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

Show quoted text

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

#2153

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

#2152

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

#2151

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

Show quoted text

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

#2150

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

#2149

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

#2148

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,

setup_cert,

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

OSSystems/zephyr

github.com

zephyr - Primary GIT Repository for the Zephyr Project

Re: mbedtls problem

Paul Sokolovsky

#2147

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,

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

#2146

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