Date   

Re: Dev-Review Meeting Agenda May 7

Simon Glass
 

Hi Kumar,

Is there a link to the meeting somewhere please?

Regards,
Simon

On Thu, 7 May 2020 at 08:24, Kumar Gala <kumar.gala@...> wrote:

Here’s the agenda topics for this week:

* Review PR’s tagged with dev-review

* Any topics anyone else has.

- k


Dev-Review Meeting Agenda May 7

Kumar Gala
 

Here’s the agenda topics for this week:

* Review PR’s tagged with dev-review

* Any topics anyone else has.

- k


Re: Bridging #networking

Jukka Rissanen
 

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

On Thu, 2020-05-07 at 02:35 -0700, kenth.eriksson@... wrote:
Any plans to add Ethernet bridging support? I want to add VLAN sub-
interfaces into a bridge.


Bridging #networking

kenth.eriksson@...
 

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


[2.3 release] Feature merge window close (M2) tomorrow

Carles Cufi
 

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


Re: #networking #ppp #gsm_modem #mbedtls #ppp #gsm_modem #mbedtls #networking

Jukka Rissanen
 

Hi Bo,

some comments inline below:

On Wed, 2020-05-06 at 09:36 -0700, Bo.Kragelund@... 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


#networking #ppp #gsm_modem #mbedtls #ppp #gsm_modem #mbedtls #networking

Bo.Kragelund@...
 

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.
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.
But maybe there other CONFIG parameters I am not aware of, that need to be adjusted. Maybe some timeout?
The basic configuration was taken from the gsm_modem sample project 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.
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

0x14D

8

7

6

5

4

3

2

1

0

1

0

1

0

0

1

1

0

1

 

NET_CONTEXT_TYPE

NET_CONTEXT_FAMILY

NET_CONTEXT_READY

NET_CONTEXT_CONNECTED

NET_CONTEXT_IN_USE

 

0x148

1

0

1

0

0

1

0

0

0

 

NET_CONTEXT_TYPE

NET_CONTEXT_FAMILY

NET_CONTEXT_IDLE

NET_CONTEXT_UNCONNECTED

NET_CONTEXT_IN_USE

 





DMA: No cache mermory region

Raveendra Padasalagi <raveendra.padasalagi@...>
 

Hi Tomasz, all,

 

We have a DMA controller requiring 1MB of non-cache memory region for DMA descriptors.

I had a look into CONFIG_NOCACHE_MEMORY implementation.

 

./arch/common/nocache.ld

 

/* Non-cached region of RAM */

SECTION_DATA_PROLOGUE(_NOCACHE_SECTION_NAME,(NOLOAD),)

{

        MPU_ALIGN(_nocache_ram_size);

        _nocache_ram_start = .;

        *(.nocache)

        *(".nocache.*")

        MPU_ALIGN(_nocache_ram_size);

        _nocache_ram_end = .;

} GROUP_DATA_LINK_IN(RAMABLE_REGION, RAMABLE_REGION)

_nocache_ram_size = _nocache_ram_end - _nocache_ram_start;

 

Since RAMABLE_REGION is RAM which is TCM memory in our case and its very small in size and we can’t get 1MB.

 

We need a way to specify DDR memory region instead of RAMABLE_REGION.

How to achieve this generically ? any hints is appreciated.

 

Regards,

Raveendra


Re: DMA: driver API's thread safety

Raveendra Padasalagi <raveendra.padasalagi@...>
 

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

-----Original Message-----
From: Tomasz Bursztyka [mailto:tomasz.bursztyka@...]
Sent: Monday, May 4, 2020 11:30 AM
To: raveendra.padasalagi@...; devel@...
Subject: Re: [Zephyr-devel] DMA: driver API's thread safety

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

Hi,

Is dma_config(), dma_start() API’s are thread safe ?
Is it a dma controller driver responsibility to use locks to ensure
dma hardware channels are accessed safely across multiple threads ?


Regards,
Raveendra


Upcoming Event: Zephyr Project: APIs - Tue, 05/05/2020 9:00am-10:00am, Please RSVP #cal-reminder

devel@lists.zephyrproject.org Calendar <devel@...>
 

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


Re: API meeting: agenda

Carles Cufi
 

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

-----Original Message-----
From: devel@... <devel@...> On
Behalf Of Carles Cufi via lists.zephyrproject.org
Sent: 05 May 2020 16:08
To: users@...; devel@...
Subject: [Zephyr-devel] API meeting: agenda

Hi all,

*************************************************
We will be using Teams instead of Zoom:
https://teams.microsoft.com/l/meetup-
join/19%3ameeting_YzYzZTAzNGItOWFiMS00MDBkLTkyYmMtNzljZjkwNDVlMThm%40thr
ead.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



API meeting: agenda

