Date   

Zephyr 2.2.0-rc3 tagged

Johan Hedberg
 

Hi Zephyr developers,

We have now tagged Zephyr 2.2.0-rc3, i.e. we’re getting close to the final release. We’re currently at 15 medium priority bugs and no high priority bugs, so the release criteria are met (at least for now).

From now on I’ll handle all merges until the release. The focus should now be on testing, documentation updates and release notes. If all goes well the final release will be done later in the coming week.

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

More details about Zephyr releases is found here: https://github.com/zephyrproject-rtos/zephyr/wiki/Program-Management

Thanks to everybody who has contributed to this release!

Johan


Re: ARMv7 Cortex-A port for Xilinx Zynq7000

Jukka Rissanen
 

Hi Immo,

the networking unit tests under tests/net directory should be self
contained i.e., they should not need SLIP to be able to run. The
sanitychecker also compiles samples/net/ programs and those indeed need
SLIP or other network connectivity, but these are not run by
sanitychecker (unless you flash them to the actual device).


Cheers,
Jukka

On Fri, 2020-02-28 at 02:53 -0800, Immo Birnbaum wrote:
Hi Jukka,

thanks for the info, I looked at the YAML files of other platforms
and eventually came across the "-netif:eth" switch. Once I had that
integrated, I had a bit of a fight against the QEMU system
configuration in conjunction with the UART pipe and SLIP drivers used
by the networking tests, I eventually came up with a configuration in
which both the UART console and the UART pipe driver work after
fixing a minor bug in one of the instantiation macros of the Xilinx
UART driver. Also, having the Ethernet controller driver perform
polling reads/writes to a PHY that is non-existent in QEMU doesn't
help the system booting. Fortunately, I had the PHY initialization as
an optional switch in the driver's Kconfig file right from the
start.

I don't have the exact number of tests performed available right now,
but after all those changes, running sanitycheck for the tests/net
branch resulted in a significant number of test cases being executed,
of which only 2 or 3 failed - the actual tests all passed, but the
test cases failed due to assertions. Obviously, more interfaces than
expected are being created, in particular for test cases involving
VLANs. I'll leave that branch as it is for now, as I'm currently
doing my research regarding the two test cases in tests/kernel that
currently fail.

Best regards,
Immo


Re: ARMv7 Cortex-A port for Xilinx Zynq7000

Immo Birnbaum
 

Hi Jukka,

thanks for the info, I looked at the YAML files of other platforms and eventually came across the "-netif:eth" switch. Once I had that integrated, I had a bit of a fight against the QEMU system configuration in conjunction with the UART pipe and SLIP drivers used by the networking tests, I eventually came up with a configuration in which both the UART console and the UART pipe driver work after fixing a minor bug in one of the instantiation macros of the Xilinx UART driver. Also, having the Ethernet controller driver perform polling reads/writes to a PHY that is non-existent in QEMU doesn't help the system booting. Fortunately, I had the PHY initialization as an optional switch in the driver's Kconfig file right from the start.

I don't have the exact number of tests performed available right now, but after all those changes, running sanitycheck for the tests/net branch resulted in a significant number of test cases being executed, of which only 2 or 3 failed - the actual tests all passed, but the test cases failed due to assertions. Obviously, more interfaces than expected are being created, in particular for test cases involving VLANs. I'll leave that branch as it is for now, as I'm currently doing my research regarding the two test cases in tests/kernel that currently fail.

Best regards,
Immo


Re: ARMv7 Cortex-A port for Xilinx Zynq7000

Jukka Rissanen
 

Hi Immo,

for networking tests to run, I think you need to say

- netif:eth

in board yaml file (instead of just "- net")


Cheers,
Jukka

On Wed, 2020-02-26 at 04:54 -0800, Immo Birnbaum wrote:
Hi all,

here's my first update on the topic of the Zynq-7000 port, this is
the progress so far:

