Date   

Dev-Review Meeting Agenda Oct 14th

Kumar Gala
 

drivers: syscon: Set default for CONFIG_SYSCON to y
- https://github.com/zephyrproject-rtos/zephyr/pull/38762


Plus anything anyone else has.

- k


Changes to project roles and github permissions

Nashif, Anas
 

Hello everyone,

We recently made changes to the project roles and the access levels given to contributors on github. Please refer to the full documentation of the roles below for more details:

https://docs.zephyrproject.org/latest/development_process/project_roles.html

The summary of the changes:

- Contributors are initially only given Read access to the Zephyr GitHub repository. Specifically, at the Read access level, Contributors are not allowed to assign reviewers to their own pull requests. An automated process will assign reviewers.
- Contributors who show dedication and skill are granted the Github Triage permission[1] level to the Zephyr GitHub repository. You may nominate yourself, or another GitHub user, for promotion to the Github Triage permission level by creating a GitHub issue, using the nomination issue type: Go to Issues, click on “New Issue” and select “Contributor Nomination” issue type, submit the issue and wait for it to be processed.
- Contributors granted the Github Triage permission level are permitted to add reviewers to a pull request and can be added as a reviewer by other GitHub users. Contributor votes on pull requests are not counted with respect to accepting and merging a pull request. However, Contributors comments and requested changes should still be considered by the pull request author.
- Contributors are promoted to the Collaborator role by adding the GitHub user name to one or more collaborators sections of the MAINTAINERS File in the Zephyr repository. Collaborator votes on pull requests can block or approve the pull request.

Many new contributors already had the same access as “Collaborators” (Write access). This access will be reset and only collaborators and maintainers referenced in the MAINTAINER file will have write access now.

If you notice that you do not have the same access as before, then most likely you are not in the MAINTAINER file. You will need to add yourself to the MAINTAINER file in the areas you are most active in using a pull request, once merged and approved, you will be assigned the collaborator access level.


This change will take effect Monday, October 18th.

If you have any concerns or questions, please reply to this email or use discord.

Thank you,

Anas


[1] https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-permission-levels-for-an-organization


[RFC] TF-M: Split trusted-firmware-m repository

Andersson, Joakim <Joakim.Andersson@...>
 

Hi.

I’ve created a request for comments to split the zephyr project maintained repository trusted-firmware-m into a fork of the individual upstream repositories

More details in the RFC github issue: https://github.com/zephyrproject-rtos/zephyr/issues/39353

Any feedback is welcome in the github issue.

-Joakim Andersson


Re: SMP support for RISC-V based Microchip PolarFire SoC Icicle Kit

conor.paxton@...
 

Hi There,

Thanks to everyone for the feedback thus far, it is really appreciated. Our plan is to modify the code that affects the arch/riscv for smp support so that it is generic/agnostic. We will also work on getting the port working on Qemu with the provided models. Also, it really great to hear that the port worked in Renode! this is a serious advantage for us.

I will report back here, as we make progress.

Kind Regards,

Conor

conor.paxton@...
petermcshane@...


Zephyr v2.7.0-rc5

Christopher Friedt
 

Hi Zephyr Community!

We are very happy to announce the 5th (and likely last) release
candidate for the v2.7.0 LTS \o/

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

This release will be codenamed "A Case of The Mondays" for.. reasons.

Some important notes:
- This RC coincides with the M3 Code Freeze on Oct 8th (see [1])

Maintainers:
- Please ensure that you have submitted release notes
- Check the appropriate box(es) in the Release Checklist [2]

Looking forward to the final release in just a few days!

C

[1] https://github.com/zephyrproject-rtos/zephyr/wiki/Program-Management
[2] https://github.com/zephyrproject-rtos/zephyr/issues/35966


Event: Zephyr Project: APIs - 10/12/2021 #cal-reminder

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

Reminder: Zephyr Project: APIs

When:
10/12/2021
4:00pm to 5:00pm
(UTC+00:00) UTC

Where:
Microsoft Teams Meeting

