Hi all,

A recent stable API has been modified to adapt it to the recent kernel timeout change.

video_dequeue() now takes a k_timeout_t instead of a u32_t for the type of the timeout parameter.

Note that if you enable `CONFIG_LEGACY_TIMEOUT_API` then k_timeout_t is reverted to be an s32_t.

Regards,

Carles

It's happening via Teams today:

*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
(
https://www.google.com/url?q=https://teams.microsoft.com/l/meetup-join/19%253ameeting_M2Q2ZDk4OWItMWE2MS00MTExLTkyYTQtNmUwOTA4MzgwOGYw%2540thread.v2/0?context%3D%257b%2522Tid%2522%253a%2522686ea1d3-bc2b-4c6f-a92c-d99c5c301635%2522%252c%2522Oid%2522%253a%252262b63b80-05d3-4465-b5a0-f04e4e156f10%2522%257d&sa=D&ust=1588427744165000&usg=AOvVaw239zM28lVIqmfqHsLzp4Yq
)


"Simon Glass via lists.zephyrproject.org"
<sjg=chromium.org@lists.zephyrproject.org> writes:

Sorry, found it in the notes!

- Simon

Reminder: Zephyr Project: Dev Meeting

When: Thursday, 7 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

Hi Kumar,

Is there a link to the meeting somewhere please?

Regards,
Simon

Here’s the agenda topics for this week:

* Review PR’s tagged with dev-review

* Any topics anyone else has.

- k

Hi Kenth,

there has not been such plans so far. Patches are welcome of course.
What kind of hw you had in mind that has multiple Ethernet sockets?


Cheers,
Jukka

Any plans to add Ethernet bridging support? I want to add VLAN sub-interfaces into a bridge.

Hi all,

This is just a reminder that the feature merge window closes tomorrow, the 8th of May.
This means that any changes that are not bugfixes or documentation changes must be merged by then.

Since I doubt I will be able to go through all GitHub emails in time for tomorrow, please make sure that your PR shows in the following filter if you want it merged:

https://github.com/zephyrproject-rtos/zephyr/pulls?q=is%3Apr+is%3Aopen+base%3Amaster+review%3Aapproved+status%3Asuccess+-label%3ADNM+draft%3Afalse++milestone%3Av2.3.0

This means that your PR must be approved, must pass CI and its milestone must be set to v2.3.0.

If you have additional requests or need help, please email me or ping me on Slack.

Regards,

Carles

Hi Bo,

some comments inline below:

On Wed, 2020-05-06 at 09:36 -0700, Bo.Kragelund@prevas.dk wrote:

Hello

I am working on an application on frdm_k64f board using official
zephyr release 2.2.0.

Can you try what you are doing using upstream master branch, it might
have issues fixed regarding what you are trying to do?

The application involves mqtt and mbedtls.
The connection is a secure connection using certificates.
The application is using either LAN with dhcpv4 client or gsm modem
with ppp.

Everything works perfect via LAN, which means
the mbedtls_ssl_handshake_client_step() function in ssl_cli.c passes
all steps of verifying certificates.

But when I use gsm modem I can connect to the network, but the
mbedtls_ssl_handshake_client_step() function stops in state
MBEDTLS_SSL_CERTIFICATE_VERIFY.
Debugging shows, that the net_ctx->flags suddenly switch from 0x14d
to 0x148, which indicates the connection is unconnected or idle, and
NET_CONMTEXT_IN_USE is also false. Please see the table of the flags
I have made here below.
In all previous states before MBEDTLS_SSL_CERTIFICATE_VERIFY, the
flags are 0x14D and every step of the
mbedtls_ssl_handshake_client_step() function works until this sudden
change in flags.

I have made sure that CONFIG_NET_PKT_RX_COUNT and
CONFIG_NET_PKT_TX_COUNT are 14 as recommended for
CONFIG_NET_L2_ETHERNET, which I then assume also applies to
NET_L2_PPP.

Where do you see a recommendation to use 14 as a value for
buffers/packets, in documentation or in samples? Usually you should use
as many network buffers as possible in your application (depending on
your application needs and device possibilities of course). The value
14 used in some sample apps, is just a reasonable working value for
some use case, but your application use case might be different.

I have also made sure that CONFIG_NET_BUF_RX_COUNT and
CONFIG_NET_BUF_TX_COUNT are 36 as recommended for
CONFIG_NET_L2_ETHERNET, which I then assume also applies to
NET_L2_PPP.

Same comment to value 36 here as for previous comment about number of
buffers.

But maybe there other CONFIG parameters I am not aware of, that need
to be adjusted. Maybe some timeout?

You could experiment with these mbedtls options. Are the values of
these same when you use Ethernet vs GSM modem?

ONFIG_MBEDTLS_HEAP_SIZE
CONFIG_MBEDTLS_SSL_MAX_CONTENT_LEN

