Date   

Re: #BluetoothMesh persistent storage for provisioning data #bluetoothmesh

Johan Hedberg
 

Hi Kai,

Please check the PR I referenced earlier. I've added a patch there to
convert mesh_demo to use settings. It was actually the other way around
that it made sense to do the calls: first settings_load() and then
bt_mesh_provision(). That way we can catch an -EALREADY return from
bt_mesh_provision() which tells us that calling configure() should not
be done.

Johan

On Fri, May 11, 2018, Kai Ren wrote:
Thanks for the reply!

The problem I suffered is that: when I run mesh_demo on microbit, I can't restore SEQ after a reset, when means that if a GenericOnOff client reset unexpected, I need to make this client catch up the SEQ on GenericOnOff server. 

I saw that there are two functions which seem to be store and restore SEQ,

void board_seq_update( u32_t seq);

static u32_t get_seq( void );

but get_seq() is called in board initial, but I don't find any piece about board_seq_update().

I agree with you, mesh_demo doesn't need persistent storage because its netkey, devkey and appkey are already in flash memory, but one thing need to be solved is SEQ. 


Also, if you run it on the BBC micro:bit be sure to remove
the direct flash access from src/microbit.c.
What does it mean? 

Kai


Re: #BluetoothMesh persistent storage for provisioning data #bluetoothmesh

Kai Ren
 

Thanks for the reply!

The problem I suffered is that: when I run mesh_demo on microbit, I can't restore SEQ after a reset, when means that if a GenericOnOff client reset unexpected, I need to make this client catch up the SEQ on GenericOnOff server. 

I saw that there are two functions which seem to be store and restore SEQ,

void board_seq_update(u32_t seq);

static u32_t get_seq(void);

but get_seq() is called in board initial, but I don't find any piece about board_seq_update().

I agree with you, mesh_demo doesn't need persistent storage because its netkey, devkey and appkey are already in flash memory, but one thing need to be solved is SEQ. 
Also, if you run it on the BBC micro:bit be sure to remove
the direct flash access from src/microbit.c.
What does it mean? 

Kai




Re: #BluetoothMesh persistent storage for provisioning data #bluetoothmesh

Johan Hedberg
 

Hi Kai,

On Fri, May 11, 2018, Kai Ren wrote:
I noticed that zephyr start to support persistent storage for
provisioning data like:
{ "Net", net_set },
{ "IV", iv_set },
{ "Seq", seq_set },
{ "RPL", rpl_set },
{ "NetKey", net_key_set },
{ "AppKey", app_key_set },
Also note that the remaining state storing is coming as part of the
following PR:

https://github.com/zephyrproject-rtos/zephyr/pull/7428

Essentially everything is in place there now, but I still need to think
a little about how to handle IV Update - we may need to store in some
circumstances information about how many hours the node has been in a
certain state.

And I know that it's already added in the sample of
./sample/bluetooth/mesh/, I know that this sample need a provisioner
to provision it. I'm curious that does the persistent storage function
can be used by the sample of ./sample/bluetooth/mesh_demo/ because
this sample is an example of self-provisioning.
I think there might be some conflicts, or at least interesting
artifacts, since mesh_demo calls itself bt_mesh_provision() and
restoring values from flash does essentially the same thing. That said,
I'm not sure what the benefit would be? Perhaps to restore the Seq and
RPL? You could try it, but be sure to call settings_load() only after
bt_mesh_provision() so that stored values overwrite the ones hard-coded
in the app. Also, if you run it on the BBC micro:bit be sure to remove
the direct flash access from src/microbit.c.

Johan


#BluetoothMesh persistent storage for provisioning data #bluetoothmesh

Kai Ren
 

Hello,

I noticed that zephyr start to support persistent storage for provisioning data like:
{ "Net", net_set },
{ "IV", iv_set },
{ "Seq", seq_set },
{ "RPL", rpl_set },
{ "NetKey", net_key_set },
{ "AppKey", app_key_set },

And I know that it's already added in the sample of ./sample/bluetooth/mesh/, I know that this sample need a provisioner to provision it. I'm curious that does the persistent storage function can be used by the sample of ./sample/bluetooth/mesh_demo/ because this sample is an example of self-provisioning.
Thanks.

Regards,
Kai


Re: Can't download in chuncks using https

christian tavares
 

I was able to resolve this problem by configuring the server to send smaller fragments than it was sending


Re: new PR adding initial dts support for nrf52 gpio, needs reviewer(s)

Carles Cufi
 