Organizer: devel@...

An RSVP is requested. Click here to RSVP

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
 
 
________________________________________________________________________________


API meeting: agenda

Carles Cufi
 

Hi all,

I won't be able to attend today's meeting, but Keith has kindly offered his help chairing it.

Agenda for today:

- PM structure optimization
- Issue: https://github.com/zephyrproject-rtos/zephyr/issues/39286

- I2C API change
- PR: https://github.com/zephyrproject-rtos/zephyr/pull/39006

Time permitting, we can continue with pinctrl.

- Pinctrl: Now focusing on #37572 as the single PR to target our efforts
- PR: https://github.com/zephyrproject-rtos/zephyr/pull/37572
- Updates by Gerard and Kumar on the state of the PR
- Discussion, specifically Devicetree layout format: https://github.com/zephyrproject-rtos/zephyr/discussions/35077#discussioncomment-1201394

If you have additional items please let me know.

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://lists.zephyrproject.org/g/devel/calendar
https://github.com/zephyrproject-rtos/zephyr/projects/18

Minutes:
https://docs.google.com/document/d/1lv-8B5QE2m4FjBcvfqAXFIgQfW5oz6306zJ7GIZIWCk/edit

Regards,

Carles


Re: [PATCH] Fix the problem that it cannot work under mimxrt1061cvl5a SOC

Henrik Brix Andersen
 

Hi Zhihao,

Thank you for your contribution. Please submit it as a pull request on GitHub.
See https://docs.zephyrproject.org/latest/contribute/index.html#contribution-workflow for detailed instructions.

Best regards,
Birx
--
Henrik Brix Andersen

On 9 Oct 2021, at 09.39, Zhou, ZhihaoX <zhihaox.zhou@...> wrote:

There is no built-in SDRAM area in mimxrt1061 cvl5a, which makes zephyr unable to work on 1061 SOC

Best Regards
Zhihao


<0001-Fix-the-problem-that-it-cannot-work-under-mimxrt1061.patch>


[PATCH] Fix the problem that it cannot work under mimxrt1061cvl5a SOC

Zhou, ZhihaoX <zhihaox.zhou@...>
 

There is no built-in SDRAM area in mimxrt1061 cvl5a, which makes zephyr unable to work on 1061 SOC

 

Best Regards

Zhihao

 


Re: SMP support for RISC-V based Microchip PolarFire SoC Icicle Kit

Olof Johansson
 

I believe qemu also has models for the SMP SiFive models (which, I'd
expect, have a very similar CPU complex to the PolarFire). Making sure
that the port works there to enable a broader set of developers to run
tests on it would be a great venue for making the SMP support generic
per Anas' request.

Super excited to see this enabled!


-Olof

On Thu, Oct 7, 2021 at 7:28 AM Nashif, Anas <anas.nashif@...> wrote:

Conor,

Thank you for sharing, this is great.

Just a quick comment, from a quick look at the links below, I noticed the arch changes to riscv adding smp support and other generic code references your SOC and hardware, this need to be made generic and vendor/soc agnostic before you submit to the zephyr tree.



Thanks,

Anas



From: <devel@...> on behalf of "conor.paxton via lists.zephyrproject.org" <conor.paxton=microchip.com@...>
Reply-To: "conor.paxton@..." <conor.paxton@...>
Date: Thursday, October 7, 2021 at 9:24 AM
To: "devel@..." <devel@...>
Subject: [Zephyr-devel] SMP support for RISC-V based Microchip PolarFire SoC Icicle Kit



Hi there,

We have been working on a port of zephyr for the Microchip PolarFire SoC Icicle Kit, focusing on SMP support. It is very much in initial stages, however,
we have tested it on our hardware using the smp/pi application and have had good results.
We would now like to put it out there, to see if we could get some feedback. We are on an older version of the zephyr code base (2.4.99), which we plan on updating
to the latest release in the coming weeks.

You can find the source our code here:
https://github.com/polarfire-soc/zephyr/tree/mpfs-zephyr