- Set up a fresh development VM which now uses the Zephyr SDK, which
works fine for the Cortex-A9.
- Forked the Zephyr repository and set up a feature branch, which can
be found here:
https://github.com/ibirnbaum/zephyr/tree/armv7_cortex_a
- Merged all of the changes/additions described above into the
current code base.
- Updated the AXI GPIO driver to match the GPIO driver API which was
heavily modified in the meantime.
- Kicked out my own GIC PL-390 interrupt controller driver and
switched over to Stephanos Ionannidis' GICv1 implementation,
including updated IRQ descriptors in the device tree files.
- I looked into the testsuite and ran tests on the QEMU Cortex-A9
target, plus a hand full of test cases on the actual hardware (as
downloading the binary to the board is still a manual process using
the Lauterbach TRACE software). The results don't look too bad, for
example, these are the results of the 'kernel' test suite:
* 86 test configurations selected, 8 configurations discarded due to
filters
* 24 tests skipped (e.g. SMP/ARMv8/userspace related test cases)
* Out of the 62 remaining test cases, 60 pass. One
(kernel.timer.tickless) fails to build due to an unresolved symbol
(z_clock_uptime). This is odd for two reasons: one, all other
'tickless'-related tests are skipped and two, the Local APIC timer
driver seems to be the only timer driver implementing this function.
To me, this looks more like a testsuite configuration issue? The
other failure is the arch.interrupt test case, which actually runs
but fails due to an assertion regarding the expected state of an IRQ
to be tested. This is due to the target IRQ selection logic only
being implemented for Cortex-M when it comes to the ARM architecture.
The following testsuites pass all test cases on the QEMU target which
aren't filtered out for whatever reason (I didn't blacklist anything
myself):
- lib
- misc
- portability
- posix
- shell
- subsys
- ztest
I'll have to look into the details as to why in some cases, more test
cases are filtered out than executed. In some cases, e.g. ARMv8-
specific stuff, it's pretty obvious, but in others I'm suspecting
that I ought to whitelist testcases or subsystems for testing, likely
in the target's YAML files? For example, despite having full Ethernet
support, the 'net' testsuite in its current state does pretty much
nothing.

I'll keep you updated and I'll look into the ongoing discussions and
the mechanics of pull requests, I could start simple, as for example,
the Xilinx TTC timer driver had a faulty prescaler calculation
routine. As this source file is already in the main repository, this
might be a good exercise for a pull request. Until then, I'd
appreciate any feedback if anyone feels like experimenting with my
fork of the repository.

Best regards,
Immo


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

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

Reminder: Zephyr Project: Dev Meeting

When: Thursday, 27 February 2020, 8:00am to 9:00am, (GMT-08:00) America/Los Angeles

Where:https://zoom.us/j/993312203

An RSVP is requested. Click here to RSVP

Organizer: devel@...

Description: Join Zoom Meeting
https://zoom.us/j/993312203

One tap mobile
+16699006833,,993312203# US (San Jose)
+16465588656,,993312203# US (New York)

Dial by your location
        +1 669 900 6833 US (San Jose)
        +1 646 558 8656 US (New York)
        +1 877 369 0926 US Toll-free
        +1 855 880 1246 US Toll-free
Meeting ID: 993 312 203
Find your local number: https://zoom.us/u/ankEMRagf


Re: ARMv7 Cortex-A port for Xilinx Zynq7000

Stephanos Ioannidis
 

Hi Immo,

 

Thanks for looking into this.

 