Carles Cufi
 

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


Network forum agenda

Jukka Rissanen
 

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


Re: DMA: driver API's thread safety

Tomasz Bursztyka
 

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

Hi,

Is dma_config(), dma_start() API’s are thread safe ?
Is it a dma controller driver responsibility to use locks to ensure
dma hardware channels are accessed safely across multiple threads ?


Regards,
Raveendra


Re: I2c read/write command?

Simon Glass
 

Thanks, it seemed to work so I added another patch and send a pull request.

- Simon

On Thu, 30 Apr 2020 at 15:50, Nashif, Anas <anas.nashif@...> wrote:

Simon,

The i2c shell was introduced just recently and scan was the first command, I had a prototype for write_byte and read_byte back then but never got to complete it, see

 

https://github.com/nashif/zephyr/pull/new/i2c_shell_scan

 

You are welcome to take a crack at it 😉

 

Anas

 

 

From: <devel@...> on behalf of Simon Glass <sjg@...>
Date: Thursday, 30 April 2020 at 17:09
To: "devel@..." <devel@...>
Subject: [Zephyr-devel] I2c read/write command?

 

Hi,

 

I don't see a command to read/write from an i2c device, just 'i2c scan'. Am I missing something? If not, I could take a crack at it.

 

Regards,

Simon

 


DMA: driver API's thread safety

Raveendra Padasalagi <raveendra.padasalagi@...>
 

Hi,

 

Is dma_config(), dma_start() API’s are thread safe ?

Is it a dma controller driver responsibility to use locks to ensure dma hardware channels are accessed safely across multiple threads ?

 

 

Regards,

Raveendra


Re: I2c read/write command?

Nashif, Anas
 

Simon,

The i2c shell was introduced just recently and scan was the first command, I had a prototype for write_byte and read_byte back then but never got to complete it, see

 

https://github.com/nashif/zephyr/pull/new/i2c_shell_scan

 

You are welcome to take a crack at it 😉

 

Anas

 

 

From: <devel@...> on behalf of Simon Glass <sjg@...>
Date: Thursday, 30 April 2020 at 17:09
To: "devel@..." <devel@...>
Subject: [Zephyr-devel] I2c read/write command?

 

Hi,

 

I don't see a command to read/write from an i2c device, just 'i2c scan'. Am I missing something? If not, I could take a crack at it.

 

Regards,

Simon

 


I2c read/write command?

Simon Glass
 

Hi,

I don't see a command to read/write from an i2c device, just 'i2c scan'. Am I missing something? If not, I could take a crack at it.

Regards,
Simon


Test-related labels on GitHub

Carles Cufi
 

Hi all,

I have tried to clean up the test-related labels on GitHub, performing the following changes:

- "Testing" has been removed
- "Testing Suite" has been renamed to "Test Framework" and should be used for issues that are related to either the framework or missing platforms (eg. a new target on QEMU, an issue that affects multiple individual tests)
- "Tests" should be used for issues related to specific tests
- "Sanitycheck" should be used for issues related to the sanitycheck Python script

Additional labels, such as "Bug" or the relevant architecture(s) should be used to complement the information provided by the Test-related ones.

I have tried to go through all test-related issues and re-label them as appropriate.
Please use the new labels as described.

Thanks,

Carles


Re: Zephyr Toolchain Working Group Meeting – 30 April 2020

Rasmussen, Torsten
 

Today’s meeting minutes:

https://docs.google.com/document/d/1IQKBK-GcJNZG0O9QArqYfvb6Huk5xHscN-XIGEZr-z8/

Notes/Minutes

Status updates

 

Best regards

 

Torsten T. Rasmussen

 

 

From: devel@... <devel@...> On Behalf Of Rasmussen, Torsten via lists.zephyrproject.org
Sent: 30 April, 2020 14:37
To: devel@...
Subject: [Zephyr-devel] Zephyr Toolchain Working Group Meeting – 30 April 2020

 

*******************************

 

NOTE: We will be using Microsoft Teams for this meeting instead of zoom.  The link is found below.

 

*******************************

 

Hi,

 

For today’s meeting let’s follow up on last meeting action items and get a status update.

Also I would like to give a brief introduction to:

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

Agenda

  • Updates:
  • Short term goals, way forward
    • Dedicated toolchain test cases.
    • Label PR for automatic execution of CI Toolchain test cases

 

 

Feel free to send a mail, if you would like additional topics to be discussed.

 

Best regards

 

Torsten T. Rasmussen           

 

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

________________________________________________________________________________

 

Join Microsoft Teams Meeting

+1 213-437-3346   United States, Los Angeles (Toll)

Conference ID: 570 955 823#

Local numbers | Reset PIN | Learn more about Teams | Meeting options

________________________________________________________________________________