And information about the PolarFire SoC and Icicle Kit here:
https://github.com/polarfire-soc/zephyr/tree/mpfs-zephyr


Kind Regards,

Conor Paxton

conor.paxton@...
petermcshane@...


Event: Zephyr Project: Dev Meeting - 10/07/2021 #cal-reminder

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

Reminder: Zephyr Project: Dev Meeting

When:
10/07/2021
3:00pm to 4:00pm
(UTC+00:00) UTC

Where:
Microsoft Teams Meeting

Organizer: devel@...

An RSVP is requested. Click here to RSVP

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 6th

Gerard Marull Paretas
 

I am not sure if it is suitable for dev-review, otherwise for the next API meeting:

- Improve API headers documentation
https://github.com/zephyrproject-rtos/zephyr/issues/30466
 


Re: Dev-Review Meeting Agenda Oct 6th

Kumar Gala
 

On Oct 6, 2021, at 8:19 AM, Kumar Gala <kumar.gala@...> wrote:

cmake: APPLICATION_CONFIG_DIR support implemented
- https://github.com/zephyrproject-rtos/zephyr/pull/38229

drivers: regulator: convert to gpio_dt_spec
- https://github.com/zephyrproject-rtos/zephyr/pull/37689

Plus anything anyone else has.

- k
Will bring this up and see if discussion in API meeting is more appropriate:

- Improve API headers documentation
https://github.com/zephyrproject-rtos/zephyr/issues/30466

- k


Re: Dev-Review Meeting Agenda Oct 6th

Bolivar, Marti
 

Just for clarity, this is the agenda for October 7, NOT October 6.

Meeting starts in about half an hour as usual.

On Wed, Oct 06 2021, Kumar Gala via lists zephyrproject org wrote:
cmake: APPLICATION_CONFIG_DIR support implemented
- https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fzephyrproject-rtos%2Fzephyr%2Fpull%2F38229&;data=04%7C01%7Cmarti.bolivar%40nordicsemi.no%7C0cb1d1cbf5774ffeaab708d988cbe5d3%7C28e5afa2bf6f419a8cf6b31c6e9e5e8d%7C0%7C0%7C637691232628390324%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=SkuO1jdBrfgFa0%2BFrsKxas%2BagF%2Fs%2BLeENYu%2B3dlTw9A%3D&amp;reserved=0

drivers: regulator: convert to gpio_dt_spec
- https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fzephyrproject-rtos%2Fzephyr%2Fpull%2F37689&;data=04%7C01%7Cmarti.bolivar%40nordicsemi.no%7C0cb1d1cbf5774ffeaab708d988cbe5d3%7C28e5afa2bf6f419a8cf6b31c6e9e5e8d%7C0%7C0%7C637691232628390324%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=5a61weXSD8SChH8hqxVHrwyBEjcAuRo%2F0e046P%2BIfnc%3D&amp;reserved=0

Plus anything anyone else has.

- k




Re: SMP support for RISC-V based Microchip PolarFire SoC Icicle Kit

Nashif, Anas
 

Conor,

Thank you for sharing, this is great.

Just a quick comment, from a quick look at the links below, I noticed the arch changes to riscv adding smp support and other generic code references your SOC and hardware, this need to be made generic and vendor/soc agnostic before you submit to the zephyr tree.

 

Thanks,

Anas

 

From: <devel@...> on behalf of "conor.paxton via lists.zephyrproject.org" <conor.paxton=microchip.com@...>
Reply-To: "conor.paxton@..." <conor.paxton@...>
Date: Thursday, October 7, 2021 at 9:24 AM
To: "devel@..." <devel@...>
Subject: [Zephyr-devel] SMP support for RISC-V based Microchip PolarFire SoC Icicle Kit

 

Hi there,

We have been working on a port of zephyr for the Microchip PolarFire SoC Icicle Kit, focusing on SMP support. It is very much in initial stages, however,
we have tested it on our hardware using the smp/pi application and have had good results.
We would now like to put it out there, to see if we could get some feedback. We are on an older version of the zephyr code base (2.4.99), which we plan on updating
to the latest release in the coming weeks.

