Date   
Zephyr 2.3.0-rc1 tagged

Carles Cufi
 

Hi all,

The first release candidate for Zephyr 2.3.0 has now been tagged (v2.3.0-rc1).

The merge window for features and enhancements is now closed for this release, and it will remain closed until 2.3.0 is released; the stabilization period is now open.
During said stabilization period only bug-fix, documentation, and stabilization-related patches may be merged to master.
Additional features or enhancements for the 2.3 release will require approval by the TSC.
As we need to reduce bug counts for the release, you are all encouraged to submit PRs that close existing bug reports, and to help reviewing such PRs submitted by other contributors or maintainers.
Testing Zephyr master branch during the stabilization period is also requested; please test the code base and file bug reports so they can be addressed before the release deadline.

The full release log can be found here:
https://github.com/zephyrproject-rtos/zephyr/releases/tag/v2.3.0-rc1

More details about Zephyr releases can found on the pages below:
https://docs.zephyrproject.org/latest/development_process/release_process.html
https://github.com/zephyrproject-rtos/zephyr/wiki/Program-Management

The final release is tentatively scheduled for May 29th.

Note 1: You are of course free to send Pull Requests for new features in order to gather feedback early or collaborate with others, but the release team would like to encourage everyone to focus on bugfixes and documentation improvements to the larges extent possible, so that we can release 2.3.0 on time and in the best shape possible.
Note 2: If you have a feature or enhancement you would like to submit to the TSC, please tag the Pull Request in question with the "TSC" label, make sure it is approved and passing CI, and attend the next TSC meeting.

A big Thank You to everyone that contributed to this release so far, be it with code, reviews, documentation or any other type of contribution.

Thanks,

Carles

How to compile riscv64 program with 0.10.3 sdk "riscv64-zephyr-elf-gcc" toolchain?

"曹子龙
 

I try to compile program with "zephyr-sdk-0.10.3/riscv64-zephyr-elf/bin/riscv64-zephyr-elf-gcc " to compile my program,

but it seems the result still be 32 bit program:
czl@czl-Vostro-3268:~/zephyr-sdk-0.10.3/riscv64-zephyr-elf/bin$ file a.out
a.out: ELF 32-bit LSB executable, UCB RISC-V, version 1 (SYSV), statically linked, with debug_info, not stripped

and i event try to compile with rv64 flag -march=rv64i
./riscv64-zephyr-elf-gcc -g main.c  -march=rv64i
cc1: error: ABI requires -march=rv32
 it seems still dont work 

at the beginning i guess it mybe use a ilp32 abi based on rv64 toolchan, so i try a program like that:
 20 unsigned long long foolbar2(unsigned long long a, unsigned long long b)
 21 {
 22         return a + b;
 23 }
whch unsigned long should be compile to "ld" and "sd" pare means ilp32 abi on RV64ISA ARCH.
but
  95 {          
  96    10194:       fe010113                addi    sp,sp,-32
  97    10198:       00812e23                sw      s0,28(sp)
  98    1019c:       02010413                addi    s0,sp,32
  99    101a0:       fea42423                sw      a0,-24(s0)
 100    101a4:       feb42623                sw      a1,-20(s0)
 101    101a8:       fec42023                sw      a2,-32(s0)
 102    101ac:       fed42223                sw      a3,-28(s0)
 103         return a + b;
 104    101b0:       fe842783                lw      a5,-24(s0)
 105    101b4:       fec42803                lw      a6,-20(s0)
 106    101b8:       fe042583                lw      a1,-32(s0)
 107    101bc:       fe442603                lw      a2,-28(s0)
 108    101c0:       00b786b3                add     a3,a5,a1

it purely total no!!!

so why? now that an rv32-zephyr-elf-gcc exist, if the iscv64-zephyr-elf-gcc  cat compile the 64 bit program, why it here ? 

曹子龙

珠海全志科技股份有限公司      BU1-PSW

地址:广东省珠海市高新区唐家湾镇科技2路9号

TEL:13824125580

Email:caozilong@...

网址: http://www.allwinnertech.com

 


API Change: video

Carles Cufi
 

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

Re: Dev-Review Meeting Agenda May 7

Bolivar, Marti
 

Sorry, found it in the notes!

- Simon

On Thu, 7 May 2020 at 08:49, Simon Glass <@sjg1> wrote:

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

Re: Dev-Review Meeting Agenda May 7

Simon Glass
 

Sorry, found it in the notes!

- Simon

On Thu, 7 May 2020 at 08:49, Simon Glass <@sjg1> wrote:

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

Upcoming Event: Zephyr Project: Dev Meeting - Thu, 05/07/2020 8:00am-9:00am, Please RSVP #cal-reminder

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

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

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