Hi all,

This is the current bug status for Zephyr 2.3 as of today.

High priority bugs: 8 (threshold for release is ==0)
https://github.com/zephyrproject-rtos/zephyr/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+label%3Abug+label%3A%22priority%3A+high%22+sort%3Aupdated-desc+-milestone%3Av1.14.1+-milestone%3Av1.14.2+

Medium priority bugs: 43 (threshold for release is <=20)
https://github.com/zephyrproject-rtos/zephyr/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+label%3Abug+label%3A%22priority%3A+medium%22+sort%3Aupdated-desc+-milestone%3Av1.14.1+-milestone%3Av1.14.2+

Since we are currently quite far away from the required thresholds in order to release 2.3.0, I would like to ask you all to go through the bug lists and try to fix (or close if they are no long applicable) as many as possible so that we do not need to delay the current tentative release date of May 29th.

Thank you all in advance.

Carles

On May 13, 2020, at 9:56 PM, Kumar Gala via lists.zephyrproject.org <kumar.gala=linaro.org@lists.zephyrproject.org> wrote:

Here’s the agenda topics for this week:

* Review PR/issues’s tagged with dev-review:

* Support for buildtesting SoCs w/o boards
https://github.com/zephyrproject-rtos/zephyr/issues/25153

* Remove `default:` functionality from devicetree bindings
https://github.com/zephyrproject-rtos/zephyr/issues/25164

* Any 2.3 issues that need discussion

* Any 2.4 topics / initial plans of activity.

* Any topics anyone else has.

Adding the following to the agenda:

* RFC: device: convert device struct instances to const
https://github.com/zephyrproject-rtos/zephyr/pull/25208

- k

Reminder: Zephyr Project: Dev Meeting

When: Thursday, 14 May 2020, 8:00am to 9:00am, (GMT-07:00) America/Los Angeles

Where:Microsoft Teams Meeting

An RSVP is requested. Click here to RSVP

Organizer: devel@...

Description: Join Microsoft Teams Meeting: https://teams.microsoft.com/l/meetup-join/19%3ameeting_M2Q2ZDk4OWItMWE2MS00MTExLTkyYTQtNmUwOTA4MzgwOGYw%40thread.v2/0?context=%7b%22Tid%22%3a%22686ea1d3-bc2b-4c6f-a92c-d99c5c301635%22%2c%22Oid%22%3a%2262b63b80-05d3-4465-b5a0-f04e4e156f10%22%7d

+1 213-437-3346 United States, Los Angeles (Toll)
Conference ID: 750 623 026#

Local numbers: https://dialin.teams.microsoft.com/488d1b50-0dd2-4ca1-aee4-92bb50a48081?id=750623026

Zephyr Toolchain Working Group

When:
Thursday, 14 May 2020
7:00am to 8:00am
(GMT-07:00) America/Los Angeles

Where:
Microsoft Teams Meeting

Description:
Topic:  Zephyr Toolchain Working Group

Time: Mar 19, 2020 07:00 AM Pacific Time (US and Canada)

        Every 2 weeks on Thu, until Jul 23, 2020, 10 occurrence(s)

        Mar 19, 2020 07:00 AM

        Apr 2, 2020 07:00 AM

        Apr 16, 2020 07:00 AM

        Apr 30, 2020 07:00 AM

        May 14, 2020 07:00 AM

        May 28, 2020 07:00 AM

        Jun 11, 2020 07:00 AM

        Jun 25, 2020 07:00 AM

        Jul 9, 2020 07:00 AM

        Jul 23, 2020 07:00 AM

Join Microsoft Teams Meeting: https://teams.microsoft.com/l/meetup-join/19%3ameeting_ZGRjNzNjMjEtOWJmMi00ODUxLWE2MjEtODM0M2FiMzQxMjE5%40thread.v2/0?context=%7b%22Tid%22%3a%22686ea1d3-bc2b-4c6f-a92c-d99c5c301635%22%2c%22Oid%22%3a%2262b63b80-05d3-4465-b5a0-f04e4e156f10%22%7d

+1 213-437-3346 United States, Los Angeles (Toll)
Conference ID: 570 955 823#

Local numbers: https://dialin.teams.microsoft.com/488d1b50-0dd2-4ca1-aee4-92bb50a48081?id=570955823