You can find the source our code here:
https://github.com/polarfire-soc/zephyr/tree/mpfs-zephyr

And information about the PolarFire SoC and Icicle Kit here:
https://github.com/polarfire-soc/zephyr/tree/mpfs-zephyr


Kind Regards,

Conor Paxton

conor.paxton@...
petermcshane@...


Re: TinyCrypt end of life - Help needed

Szymon Janc
 

Hi,

There is no information about tinycrypt being EOL on webpage nor github...


On Fri, 1 Oct 2021 at 22:37, Flavio Ceolin <flavio.ceolin@...> wrote:
Send it to users list as well.

> Hello,
>
> Recently Intel notify us about TinyCrypt end of life because Zephyr is
> one major project still using it.
>
> In order to respond it properly, the Zephyr PSIRT team needs to
> understand how TinyCrypt is currently used on Zephyr. An
> initial research shows that only the Bluetooth subsystem depends
> (exclusively) on this library for hashing and elliptic curves.
>
> We need the community feedback to know which other places are using
> TinyCrypt, which features are being used and finally what is the most
> constraint platform currently supported that is using TinyCrypt.
>
> Based on the answers we will come up with some proposals to mitigate
> this problem.
>
> Regards,
> Flavio Ceolin
>
>
>







--
pozdrawiam
Szymon K. Janc


Re: SMP support for RISC-V based Microchip PolarFire SoC Icicle Kit

pzierhoffer@...
 

Hi Conor

We have tried to run it in Renode and everything worked as expected!
We checked the smp/pi sample and some other basic apps like hello-world or synchronization.

We'd be happy to review it when you bump your branch on top of the latest codebase and submit the PR!

Best regards

Piotr Zierhoffer
Antmicro


On Thu, Oct 7, 2021 at 3:24 PM conor.paxton via lists.zephyrproject.org <conor.paxton=microchip.com@...> wrote:
Hi there,

We have been working on a port of zephyr for the Microchip PolarFire SoC Icicle Kit, focusing on SMP support. It is very much in initial stages, however,
we have tested it on our hardware using the smp/pi application and have had good results.
We would now like to put it out there, to see if we could get some feedback. We are on an older version of the zephyr code base (2.4.99), which we plan on updating
to the latest release in the coming weeks.

You can find the source our code here:
https://github.com/polarfire-soc/zephyr/tree/mpfs-zephyr

And information about the PolarFire SoC and Icicle Kit here:
https://github.com/polarfire-soc/zephyr/tree/mpfs-zephyr


Kind Regards,

Conor Paxton

conor.paxton@...
petermcshane@...



--
Piotr Zierhoffer
mobile: +48 696 419 606
Antmicro Ltd | www.antmicro.com
Zwierzyniecka 3, 60-813 Poznan, Poland


SMP support for RISC-V based Microchip PolarFire SoC Icicle Kit

conor.paxton@...
 

Hi there,

We have been working on a port of zephyr for the Microchip PolarFire SoC Icicle Kit, focusing on SMP support. It is very much in initial stages, however,
we have tested it on our hardware using the smp/pi application and have had good results.
We would now like to put it out there, to see if we could get some feedback. We are on an older version of the zephyr code base (2.4.99), which we plan on updating
to the latest release in the coming weeks.

You can find the source our code here:
https://github.com/polarfire-soc/zephyr/tree/mpfs-zephyr

And information about the PolarFire SoC and Icicle Kit here:
https://github.com/polarfire-soc/zephyr/tree/mpfs-zephyr


Kind Regards,

Conor Paxton

conor.paxton@...
petermcshane@...


Re: [Zephyr-users] [Zephyr-devel] TinyCrypt end of life - Help needed

Hristozov, Stefan <stefan.hristozov@...>
 

Dear Flavio,

thank you for the information!