For the time being, I believe focusing on the following issues would help in getting these changes upstream-ed:

 

  1. Getting all applicable tests to pass
    1. At least, all applicable `kernel` tests must pass.
    2. Some tests (e.g. `benchmark` and `interrupt`) may require additional work to pass (see #22669 and #22670).
  2. Cleaning up commits (all the usual stuff)
    1. Breaking changes into more manageable chunks/commits
    2. Squashing commits that should really be one commit

 

The following are some ongoing issues that could be noteworthy:

 

  • Refactor ARM interrupt system (Cortex-A & Cortex-R) (#22718)
  • Implement benchmark tests for Cortex-R and Cortex-A (#22669)
  • Implement GIC-based ARM interrupt tests (#22670)
  • arch: arm: aarch32: Allow selecting compiler instruction set (#22741)
  • AArch64 / Cortex-A port improvements / TODO (#22411)
  • soc: arm64: Add support for Xilinx ZynqMP APU (#22418)

 

There is also the #arch-arm channel on the Slack where we discuss ARM arch development topics.

 

Regards,

 

Stephanos

 

From: devel@... <devel@...> On Behalf Of Immo Birnbaum via Lists.Zephyrproject.Org
Sent: Wednesday, February 26, 2020 9:55 PM
To: devel@...
Cc: devel@...
Subject: Re: [Zephyr-devel] ARMv7 Cortex-A port for Xilinx Zynq7000

 

Hi all,

here's my first update on the topic of the Zynq-7000 port, this is the progress so far:

- Set up a fresh development VM which now uses the Zephyr SDK, which works fine for the Cortex-A9.
- Forked the Zephyr repository and set up a feature branch, which can be found here: https://github.com/ibirnbaum/zephyr/tree/armv7_cortex_a
- Merged all of the changes/additions described above into the current code base.
- Updated the AXI GPIO driver to match the GPIO driver API which was heavily modified in the meantime.
- Kicked out my own GIC PL-390 interrupt controller driver and switched over to Stephanos Ionannidis' GICv1 implementation, including updated IRQ descriptors in the device tree files.
- I looked into the testsuite and ran tests on the QEMU Cortex-A9 target, plus a hand full of test cases on the actual hardware (as downloading the binary to the board is still a manual process using the Lauterbach TRACE software). The results don't look too bad, for example, these are the results of the 'kernel' test suite:
* 86 test configurations selected, 8 configurations discarded due to filters
* 24 tests skipped (e.g. SMP/ARMv8/userspace related test cases)
* Out of the 62 remaining test cases, 60 pass. One (kernel.timer.tickless) fails to build due to an unresolved symbol (z_clock_uptime). This is odd for two reasons: one, all other 'tickless'-related tests are skipped and two, the Local APIC timer driver seems to be the only timer driver implementing this function. To me, this looks more like a testsuite configuration issue? The other failure is the arch.interrupt test case, which actually runs but fails due to an assertion regarding the expected state of an IRQ to be tested. This is due to the target IRQ selection logic only being implemented for Cortex-M when it comes to the ARM architecture.
The following testsuites pass all test cases on the QEMU target which aren't filtered out for whatever reason (I didn't blacklist anything myself):
- lib
- misc
- portability
- posix
- shell
- subsys
- ztest
I'll have to look into the details as to why in some cases, more test cases are filtered out than executed. In some cases, e.g. ARMv8-specific stuff, it's pretty obvious, but in others I'm suspecting that I ought to whitelist testcases or subsystems for testing, likely in the target's YAML files? For example, despite having full Ethernet support, the 'net' testsuite in its current state does pretty much nothing.

I'll keep you updated and I'll look into the ongoing discussions and the mechanics of pull requests, I could start simple, as for example, the Xilinx TTC timer driver had a faulty prescaler calculation routine. As this source file is already in the main repository, this might be a good exercise for a pull request. Until then, I'd appreciate any feedback if anyone feels like experimenting with my fork of the repository.

Best regards,
Immo


Re: ARMv7 Cortex-A port for Xilinx Zynq7000

Immo Birnbaum
 

Hi all,

here's my first update on the topic of the Zynq-7000 port, this is the progress so far:

- Set up a fresh development VM which now uses the Zephyr SDK, which works fine for the Cortex-A9.
- Forked the Zephyr repository and set up a feature branch, which can be found here: https://github.com/ibirnbaum/zephyr/tree/armv7_cortex_a
- Merged all of the changes/additions described above into the current code base.
- Updated the AXI GPIO driver to match the GPIO driver API which was heavily modified in the meantime.
- Kicked out my own GIC PL-390 interrupt controller driver and switched over to Stephanos Ionannidis' GICv1 implementation, including updated IRQ descriptors in the device tree files.
- I looked into the testsuite and ran tests on the QEMU Cortex-A9 target, plus a hand full of test cases on the actual hardware (as downloading the binary to the board is still a manual process using the Lauterbach TRACE software). The results don't look too bad, for example, these are the results of the 'kernel' test suite:
* 86 test configurations selected, 8 configurations discarded due to filters
* 24 tests skipped (e.g. SMP/ARMv8/userspace related test cases)
* Out of the 62 remaining test cases, 60 pass. One (kernel.timer.tickless) fails to build due to an unresolved symbol (z_clock_uptime). This is odd for two reasons: one, all other 'tickless'-related tests are skipped and two, the Local APIC timer driver seems to be the only timer driver implementing this function. To me, this looks more like a testsuite configuration issue? The other failure is the arch.interrupt test case, which actually runs but fails due to an assertion regarding the expected state of an IRQ to be tested. This is due to the target IRQ selection logic only being implemented for Cortex-M when it comes to the ARM architecture.
The following testsuites pass all test cases on the QEMU target which aren't filtered out for whatever reason (I didn't blacklist anything myself):
- lib
- misc
- portability
- posix
- shell
- subsys
- ztest
I'll have to look into the details as to why in some cases, more test cases are filtered out than executed. In some cases, e.g. ARMv8-specific stuff, it's pretty obvious, but in others I'm suspecting that I ought to whitelist testcases or subsystems for testing, likely in the target's YAML files? For example, despite having full Ethernet support, the 'net' testsuite in its current state does pretty much nothing.

I'll keep you updated and I'll look into the ongoing discussions and the mechanics of pull requests, I could start simple, as for example, the Xilinx TTC timer driver had a faulty prescaler calculation routine. As this source file is already in the main repository, this might be a good exercise for a pull request. Until then, I'd appreciate any feedback if anyone feels like experimenting with my fork of the repository.

Best regards,
Immo


Re: How to use DTLS with offloaded socket if the underlying modem does not support DTLS

Jukka Rissanen
 

Hi Holger,

one option is use the generic GSM modem, which uses PPP to connect to
modem, instead of offloading the IP stack to the modem. In that case
one can send DTLS data via the modem. Unfortunately the modem you
mentioned (Quectel BC68) does not seem to support PPP mode.

Cheers,
Jukka

On Wed, 2020-02-26 at 02:04 -0800, Holger Gräf wrote:
Hi Billy,

thanks for the reply. I still have to clean up the driver a bit, then
I will create the PR.

With regard to the second message, thanks for the hint. I have
already stumbled upon these commands, but according to the manual
they are specific to Huawei's IoT platform, which I don't use. I have
the impression that it's based on LwM2M, but I would like to be able
to use DTLS encryption regardless of the protocol I use (UDP, TCP or
the higher level COAPS or LwM2M).

That's why I'm looking for a way to use Zephyr's mbedtls with my
offloaded sockets. Any help would be very much appreciated :-)

All the best,

Holger


Re: How to use DTLS with offloaded socket if the underlying modem does not support DTLS

Holger Gräf
 

Hi Billy,

thanks for the reply. I still have to clean up the driver a bit, then I will create the PR.

With regard to the second message, thanks for the hint. I have already stumbled upon these commands, but according to the manual they are specific to Huawei's IoT platform, which I don't use. I have the impression that it's based on LwM2M, but I would like to be able to use DTLS encryption regardless of the protocol I use (UDP, TCP or the higher level COAPS or LwM2M).

That's why I'm looking for a way to use Zephyr's mbedtls with my offloaded sockets. Any help would be very much appreciated :-)

All the best,

Holger


Zephyr 2.2.0-rc2 tagged

Johan Hedberg
 

Hi Zephyr developers,

We have now tagged the second release candidate for Zephyr 2.2: 2.2.0-rc2.

We’re currently at 0 high priority bugs and 21 medium priority bugs. This is already close to the requirements for rc3 and the final release, which are 0 and 20 respectively.

Developers are requested to continue testing the release, filing bugs, and addressing any remaining bugs that are assigned to you. I would also encourage subsystem owners to take a look at their respective sections in doc/releases/release-notes-2.2.rst and submit updates in case your subsystem is still missing a change summary since the last release.

Looking at the original release schedule, it seems likely that we’ll need to push the final release from the end of this week to some time next week - we will discuss this in this week’s TSC call.

The full release log for 2.2.0-rc2 can be found here:
https://github.com/zephyrproject-rtos/zephyr/releases/tag/v2.2.0-rc2

More details about Zephyr releases is found here:
https://github.com/zephyrproject-rtos/zephyr/wiki/Program-Management

Thanks to everybody who has contributed to this release!

Johan


Re: How do I get to know about plans on on-going or future features?

Carles Cufi
 

Hi Alex,

 

Thanks for your interest in Zephyr.

I think you should begin by defining an area you want to contribute in: kernel, filesystems, drivers, protocol stacks, etc.

In order to find out which features are missing I think one good way is to look through the “Enhancements” and “Feature Requests” GitHub issues:

 

Enhancements:

https://github.com/zephyrproject-rtos/zephyr/issues?q=is%3Aissue+is%3Aopen+label%3Aenhancement

 

Feature Requests:

https://github.com/zephyrproject-rtos/zephyr/issues?q=is%3Aissue+is%3Aopen+label%3A%22feature+request%22

 

Once you define the area you want to contribute in, you can combine the above labels with an area label and browse through the issues.

As soon as you find an issue you would like to work on, you can then write on the mailing list asking if there is someone else planning to work or working already on it.

 

Another category that might be of interest to you is the “Good first issue”, which we have tried to use for issues that are not overly complicated and that can serve as a starting point to someone like you looking to become a contributor:

https://github.com/zephyrproject-rtos/zephyr/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen++label%3A%22Good+first+issue%22+

 

Thanks,

 

Carles

 

From: devel@... <devel@...> On Behalf Of Alexander Syvak via Lists.Zephyrproject.Org
Sent: 24 February 2020 14:11
To: devel@...
Cc: devel@...
Subject: [Zephyr-devel] How do I get to know about plans on on-going or future features?

 

Hi!

 

I am new to Zephyr projet, and I'd like to contribute.

 

There are many features had been implemented by the moment.

There are features are being implemented at the moment.

Finally, there are features to be implemented.

 

How do I know about the last two groups of features? About plans on them?

 

Where do I start?

 

Regards,

Alex.


Re: How can west commands be executed when doing ‘west update’?

Bolivar, Marti
 

Hello,

I believe the west issue covering this feature request is:
https://github.com/zephyrproject-rtos/west/issues/320

Please take a look and feel free to comment!

Thanks,
Marti

"Li, Jun R via Lists.Zephyrproject.Org"
<jun.r.li=intel.com@...> writes:

Hey,

I would like to copy some environment setting scripts to the top directory of my project by using west commands when the command “west update” runs. So far, I can run “west <my_cmd>“ to do that but I hope to let it run automatically while west updating repos.


Thank you!

Jun



How can west commands be executed when doing ‘west update’?

Li, Jun R
 

Hey,

I would like to copy some environment setting scripts to the top directory of my project by using west commands when the command “west update” runs. So far, I can run “west <my_cmd>“ to do that but I hope to let it run automatically while west updating repos.


Thank you!

Jun


Does Nordic’s SPI driver support easyDMA?

Li, Jun R
 

Hey,

Anyone has experience on enabling easyDMA for nRF52’s SPI master?

Thank you!

Jun


API meeting: cancelled today

Carles Cufi
 

Hi all,

Due to several contributors being unavailable today and myself having an additional commitment I have decided to cancel this week's API meeting.
Next week the meeting will take place as usual.

Thanks,

Carles


Cancelled Event: Zephyr Project: APIs - Tuesday, 25 February 2020 #cal-cancelled

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

Cancelled: Zephyr Project: APIs

This event has been cancelled.

When:
Tuesday, 25 February 2020
9:00am to 10:00am
(UTC-08:00) America/Los Angeles

Where:
https://zoom.us/j/177647878

Organizer: devel@...

Description:
Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/177647878

Or iPhone one-tap :
    US: +16465588656,,177647878# or +16699006833,,177647878# 
Or Telephone:
    Dial(for higher quality, dial a number based on your current location): 
        US: +1 646 558 8656 or +1 669 900 6833 or +1 855 880 1246 (Toll Free) or +1 877 369 0926 (Toll Free)
    Meeting ID: 177 647 878
    International numbers available: https://zoom.us/zoomconference?m=ioAR9GK1OE5LkN1ojt-heTCl7yPcJrhY


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


How do I get to know about plans on on-going or future features?

Alexander Syvak
 

Hi!

I am new to Zephyr projet, and I'd like to contribute.

There are many features had been implemented by the moment.
There are features are being implemented at the moment.
Finally, there are features to be implemented.

How do I know about the last two groups of features? About plans on them?

Where do I start?

Regards,
Alex.


Re: How to use DTLS with offloaded socket if the underlying modem does not support DTLS

William Fish
 

A quick internet search brought up a manual which gave a basic DLTS example:
https://www.quectel.com/UploadImage/Downlad/Quectel_BC95-G&BC68_AT_Commands_Manual_V1.1.pdf

BC95-G&BC68_AT_Commands_Manual -- Pg 122 
 
Register to Huawei’s IoT Platform with DTLS
 
AT+CGATT? //Query the PS service attach status.
+CGATT:1 //Attached to the PS service.
OK
 
AT+NCDP= 180.101.147.115,5684 //Set IoT platform IP address and port. The port is 5684.
OK
 
AT+QSECSWT=1 //Encryption using standard DTLS.
OK
 
AT+QSETPSK=201703230000024,0123456789ABCDEF0123456789ABCDEF
OK //Set PSK ID and PSK.
 
AT+QREGSWT? //Query the registration mode.
+QREGSWT:0 //Manual registration mode.
OK
 
AT+QLWSREGIND=0 //Start to register to the IoT platform.
OK
 
+QLWEVTIND:0 //Successful registration indication.


Re: How to use DTLS with offloaded socket if the underlying modem does not support DTLS

William Fish
 

Holger,
Great if you have created a driver...you may want to create a PR so that it gets reviewed by the Dev community The man that should be able to help is Mike Scott.

Billy..


How to use DTLS with offloaded socket if the underlying modem does not support DTLS

Holger Gräf
 

Dear all,

I have adapted the Sara R4 modem driver (zephyr/drivers/modem/ublox-sara-r4.c) in Zephyr in order to control a Quectel BC68 NB-IoT modem. The aim is to use this with Zephyr's LwM2M engine. Without DTLS everything works fine.

Now I want to add DTLS encryption to my setup, but I have not managed to figure out how to implement this with the socket offload API used by the modem driver (note that the Quectel modem I use does not itself support DTLS sockets).

Is there any easy way to implement this?

Thanks and all the best,

Holger