Live meeting minutes: https://docs.google.com/document/d/1IQKBK-GcJNZG0O9QArqYfvb6Huk5xHscN-XIGEZr-z8/edit#heading=h.x36xe8bnwr9r

Reminder: Zephyr Toolchain Working Group

When: Thursday, 14 May 2020, 7:00am to 8:00am, (GMT-07:00) America/Los Angeles

Where:Microsoft Teams Meeting

View Event

Organizer: Maureen Helm

Description: Topic:  Zephyr Toolchain Working Group

Time: Mar 19, 2020 07:00 AM Pacific Time (US and Canada)

        Every 2 weeks on Thu, until Jul 23, 2020, 10 occurrence(s)

        Mar 19, 2020 07:00 AM

        Apr 2, 2020 07:00 AM

        Apr 16, 2020 07:00 AM

        Apr 30, 2020 07:00 AM

        May 14, 2020 07:00 AM

        May 28, 2020 07:00 AM

        Jun 11, 2020 07:00 AM

        Jun 25, 2020 07:00 AM

        Jul 9, 2020 07:00 AM

        Jul 23, 2020 07:00 AM

Join Microsoft Teams Meeting: https://teams.microsoft.com/l/meetup-join/19%3ameeting_ZGRjNzNjMjEtOWJmMi00ODUxLWE2MjEtODM0M2FiMzQxMjE5%40thread.v2/0?context=%7b%22Tid%22%3a%22686ea1d3-bc2b-4c6f-a92c-d99c5c301635%22%2c%22Oid%22%3a%2262b63b80-05d3-4465-b5a0-f04e4e156f10%22%7d

+1 213-437-3346 United States, Los Angeles (Toll)
Conference ID: 570 955 823#

Local numbers: https://dialin.teams.microsoft.com/488d1b50-0dd2-4ca1-aee4-92bb50a48081?id=570955823

Live meeting minutes: https://docs.google.com/document/d/1IQKBK-GcJNZG0O9QArqYfvb6Huk5xHscN-XIGEZr-z8/edit#heading=h.x36xe8bnwr9r

Here’s the agenda topics for this week:

* Review PR/issues’s tagged with dev-review:

* Support for buildtesting SoCs w/o boards
https://github.com/zephyrproject-rtos/zephyr/issues/25153

* Remove `default:` functionality from devicetree bindings
https://github.com/zephyrproject-rtos/zephyr/issues/25164

* Any 2.3 issues that need discussion

* Any 2.4 topics / initial plans of activity.

* Any topics anyone else has.

- k

Thanks for the feedback. I will go ahead and create an issue on github to describe the issue and show what I have tried so far.

Thanks!
Brian

So I think there are a few things going on here, and have begun to unravel it but I might need some guidance on how to proceed. 

I intend to utilize the STM32F411E MCU on an upcoming board, but I wanted to test the DISCO board in zephyr to get a feel for it first. One of the features I will need is USB, which the DISCO board appears to have available in the form of an OTG port. I only need the cdc mode of operation, so I think this shouldn't be too difficult of a task.

I pretty quickly realized that USB wasn't supported on this board on latest version of zephyr (2.3-rc0), so I started by trying to add it. I was able to get it compiled pretty quickly with some changes to the dts and pinmux.c by referencing other implementations and the datasheet for the MCU. 

So after some minor changes, I was able to get it to compile without any problems. Upon flashing it to the board *something* appears to be happening, but I am not sure if there is more that I am missing. Right now, the USB_OTG LED is illuminating on the DISCO board, which I think indicates something is happening, and the Device Manager (Windows 10) is recognizing a device, which is also good. But it is unable to setup the device and giving a "Device Descriptor Request Failed" error. I am curious if I am missing some additional steps to properly implement USB, and if I should possibly start an issue and work towards a PR on github.

Thanks for any advice!
Brian

As part of the SDK 0.11.x SDK we moved from python2.7 to python3.6 as the version of python that GDB is linked against, partially due to the deprecation of python2.7.

There have been several issues opened about this on various Linux distributions. It was suggested that Python3.8 would be a better choice since there are options on most of the major distribution versions to install a python3.8 package.