we are using TinyCrypt in the uoscore-uedhoc [1] project, which we want to contribute to zephyr OS. We are in contact already with the responsible people at Zephyr. Our project is however agnostic regarding the crypto library, i.e., we can exchange TinyCrypt with another library. Which will be the preferred crypto library that should be used in projects like ours with Zephyr OS? mbedTLS?

Best regards
Stefan  



On Fri, 2021-10-01 at 13:37 -0700, Flavio Ceolin wrote:
Send it to users list as well.

Hello,

Recently Intel notify us about TinyCrypt end of life because Zephyr is
one major project still using it.

In order to respond it properly, the Zephyr PSIRT team needs to
understand how TinyCrypt is currently used on Zephyr. An
initial research shows that only the Bluetooth subsystem depends
(exclusively) on this library for hashing and elliptic curves.

We need the community feedback to know which other places are using
TinyCrypt, which features are being used and finally what is the most
constraint platform currently supported that is using TinyCrypt.

Based on the answers we will come up with some proposals to mitigate
this problem.

Regards,
Flavio Ceolin








-- 
Stefan Hristozov
Department Hardware Security
Fraunhofer Institute for Applied and Integrated Security AISEC
Lichtenbergstraße 11, 85748 Garching near Munich, Germany
Tel. +49 89 32299 86 157


Re: Devicetree GPIO output initialization #gpio

lairdjm
 

Hi,
Have you tried using the regulators API which was added in 2.5? https://docs.zephyrproject.org/latest/reference/peripherals/regulators.html 
Thanks,
Jamie

On Wed, 2021-10-06 at 23:56 -0700, markus.prager via lists.zephyrproject.org wrote:
Hi everybody.

I am trying to get my self written driver for a lis3dhh sensor working, but I am encountering a problem with my devicetree initialization. I have a GPIO pin that powers the sensor, which needs to output a HIGH signal for the sensor to turn on. Turning on the sensor takes about 10ms according to the data sheet. Now the problem is that I have not found a way to initialize this GPIO pin in a way so that it turns high early enough for the initialization of the lis3dhh device, since that is happening automatically as soon as Zephyr boots. See this screenshot, channel 2 is the GPIO PWR pin:



As you can see, the pin does not get pulled to high early enough for the sensor to boot before Zephyr tries to initialize the sensor. I don't know why it is actually doing any of this, since i only initialized the pin as being active high. For some reason it then turns high on its own (???). Interestingly enough, this problem occurs very consistently every second boot.
In the following screenshot i rebooted the device at ~2.5s, 5s, 8s and 11s. As you can see, the PWR pin only turns low every second boot, and that is the time when the initialization does not work. Like I said, I also don't know why the pin is turning on in the first place, since I have only defined the pin as being active high and nothing else. I have also taken a look into the entire devicetree that gets built, but I could not find any other reference to this GPIO pin that would offer an explanation of what is happening to this pin.



Here is my devicetree overlay for the sensor:

&spi2 {
lis3dhh:lis3dhh@0 {
compatible ="st,lis3dhh","st,spi_lis3dhh";
status ="okay";
reg = <0>;
label ="LIS3DHH";
spi-max-frequency = <1000000>;/* max. 10MHz, currently 1MHz */
device-enable-gpios = <&gpiod2 (GPIO_ACTIVE_HIGH)>;/* PD2, PWR enable pin */
irq-gpios = <&gpioc7GPIO_ACTIVE_HIGH>, <&gpioc8GPIO_ACTIVE_HIGH>;/* INT1, PC7 & INT2, PC8 */
};
};

I have tried to initialize the device as output active, but when I try that my program will not compile:
device-enable-gpios = <&gpiod2 (GPIO_ACTIVE_HIGH |GPIO_OUTPUT_ACTIVE)>;


Is there a way to better influence the GPIO pin's behaviour? Give it a default output active value or something? Manually setting the GPIO in a function did not work, since the initialization takes place before any of that is called.

Thanks in advance for any advice or directions!
Cheers,
Markus


481 - 500 of 8574