Hi Marc,

 

Thanks very much for your PR. Since you cannot add reviewers yourself I have added them for you.

 

Regards,

 

Carles

 

From: <devel@...> on behalf of Marc Reilly <marc.reilly@...>
Date: Thursday, 10 May 2018 at 10:28
To: "devel@..." <devel@...>
Subject: [Zephyr-devel] new PR adding initial dts support for nrf52 gpio, needs reviewer(s)

 

Hi,

I've just added PR #7444 (https://github.com/zephyrproject-rtos/zephyr/pull/7444), but I'm not sure who to ask as reviewer(s). So, I'd like to make an appeal to anyone who is interested in bringing nrf52 devices into using device tree to have a look and give some advice.

Its a small change, but already it means for example that nrf boards could use the "gpio-leds" dt binding to generate some defines for leds.

Next steps are to support pin selection for common drivers like uart, spi, i2c, etc. as well as pin selection for interrupts etc.

All and any feedback will be much appreciated..

I also invite anyone to ask me to review theirs, although I'm still a novice here.

 

Cheers

Marc

 

 


new PR adding initial dts support for nrf52 gpio, needs reviewer(s)

Marc Reilly
 

Hi,

I've just added PR #7444 (https://github.com/zephyrproject-rtos/zephyr/pull/7444), but I'm not sure who to ask as reviewer(s). So, I'd like to make an appeal to anyone who is interested in bringing nrf52 devices into using device tree to have a look and give some advice.

Its a small change, but already it means for example that nrf boards could use the "gpio-leds" dt binding to generate some defines for leds.

Next steps are to support pin selection for common drivers like uart, spi, i2c, etc. as well as pin selection for interrupts etc.

All and any feedback will be much appreciated..
I also invite anyone to ask me to review theirs, although I'm still a novice here.

Cheers
Marc



Read connection RSSI always return -127

전형욱
 

Hello,

I wrote the same question on user forum but haven't got any response so I'm writing this on devel forum, too.

I'm developing HCI UART dongle using nRF52840 based on Zephyr v1.11 branch.
Everything works fine now except for reading RSSI on connected device.

HCI commands were successfully executed but always return -127.

< HCI Command: Read RSSI (0x05|0x0005) plen 2            #488 [hci1] 620.325803
        Handle: 0
> HCI Event: Command Complete (0x0e) plen 7              #489 [hci1] 620.326563
      Read RSSI (0x05|0x0005) ncmd 1
        Status: Success (0x00)
        Handle: 0
        RSSI: -127 dBm (0x81)
It is the same on nRF52840_pca10056 reference board.

Here are contents of prj.conf file.
CONFIG_CONSOLE=n
CONFIG_STDOUT_CONSOLE=n
CONFIG_UART_CONSOLE=n
CONFIG_GPIO=y
CONFIG_SERIAL=y
CONFIG_UART_INTERRUPT_DRIVEN=y
CONFIG_UART_NRF5_BAUD_RATE=1000000
CONFIG_UART_NRF5_FLOW_CONTROL=y
CONFIG_MAIN_STACK_SIZE=512
CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=512
CONFIG_BT=y
CONFIG_BT_HCI_RAW=y
CONFIG_BT_MAX_CONN=16
CONFIG_BT_TINYCRYPT_ECC=y
CONFIG_BT_CTLR_DTM_HCI=y
CONFIG_BT_CTLR_ASSERT_HANDLER=n
CONFIG_BT_HCI_ACL_FLOW_CONTROL=y
CONFIG_BT_CTLR_DATA_LENGTH=y
CONFIG_BT_CTLR_DATA_LENGTH_MAX=251
CONFIG_BT_CTLR_GPIO_LNA=y
CONFIG_BT_CTLR_GPIO_LNA_PIN=28
CONFIG_BT_CTLR_GPIO_PA=y
CONFIG_BT_CTLR_GPIO_PA_PIN=3
CONFIG_CLOCK_CONTROL_NRF5_K32SRC_RC=y
CONFIG_CLOCK_CONTROL_NRF5_K32SRC_250PPM=y
CONFIG_BT_CTLR_ADVANCED_FEATURES=y
CONFIG_BT_CTLR_CONN_RSSI=y

Is there anything that I need to configure in project setting?

Regards,

Hyoungwook Jeon



1.12 merge window closing soon

Maureen Helm
 

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

 


Can't download in chuncks using https

christian tavares
 

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

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
 

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

 

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
 

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

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

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

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
 

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

 

4081 - 4100 of 8627