I wanted to see if this change caused any major concerns.

If you want to test out the python3.8 version, here’s a link a test SDK build:

https://builds.zephyrproject.org/zephyrproject-rtos/sdk-ng/210/zephyr-sdk-0.11.3-beta-1-pr-210-setup.run

Please let me know by end of Thur (May 14th) if you have concerns.

Thanks

- k

Reminder: Zephyr Project: APIs

When: Tuesday, 12 May 2020, 9:00am to 10:00am, (GMT-07:00) America/Los Angeles

Where:Microsoft Teams Meeting

An RSVP is requested. Click here to RSVP

Organizer: devel@...

Description: Join Microsoft Teams Meeting:
https://teams.microsoft.com/l/meetup-join/19%3ameeting_YzYzZTAzNGItOWFiMS00MDBkLTkyYmMtNzljZjkwNDVlMThm%40thread.v2/0?context=%7b%22Tid%22%3a%22686ea1d3-bc2b-4c6f-a92c-d99c5c301635%22%2c%22Oid%22%3a%2262b63b80-05d3-4465-b5a0-f04e4e156f10%22%7d

+1 213-437-3346 United States, Los Angeles (Toll)
Conference ID: 262 362 129#

Local numbers: https://dialin.teams.microsoft.com/488d1b50-0dd2-4ca1-aee4-92bb50a48081?id=262362129

---

 Live meeting minutes: https://docs.google.com/document/d/1lv-8B5QE2m4FjBcvfqAXFIgQfW5oz6306zJ7GIZIWCk/edit?usp=sharing

Hi all,

*************************************************
We will be using Teams instead of Zoom:
https://teams.microsoft.com/l/meetup-join/19%3ameeting_YzYzZTAzNGItOWFiMS00MDBkLTkyYmMtNzljZjkwNDVlMThm%40thread.v2/0?context=%7b%22Tid%22%3a%22686ea1d3-bc2b-4c6f-a92c-d99c5c301635%22%2c%22Oid%22%3a%2262b63b80-05d3-4465-b5a0-f04e4e156f10%22%7d
*************************************************

Today's topics:

- dma: enable edma drivers for mcux
- PR https://github.com/zephyrproject-rtos/zephyr/pull/23689

- Documenting API behavior in Doxygen:
- Issue: https://github.com/zephyrproject-rtos/zephyr/issues/18970
- Issue: https://github.com/zephyrproject-rtos/zephyr/issues/21061

- RTC API follow-up (if the relevant people are present and there is material for discussion)
- PR: https://github.com/zephyrproject-rtos/zephyr/pull/23526

Additional items in the "Triage" column in the GitHub project may be discussed if time permits.
If you want an item included in the meeting, please add it to the GitHub project.

https://github.com/zephyrproject-rtos/zephyr/wiki/Zephyr-Committee-and-Working-Group-Meetings#zephyr-api-discussion
https://github.com/zephyrproject-rtos/zephyr/projects/18
https://docs.google.com/document/d/1lv-8B5QE2m4FjBcvfqAXFIgQfW5oz6306zJ7GIZIWCk/edit

Regards,

Carles

Hi all,

I'd like to ask you to set the milestone in all Pull Requests that need to be merged during the stabilization period (be them bugfix and documentation or special cases, in which case they also require the "TSC" label).
This will help filter out any PRs that can wait until 2.3 is released, thus alleviating the burden on reviewers and maintainers.

Thanks in advance.

Regards,

Carles

Hi Jukka
And thank you very much for your very quick answer.
I am sorry I haven't repsonded before, but we had a national Holiday in Denmark Friday the 8th.

I will try to answer on your comments.

Regarding the buffer counts, having a value of 14 is written in the documentation of zephyr 2.2.0 as the link below shows.
https://docs.zephyrproject.org/2.2.0/reference/kconfig/CONFIG_NET_PKT_RX_COUNT.html?highlight=config_net_pkt_rx_count#cmdoption-arg-config-net-pkt-rx-count

Regarding the buffer counts, having a value of 36 is written in the documentation of zephyr 2.2.0 as the link below shows.
https://docs.zephyrproject.org/2.2.0/reference/kconfig/CONFIG_NET_BUF_TX_COUNT.html?highlight=config_net_buf_tx_count#cmdoption-arg-config-net-buf-tx-count

