|
Re: [RFC] SMP support for RISC-V privilege architecture
Katsuhiro Suzuki
Hello Kumar,
Sorry for multi posting. Zephyr ML has very long delay to deliver my mail...?? Anyway, thanks a lot for your comment. On 2020/10/06 23:57, Kumar Gala wrote: I'll add the config.On Oct 6, 2020, at 4:04 AM, Katsuhiro Suzuki <katsuhiro@katsuster.net> wrote:Would probably be good to add a second SMP config for qemu_riscv32 for SMP=y. You can look at the boards/x86/qemu_x86 to see examples of having different configs. BTW, QEMU can choose SMP mode or non-SMP mode by command option. qemu_x86 Zephyr users never want to use non-SMP mode? I remember a help of CONFIG_USE_SWTCH said that: "In uniprocess situations where the architecture provides both, _arch_switch incurs more somewhat overhead and may be slower.". I think RISC-V may cover high-end from low-end, so I try to keep old style context switch mechanism. On the other hand, it seems x86_64 port don't implement old style. Should we keep old one or it depends on each architectures? As for testing, I’m guessing the main test to make sure runs and passes is tests/kernel/smp.Thanks! I'll try it and report results. - kBest Regards, Katsuhiro Suzuki
|
|
|
|
Zephyr Project: APIs - Tue, 10/06/2020 4:00pm-5:00pm, Please RSVP
#cal-reminder
devel@lists.zephyrproject.org Calendar <devel@...>
Reminder: Zephyr Project: APIs When: Tuesday, 6 October 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
________________________________________________________________________________
|
|
|
|
Re: API meeting: agenda
Carles Cufi
Hi all,
toggle quoted messageShow quoted text
An additional item for today: - Cleanup of work queue API doc - PR: https://github.com/zephyrproject-rtos/zephyr/pull/28824
-----Original Message-----
|
|
|
|
Re: [RFC] SMP support for RISC-V privilege architecture
Kumar Gala
On Oct 6, 2020, at 4:04 AM, Katsuhiro Suzuki <katsuhiro@katsuster.net> wrote:Would probably be good to add a second SMP config for qemu_riscv32 for SMP=y. You can look at the boards/x86/qemu_x86 to see examples of having different configs. As for testing, I’m guessing the main test to make sure runs and passes is tests/kernel/smp. Andrew, can probably mention other tests or aspects to be aware of. - k
|
|
|
|
API meeting: agenda
Carles Cufi
Hi all,
Agenda for today, sorry for the short notice. - Pinmux and pinctrl API: Decide what the priorities for this are, and how to get to LTS with it - Issue: https://github.com/zephyrproject-rtos/zephyr/issues/22748 Since there are no other new items in the Triage column, I would propose we go through the To Do and In Progress items and make sure they are still applicable and they have a person assigned who is actively working on them. 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 Regards, Carles
|
|
|
|
[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
|
|
|
|
[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@lists.zephyrproject.org> wrote: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 pinctrl nodes": https://github.com/zephyrproject-rtos/zephyr/pull/25996 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
________________________________________________________________________________
|
|
|
