Date   

[RFC] SMP support for RISC-V privilege architecture

Katsuhiro Suzuki
 

Hello All,

I'm working on SMP support for RISC-V privilege architecture.
https://github.com/katsuster/zephyr/tree/riscv_virt_pc_smp

It seems worked well on QEMU RV32 virt pc (*) porting.
(RV64 not tested yet)

But I don't understand Zephyr's SMP mechanism perfectly and
don't know required conditions (Ex. regression tests) if I
want to change these area.

I'm welcome comments or review of my patch.

(*)QEMU RV32 virt pc:
https://github.com/zephyrproject-rtos/zephyr/pull/28749

Diffs of config from default:
CONFIG_RISCV_USE_SWITCH=y (added by me)
CONFIG_SMP=y
CONFIG_MP_NUM_CPUS=4

Command line:
qemu-system-riscv32 -nographic -machine virt -net none \
-chardev stdio,id=con,mux=on -serial chardev:con \
-mon chardev=con,mode=readline -kernel zephyr/zephyr.elf \
-cpu rv32 -smp cpus=4 -bios none

Best Regards,
Katsuhiro Suzuki


[RFC] SMP support for RISC-V privilege architecture

Katsuhiro Suzuki
 

Hello All,

I'm working on SMP support for RISC-V privilege architecture.
https://github.com/katsuster/zephyr/tree/riscv_virt_pc_smp

It seems worked well on QEMU RV32 virt pc (*) porting.
(RV64 not tested yet)

But I don't understand Zephyr's SMP mechanism perfectly and
don't know required conditions (Ex. regression tests) if I
want to change these area.

I'm welcome comments or review of my patch.

(*)QEMU RV32 virt pc:
https://github.com/zephyrproject-rtos/zephyr/pull/28749

Diffs of config from default:
CONFIG_RISCV_USE_SWITCH=y (added by me)
CONFIG_SMP=y
CONFIG_MP_NUM_CPUS=4

Command line:
qemu-system-riscv32 -nographic -machine virt -net none \
-chardev stdio,id=con,mux=on -serial chardev:con \
-mon chardev=con,mode=readline -kernel zephyr/zephyr.elf \
-cpu rv32 -smp cpus=4 -bios none

Best Regards,
Katsuhiro Suzuki


Zephyr SDK 0.12.0-alpha-1 available for testing

Kumar Gala
 

Hi,

Latest version of the SDK can be found here:

https://github.com/zephyrproject-rtos/sdk-ng/releases/tag/v0.12.0-alpha-1

Please download and try things out and report any issues. Please report issues here:

https://github.com/zephyrproject-rtos/sdk-ng/issues

Known issues:

* some xtensa platforms may need updating w/regards to Zephyr & Xtensa HAL
[ https://github.com/zephyrproject-rtos/zephyr/pull/23142 ]

* known issue with arm64 and linking C++ & newlib:
[ https://github.com/zephyrproject-rtos/zephyr/issues/28650 ]

Changes since the last release:

• General:

• Updated to using buildkite for CI
• Updated yocto 3.1.1
• Build aarch64 (arm64) linux host toolchains.
• Moved to using a zephyr fork of crosstool-ng
• Update bossa to 1.9.1+
• cmake: Set HOST_TOOLS_HOME based on OS_PLATFORM
• QEMU:

• Updated to QEMU 5.1.0
• Added icount support for ARC
• OpenOCD:

• Updated to 20200928 snapshot
• newlib:

• Updated to version 3.3
• Updated xtensa to version 3.3 (in sync with all arch's)
• binutils:

• updated to version 2.35.1
• gcc:

• Updated to version 10.2.0
• gdb:

• Updated to version 9.2
• xtensa:

• remove HAL from SDK build


- k


Network forum agenda

Jukka Rissanen
 

Hi all,

There is a network forum meeting tomorrow Tuesday 6 Oct at 8AM PDT /
17.00 CET.

Agenda:

- TCP2 is now the default TCP implementation, legacy TCP implementation
is not yet removed. We can discuss possible issues and how to proceed.

https://github.com/zephyrproject-rtos/zephyr/issues/28587
https://github.com/zephyrproject-rtos/zephyr/pull/28832


- Modem power management support. Two alternative implementations
proposed for generic GSM modem, and one for offloaded modem.

https://github.com/zephyrproject-rtos/zephyr/pull/28475
https://github.com/zephyrproject-rtos/zephyr/pull/27731
https://github.com/zephyrproject-rtos/zephyr/pull/27927


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

Link to the Teams meeting:

https://teams.microsoft.com/l/meetup-join/19%3ameeting_NDU5ODRkNzktZDBmNC00MDg5LWI2OWEtNzM0MGZjMDU0Yjgw%40thread.v2/0?context=%7b%22Tid%22%3a%22af0096d9-700c-411a-b795-b3dd7122bad2%22%2c%22Oid%22%3a%22841a7c92-7816-4faf-9887-5e334e88f6d8%22%7d


Cheers,
Jukka


Re: SMP support for ARM architecture

Boie, Andrew P
 

Hi Krzysztof,

 

I'm assuming that you're referring to ARM Cortex-A? A patch recently landed to implement switch instead of swap: https://github.com/zephyrproject-rtos/zephyr/pull/27766. There is a GitHub enhancement for ARM64 SMP support https://github.com/zephyrproject-rtos/zephyr/issues/26952 but nobody is working on it AFAIK.

 

CPU affinity is currently implemented via the k_thread_cpu_mask_* APIs in include/kernel.h. So if you get SMP working on your arch the scheduling infrastructure is there.

 

This is just the first step, to fully implement SMP you'll need per-cpu variables, IPIs, some extra arch_* APIs implemented, etc. We don't have a porting guide for SMP yet, and having not done this myself I'm not quite an expert in this area but I would reach out to Andy Ross for general SMP enabling questions, and for ARM64 stuff I would coordinate with  Carlo Caione who has done much of the work so far.

 

We have SMP working on x86_64, ARC, and Xtensa so reviewing that may also be helpful.

 

HTH

Andrew

 

From: devel@... <devel@...> On Behalf Of Krzysztof Walczak via lists.zephyrproject.org
Sent: Friday, October 2, 2020 5:09 AM
To: devel@...
Subject: [Zephyr-devel] SMP support for ARM architecture

 

Hi,

 

For our multicore ARM based project we would like to use SMP and affinity mechanism in Zephyr. When digging into the code I found that it is not implemented.

Mainly, there is an implementation of arch_switch() missing needed by SMP. Can someone give me any guideline as to what would be required for implementation to have an SMP/afinity mechanism operational in Zephyr on ARM platform.

 

rgds

Krzysztof


Re: RFC: API Change: k_work

Peter A. Bigot
 

This RFC has been withdrawn.  Instead the documentation of the existing API will be updated to describe its behavior more precisely, and ultimately deprecated in favor of a new API and recommended usage that eliminates the problems.  See this and subsequent comments.


SMP support for ARM architecture

Krzysztof Walczak
 

Hi,

For our multicore ARM based project we would like to use SMP and affinity mechanism in Zephyr. When digging into the code I found that it is not implemented.
Mainly, there is an implementation of arch_switch() missing needed by SMP. Can someone give me any guideline as to what would be required for implementation to have an SMP/afinity mechanism operational in Zephyr on ARM platform.

rgds
Krzysztof


Zephyr Project: Dev Meeting - Thu, 10/01/2020 3:00pm-4:00pm, Please RSVP #cal-reminder

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

Reminder: Zephyr Project: Dev Meeting

When: Thursday, 1 October 2020, 3:00pm to 4:00pm, (GMT+00:00) UTC

Where:Microsoft Teams Meeting

An RSVP is requested. Click here to RSVP

Organizer: devel@...

Description:

________________________________________________________________________________
+1 321-558-6518 United States, Orlando (Toll)
Conference ID: 483 314 739#
Local numbers | Reset PIN | Learn more about Teams | Meeting options
 
 
________________________________________________________________________________


Re: Dev-Review Meeting Agenda Oct 1

Kumar Gala
 

On Oct 1, 2020, at 7:49 AM, Kumar Gala via lists.zephyrproject.org <kumar.gala=linaro.org@...> wrote:

Here’s the agenda topics for this week:

* List property label for all active ADCs regardless of the board used:
- https://github.com/zephyrproject-rtos/zephyr/issues/28566

* DTS default usage guidelines
- https://github.com/zephyrproject-rtos/zephyr/issues/25164
- https://github.com/zephyrproject-rtos/zephyr/pull/28817

* Any PR/issues w/dev-review tag

https://github.com/zephyrproject-rtos/zephyr/labels/dev-review

* Any topics anyone else has.
Added to agenda:

drivers: flash: nrf_qspi_nor: remove multithreading dependency
- https://github.com/zephyrproject-rtos/zephyr/pull/28740

For discussion on our policy w/regards to updates & fixes for deprecated features in general.


Dev-Review Meeting Agenda Oct 1

Kumar Gala
 

Here’s the agenda topics for this week:

* List property label for all active ADCs regardless of the board used:
- https://github.com/zephyrproject-rtos/zephyr/issues/28566

* DTS default usage guidelines
- https://github.com/zephyrproject-rtos/zephyr/issues/25164
- https://github.com/zephyrproject-rtos/zephyr/pull/28817

* Any PR/issues w/dev-review tag

https://github.com/zephyrproject-rtos/zephyr/labels/dev-review

* Any topics anyone else has.


Review of LoRaWAN PR

Mani Sadhasivam <manivannanece23@...>
 

Hi Folks,

There is a LoRaWAN PR posted a while ago [1] and it has undergone
reviews from several developers. But it still got stuck and I'd appreciate
any help to move this forward. This will be a great addition to the Zephyr
ecosystem once merged.

[1] https://github.com/zephyrproject-rtos/zephyr/pull/23664

Thanks,
Mani

--
மணிவண்ணன் சதாசிவம்


STM32: Moving devices pin configuration to device tree

Erwan Gouriou
 

TL;DR:
- Upcoming device tree based pin configuration for STM32 based boards
- Script generated, SoC package specific *-pinctrl.dtsi files are available in hal_stm32 modules
- Each *.pcintrl.dtsi file provides a complete set of valid pin configurations for targeted STM32
package
- Generation script is provided and can be used to generate new pin configuration variants (low
power, ...)
- One driver (STM32 serial) and two boards converted today as proof of concept
- Contributions are welcome to achieve deprecation of existing pinmux.c files within V2.5.0 
merge window


To all STM32 users and developers,

We're in the final step of reviewing PR #25996 "stm32: devices signals configuration from dt
This PR introduces the required material to enable device pin configuration using device tree.

With this method, device pin configuration should no longer be done in pinmux.c board file, but
in .dts file. For instance, to enable PB6 as TX and PB7 as RX on USART1, the following lines
should be added in .dts board file, in usart1 node:

 &usart1 {
        current-speed = <115200>;
+      pinctrl-0 = <&usart1_tx_pb6 &usart1_rx_pb7>;
+      pinctrl-names = "default";
        status = "okay";
 };

As a consequence, pin configuration can now be done at device driver level, opening the way
to dynamic pin configuration, which could be useful in various fields such as low power
management. Also, it provides flexibility in application configuration as pin configurations could
then be modified in using overlays.

Pin control nodes are defined using Linux pinctrl bindings. For instance, usart1_tx_pb6 is
defined as
+usart1_tx_pb6: usart1_tx_pb6 {
+       pinmux = <STM32_PINMUX('B', 6, AF7)>;
+       bias-pull-up;
+};

Definition of nodes usart1_tx_pb6 and usart1_rx_pb7 could be provided manually but to assist
in board configuration, SoC variant package specific -pinctrl.dtsi files are provided and should
be included in the board dts files.

For instance, for board disco_l475_iot1:
 #include <st/l4/stm32l475Xg.dtsi>
+#include <st/l4/stm32l475r(c-e-g)tx-pinctrl.dtsi>
 #include "arduino_r3_connector.dtsi"

*-pinctrl.dtsi files provide known working pin configurations which could be overwritten at
board level to fit a specific need. These files are hosted in hal_stm32 module (under dts/st/),
one for each STM32 SoC package. These files are generated from STM32 .xml description files
(currently delivered in ST STM32CubeMx tool). Using the appropriate -pinctrl.dtsi file allows
benefiting from the full list of valid pinctrl nodes for a SoC package that is used on a board,
reducing the risk of pin misconfiguration.
The -pinctrl.dtsi generation script is also provided and could be used to add or modify pinctrl
node variants, or to provide a new set of -pinctrl.dtsi files if a new STM32 SoC shows up.

This new method could coexist with current pinmux.c configuration (beware of the pin conflicts
as usual, though). 

For now, PR #25996 only provides the tooling for dts based pin configuration. Only one driver
(STM32 serial) and 2 boards have been modified as proof of concept (cf PR for more details).
Next step is to extend its usage to existing STM32 boards and drivers. Target is to get rid of in
tree pinmux.c files for V2.5.0, so their usage could be deprecated.
I invite STM32 codeowners and contributors to help us in this task. Out of tree users are also
encouraged to perform this change on their respective boards.

Big thanks to Gerard Marull-Paretas (@gmarull) who helped me with this PR and provided the
pinctrl.dtsi files generation script.

Cheers
Erwan


RFC: API Change: k_work

Peter A. Bigot
 

In accordance with policy your attention is drawn to #28794 which summarizes and outlines the motivation for a change to the k_work infrastructure, specifically with how k_delayed_work functions behave.  These changes are motivated by #27356.

Please raise high level concerns in that issue, and the specific changes in #28589.

Peter


Zephyr Project: APIs - Tue, 09/29/2020 4:00pm-5:00pm, Please RSVP #cal-reminder

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

Reminder: Zephyr Project: APIs

When: Tuesday, 29 September 2020, 4:00pm to 5:00pm, (GMT+00:00) UTC

Where:Microsoft Teams Meeting

An RSVP is requested. Click here to RSVP

Organizer: devel@...

Description:

Meeting decisions/discussions in their respective PRs, tracked here: https://github.com/zephyrproject-rtos/zephyr/projects/18


________________________________________________________________________________
+1 321-558-6518 United States, Orlando (Toll)
Conference ID: 317 990 129#
Local numbers | Reset PIN | Learn more about Teams | Meeting options
 
 
________________________________________________________________________________


Enabling LE Periodic Advertising for nRF8240-dongle

Anupam Roy
 

Hello Zephyr Developers,

 I am trying to enable BT 5.0 features - 2MPHY & CODED PHY, LE Extended Advertising & Periodic Advertising features for my nRF52840 USB dongle with Linux Host (Bluez)

In order to enable EXT & Periodic Advertising, I modified my prj.conf file in following way

 

 --- a/samples/bluetooth/hci_usb/prj.conf
+++ b/samples/bluetooth/hci_usb/prj.conf
@@ -5,6 +5,8 @@ CONFIG_UART_INTERRUPT_DRIVEN=y

 CONFIG_BT=y
 CONFIG_BT_HCI_RAW=y
+CONFIG_BT_CTLR_ADV_EXT=y
+CONFIG_BT_CTLR_ADV_PERIODIC=y

 CONFIG_USB=y
 CONFIG_USB_DEVICE_STACK=y

 

After establishing connection, following is the HCI trace for "LE Remote feature Read" request

Even though, CSA#2 & Extended Advertising ae enabled, somehow Periodic Advertising feature is missing.

Please suggest if I am missing something. Thank You

 

< HCI Command: LE Read Remote Used Features (0x08|0x0016) plen 2                                                                                                                                                   

  Handle: 0


> HCI Event: LE Meta Event (0x3e) plen 12                                                                                                                                                                           

      LE Read Remote Used Features (0x04)
        Status: Success (0x00)
        Handle: 0
        Features: 0xff 0x59 0x01 0x00 0x00 0x00 0x00 0x00
          LE Encryption
          Connection Parameter Request Procedure
          Extended Reject Indication
          Slave-initiated Features Exchange
          LE Ping
          LE Data Packet Length Extension
          LL Privacy
          Extended Scanner Filter Policies
          LE 2M PHY
          LE Coded PHY
          LE Extended Advertising
         
Channel Selection Algorithm #2
          Minimum Number of Used Channels Procedure
 

 

BR,

-Anupam Roy

 


API meeting agenda: 2020-09-29

Peter A. Bigot
 

Carles has asked me to stand in for him in coordinating this week's API telecon.

Topics include:

- Triage #28220
- Highlight #28579 and discuss whether this needs to follow the "incompatible API change" process.
- Renewed call for reviews of #27360
- Review of To Do and In Progress items in API project to see what might make 2.5
- Anything else added to the Triage column of the API Project
- Anything else raised in the slack #api channel or at the meeting

Teams link: https://teams.microsoft.com/l/meetup-join/19%3ameeting_NWU2MjZlYWEtZDcwMi00MWQzLTgwMjEtNDdkYjQwMjBjMmFj%40thread.v2/0?context=%7b%22Tid%22%3a%22af0096d9-700c-411a-b795-b3dd7122bad2%22%2c%22Oid%22%3a%22841a7c92-7816-4faf-9887-5e334e88f6d8%22%7d

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


How to check if a Kconfig string is empty? #builds #defines

arnaud.durand@...
 

Given this Kconfig:
config MY_STR
    string "A string"


The directive #if defined(CONFIG_MY_STR) will eval to true for the default empty string.

How to check if CONFIG_MY_STR is an empty string at compile time? Is it a better practice to use a second boolean value (e.g. CONFIG_USE_MY_STR) like the following?
config MY_STR
    string "A string"
    depends on USE_MY_STR

config USE_MY_STR
    bool "Enable MY_STR"


Zephyr v2.4.0 released

Maureen Helm
 

Hi everyone,

We are pleased to announce the release of Zephyr RTOS version 2.4.0!

 

Major enhancements with this release include:

  • Introduced initial support for virtual memory management.
  • Added Bluetooth host support for periodic advertisement and isochronous channels.
  • Enabled the new TCP stack, TCP2, by default. This stack was introduced in Zephyr v2.1.0 to improve network protocol testability with open source tools.
  • Introduced a new toolchain abstraction with initial implementations for GCC and LLVM/Clang, and groundwork for future support of commercial toolchains.
  • Moved to using C99 integer types and deprecate Zephyr integer types. The Zephyr types can be enabled by Kconfig DEPRECATED_ZEPHYR_INT_TYPES option.

 

During this release cycle we also:

  • Migrated to a new CI infrastructure.
  • Started aggregating board farm test results from multiple companies.
  • Agreed on a set of MISRA-based coding guidelines and a plan to implement them.
  • Reduced a large backlog of low priority bugs.

 

The detailed release notes can be found here:

https://github.com/zephyrproject-rtos/zephyr/releases/tag/zephyr-v2.4.0

 

The next release, v2.5.0, is scheduled for January 29th, 2021. We’ll select a release manager in the next few days. The merge window is now open!

 

Thank you to everyone that contributed features, documentation, testing, infrastructure, and bug fixes!

 

Maureen


Re: Zephyr v2.4.0-rc3 tagged

Chettimada, Vinayak Kariappa
 

Hi Maureen,

 

> The final release remains scheduled for 25 Sep.

 

I see that one of my PR has not been merged, because there was a merge conflict introduced due to another PR that was merged.

 

PR: https://github.com/zephyrproject-rtos/zephyr/pull/28089

 

This PR was submitted 19 days ago, covering a bug reported by a user. It has since not got reviews after repeated reminders to reviewers until “it's a big change that fixes one low priority bug. do we really need it?

“ and “it is this late in the release cycle…” decision being taken. (Discussions in #release slack channel)

 

There are 142 low priority bugs still open as mentioned in this email chain.

A bug is a bug, an assignee works on a fix during the release stabilization period.

Fix PR could be submitted by assignee before the next Release Candidate, these PR shall be merged else there is no point in classifying medium and low priority if the fixes are not merged because release criteria of < 150 low priority bugs is already met because of other PRs being closed.

 

There should be a RC4 considering that all medium and low priority bugs having a submitted PR that is passing CI gets reviews/approvals. These PRs can be omitted if there are pending change requests and it is decided to be removed from v2.4 milestone.

 

Regards,

Vinayak

 

 

From: devel@... <devel@...> On Behalf Of Maureen Helm via lists.zephyrproject.org
Sent: 25 September 2020 01:19
To: announce@...; devel@...
Subject: [Zephyr-devel] Zephyr v2.4.0-rc3 tagged

 

Hi everyone,

The third release candidate for Zephyr v2.4.0 has been tagged (v2.4.0-rc3). The full release log can be found here:

https://github.com/zephyrproject-rtos/zephyr/releases/tag/v2.4.0-rc3

 

This is hopefully the last release candidate before we finalize the v2.4.0 release. We have satisfied release quality criteria [1] with the exception of one high priority bug. Current bug counts are:

    High: 1

    Medium: 18

    Low: 142

 

The outstanding high priority bug is to deprecate and remove old k_mem_pool/sys_mem_pool APIs [2]. The TSC decided this week that the PR fixing this bug [3] is too extensive to merge at this late stage of the release cycle. We have documented the mem_pool APIs as deprecated [4], but will wait until after the v2.4.0 release to tag them with the __deprecated attribute and fix in-tree uses, then remove the APIs completely in v2.6.0 LTS.

 

The purpose of this release candidate is to do one last round of QA testing and finalize release notes. I don’t plan to merge anything other than documentation unless QA testing reveals new bugs that cause us to no longer satisfy release quality criteria.

 

The final release remains scheduled for 25 Sep.

 

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!

 

[1] https://docs.zephyrproject.org/latest/development_process/release_process.html#release-quality-criteria

[2] https://github.com/zephyrproject-rtos/zephyr/issues/24358

[3] https://github.com/zephyrproject-rtos/zephyr/pull/28611

[4] https://github.com/zephyrproject-rtos/zephyr/pull/28646

 

Maureen


Zephyr v2.4.0-rc3 tagged

Maureen Helm
 

Hi everyone,

The third release candidate for Zephyr v2.4.0 has been tagged (v2.4.0-rc3). The full release log can be found here:

https://github.com/zephyrproject-rtos/zephyr/releases/tag/v2.4.0-rc3

 

This is hopefully the last release candidate before we finalize the v2.4.0 release. We have satisfied release quality criteria [1] with the exception of one high priority bug. Current bug counts are:

    High: 1

    Medium: 18

    Low: 142

 

The outstanding high priority bug is to deprecate and remove old k_mem_pool/sys_mem_pool APIs [2]. The TSC decided this week that the PR fixing this bug [3] is too extensive to merge at this late stage of the release cycle. We have documented the mem_pool APIs as deprecated [4], but will wait until after the v2.4.0 release to tag them with the __deprecated attribute and fix in-tree uses, then remove the APIs completely in v2.6.0 LTS.

 

The purpose of this release candidate is to do one last round of QA testing and finalize release notes. I don’t plan to merge anything other than documentation unless QA testing reveals new bugs that cause us to no longer satisfy release quality criteria.

 

The final release remains scheduled for 25 Sep.

 

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!

 

[1] https://docs.zephyrproject.org/latest/development_process/release_process.html#release-quality-criteria

[2] https://github.com/zephyrproject-rtos/zephyr/issues/24358

[3] https://github.com/zephyrproject-rtos/zephyr/pull/28611

[4] https://github.com/zephyrproject-rtos/zephyr/pull/28646

 

Maureen