We are already using a maximum heap size for CONFIG_MBEDTLS_HEAP_SIZE of 65356.
CONFIG_MBEDTLS_SSL_MAX_CONTENT_LEN is set to 8196.
And it is the same configuration in both Ethernet and GSM modem.

Using the maximum value of 16384 for CONFIG_MBEDTLS_SSL_MAX_CONTENT_LEN gives another error of "<err> net_sock_tls: TLS handshake error: -4310" when running state MBEDTLS_SSL_CERTIFICATE_VERIFY.

Anyway, this is the "maximum" configuration we use now, where some buffers and also some NET RX and TX stacks are increased to the double of default.
I have disabled some shell to get more memory available for this.
And I am still stuck with the same error in the GSM modem variant.
The Ethernet variant still works perfect.

Again, I have attached the two auto generated header files, so they can be compared directly.
Basically the header file for Ethernet has some ETH related configuration and the GSM modem header has some MODEM and PPP related configuration.
I have also attached the two proj.cnf so they can be compared directly.
And basically you will see, that there is a section at the bottom for using GSM modem, which is based on the GSM_modem sample project.
And when building for Ethernet, you will see this section outcommented more or less, except for the buffers and some net stacks. The only other thing Ethernet variant has enabled is the DHCPV4.


Regarding using latest upstream zephyr version I have tried using 2.2.3rc1 and compare with 2.2.0.
I am only testing the gsm_modem sample project, but using UART 3 on the frdm_k64f board, which is compatible with Arduino pinout, which my modem shield uses.

Using an oscilloscope, no data is sent out on UART 3 for communicating with the modem shield, when I test with zephyr 2.2.3rc1.
Everything works fine with zephyr version 2.2.0 and I can use the net shell to ping some IP addresses, meaning the modem is being configured correct via PPP over UART 3.

What am I missing in order to sent out data on UART 3 on the frdm_k64f board??
 
There are some changes to the configuration of UART 3 between zephyr 2.2.3rc1 and 2.2.0.

In zephyr 2.2.0 the following configuration parameters are needed to make the UART 3 work, which can be seen in the attahced proj.2.2.0.conf for the gms_modem sample project:
CONFIG_SERIAL=y CONFIG_UART_MCUX_3=y CONFIG_MODEM_GSM_UART_NAME="UART_3" 

In zephyr 2.2.3rc1 it seems like CONFIG_UART_MCUX_3=y is no longer needed and I only have to set the two other configuration parameters, which can be seen in the attached proj.2.2.3rc1.conf for the gms_modem sample project: CONFIG_SERIAL=y CONFIG_MODEM_GSM_UART_NAME="UART_3"

I hope to get 2.2.3rc1 up and running to see if it solves my issues with mbedtls certificate handshaking, as you also suggest as first thing to try.

Best regards,
Bo

> I'm not quite sure what you are trying to mitigate, exactly.  This is the desired behavior.  You WANT your two custom threads to run instead of  your main thread, that's why they're higher priority.

I think the mitigation is of Zephyr's default behavior: that the main thread is preemptible by default.  I've also run into this where starting a repeating timer with no initial delay in main caused a work item to be submitted (from interrupt) and started (from system work thread, which is default cooperative) before I'd finished configuring the work item back in main.

Not that it's wrong, but it's unexpected to have main be preemptible, and since every thread declared in the samples and drivers is cooperative people just starting with threads are likely to make this "mistake".

Peter

Your understanding is correct.  If a higher priority thread is available to run, then a preemptible thread will yield to that thread at every scheduling point.

I'm not quite sure what you are trying to mitigate, exactly.  This is the desired behavior.  You WANT your two custom threads to run instead of  your main thread, that's why they're higher priority.  I think you might want to revisit the priority design in your app, basically.  The priorities you've assigned to your threads don't reflect what you want them to do.

If you just need the custom threads to get out of the way at startup, why not just have them sleep a bit, or (much better) block on a semaphore or whatever waiting for main to signal them to begin.  Or you can change priorities at runtime -- have main start at a very high priority but then lower itself, for example.  Or launch the threads dynamically via k_thread_create() at runtime once you know it's safe for them to run...

Andy