Try increasing the max content len to 16kb, mbedtls is really memory
hungry and can fail weirdly if some buffers are not long enough.

The basic configuration was taken from the gsm_modem sample pr

oject and extended from there.
I have attached the autoconf.h so you can see the full configuration.
Hopefully someone can help me figure out, what I am missing to make
the application work with gsm modem.

I have also added my own debug code with printk, because enabling
debugging for some of the modules simply makes it impossible to
display all debug messages in a console.

Hmm, I did not quite understand this comment. If you see log messages
being dropped, try increasing these values

CONFIG_LOG_BUFFER_SIZE=65536
CONFIG_LOG_STRDUP_BUF_COUNT=100

the buf count could be even higher if you have memory.

Zephyr writes it has dumped e.g. 54 messages.
I have also attached my debug output, where each state in the
mbedtls_ssl_handshake_client_step() function is clearly identified,
and some debug info about the flags, number of bytes to send etc.
And here you can see the change in flags clearly in state
MBEDTLS_SSL_CERTIFICATE_VERIFY.

Best regards

Bo Kragelund
Prevas A/S

You can also discuss these issues in #networking or #modem channels in
Zephyr slack.


Cheers,
Jukka

Hello

I am working on an application on frdm_k64f board using official zephyr release 2.2.0.
The application involves mqtt and mbedtls.
The connection is a secure connection using certificates.
The application is using either LAN with dhcpv4 client or gsm modem with ppp.

Everything works perfect via LAN, which means the mbedtls_ssl_handshake_client_step() function in ssl_cli.c passes all steps of verifying certificates.

But when I use gsm modem I can connect to the network, but the mbedtls_ssl_handshake_client_step() function stops in state MBEDTLS_SSL_CERTIFICATE_VERIFY.
Debugging shows, that the net_ctx->flags suddenly switch from 0x14d to 0x148, which indicates the connection is unconnected or idle, and NET_CONMTEXT_IN_USE is also false. Please see the table of the flags I have made here below.
In all previous states before MBEDTLS_SSL_CERTIFICATE_VERIFY, the flags are 0x14D and every step of the mbedtls_ssl_handshake_client_step() function works until this sudden change in flags.

I have made sure that CONFIG_NET_PKT_RX_COUNT and CONFIG_NET_PKT_TX_COUNT are 14 as recommended for CONFIG_NET_L2_ETHERNET, which I then assume also applies to NET_L2_PPP.

Hi Tomasz,

Thanks for the info, link provided was very helpful.

I do have additional queries on DMA driver implementation and will send in a
separate thread for each.

Regards,
Raveendra

Reminder: Zephyr Project: APIs

When: Tuesday, 5 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

Updated agenda:

- RFC: API change: Add I2C bus recovery API
- Issue: https://github.com/zephyrproject-rtos/zephyr/issues/23441
- PR: https://github.com/zephyrproject-rtos/zephyr/pull/23442

- RFC: use compatible name for prefix for device-specific API
- PR: https://github.com/zephyrproject-rtos/zephyr/issues/24978

- 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

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

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:

- RFC: use compatible name for prefix for device-specific API
- PR: https://github.com/zephyrproject-rtos/zephyr/issues/24978

- 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

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

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,

There is a network forum meeting tomorrow 5 May at 8AM PDT / 17.00 CET.

We will be using Teams instead of Zoom:
________________________________________________________________
Join Microsoft Teams Meeting<
https://teams.microsoft.com/l/meetup-join/19%3ameeting_ODE2MzMzZmItYWZjNC00N2E5LThjZjAtNGY3YTJkNDhlYTQw%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<tel:+1%20213-437-3346,,335898965#> United States, Los
Angeles (Toll)
Conference ID: 335 898 965#
Local numbers<
https://dialin.teams.microsoft.com/488d1b50-0dd2-4ca1-aee4-92bb50a48081?id=335898965

| Reset PIN<https://mysettings.lync.com/pstnconferencing> | Learn

more about Teams<https://aka.ms/JoinTeamsMeeting> | Meeting options<
https://teams.microsoft.com/meetingOptions/?organizerId=62b63b80-05d3-4465-b5a0-f04e4e156f10&tenantId=686ea1d3-bc2b-4c6f-a92c-d99c5c301635&threadId=19_meeting_ODE2MzMzZmItYWZjNC00N2E5LThjZjAtNGY3YTJkNDhlYTQw@thread.v2&messageId=0&language=en-US

________________________________________________________________

Preliminary agenda:

* TCP2 status
* User mode networking

If you have anything you want to discuss, please let me know.


Cheers,
Jukka

Hi Raveendra,

Yes it should be up to the driver to manage this. However, this is not
the case in many drivers (across all domain, not only DMA).

This is also one of the thing which is being solved through
https://github.com/zephyrproject-rtos/zephyr/issues/22941

The goal would be drivers maintainers should not have to think about
it. It would be handled transparently.

Tomasz