Date   

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



Devicetree GPIO output initialization #gpio

markus.prager@...
 

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 = <&gpiod 2 (GPIO_ACTIVE_HIGH)>; /* PD2, PWR enable pin */
irq-gpios = <&gpioc 7 GPIO_ACTIVE_HIGH>, <&gpioc 8 GPIO_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 = <&gpiod 2 (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


Re: Attn: Maintainers - LTS Release Notes v2.7.0

Christopher Friedt
 

Hi Maintainers,

On Wed, Sep 22, 2021 at 12:56 PM Christopher Friedt
<chrisfriedt@...> wrote:
It's that time of the release cycle, and I would like to invite all
maintainers to make PR's for the v2.7.0 LTS release notes [1].
[1] doc/releases/release-notes-2.7.rst
In case you have not already submitted release notes, or in case there
are any last minute changes, this is just a reminder to please submit
a PR for release notes at your earliest convenience.

Otherwise, thanks to everyone who has already submitted :-)

C


Cancelled Event: Zephyr Memory Footprint - biweekly discussion - Monday, October 11, 2021 #cal-cancelled

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

Cancelled: Zephyr Memory Footprint - biweekly discussion

This event has been cancelled.

When:
Monday, October 11, 2021
3:00pm to 4:00pm
(UTC+00:00) UTC

Where:
Microsoft Teams Meeting

Organizer: devel@...

Description:
Working doc: https://docs.google.com/document/d/1bnQLJKVhgI3zkk3MsSXun8onEsA8z1Rf5ohdbCHASmU/edit#heading=h.x36xe8bnwr9r

________________________________________________________________________________
Microsoft Teams meeting
Join on your computer or mobile app
Click here to join the meeting
Or call in (audio only)
+1 321-558-6518,,546018126# United States, Orlando
Phone Conference ID: 546 018 126#
 
 
________________________________________________________________________________


Dev-Review Meeting Agenda Oct 6th

Kumar Gala
 

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


Integrating gsm_modem sample code with mqtt_publisher sample #gsm_modem #ppp #networking

Brent (214500040@ukzn) <214500040@...>
 

Hello Everyone
 
I am attempting to connect my NRF5340dk to a MQTT test server (test.mosquitto.org / 5.196.95.208) via a GSM module (Ublox LARA R211 EVK).
 
- I integrated the gsm_modem sample with the mqtt_publisher sample. 
- I flashed my application to nrf5340dk_nrf5340_cpuapp.
- The ppp connection was successfully established and I could ping google via the nrf53 dev kit.
- Whenever I ping'd google, I could view the data output via "CONFIG_MODEM_GSM_UART_NAME" i.e. UART port 1 (This NRF53 UART port was bridged to the GSM module).
- However whenever the MQTT code ran, there was no data output on  UART port 1 (CONFIG_MODEM_GSM_UART_NAME).
 
How should I approach this issue? i.e how do I route the mqtt connection via the GSM module.
 
Any advice would be truly appreciated!


RFC: drivers: serial: Use microseconds to represent timeout in asynchronous API

Chruściński, Krzysztof
 

Hi,

there is an open PR with change UART Asynchronous API to use microseconds to represent timeouts in uart_tx() and uart_rx_enable() functions (currently milliseconds are used). Note that UART Asynchronous API is marked as unstable.


Note that when it's merged, code will compile but provided argument will be interpreted differently by the driver! Action is required on the user side to multiply previously provided argument by 1000 to get the same behavior.

regards,
Krzysztof


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

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

Reminder: Zephyr Project: APIs

When:
10/05/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
 
 
________________________________________________________________________________


Event: Zephyr: Networking Forum - 10/05/2021 #cal-reminder

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

Reminder: Zephyr: Networking Forum

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

Where:
Microsoft Teams Meeting

Organizer: tsc@...

An RSVP is requested. Click here to RSVP

Description:


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


API meeting: agenda

Carles Cufi
 


Now: Zephyr: Toolchain Working Group - 10/04/2021 #cal-notice

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

Zephyr: Toolchain Working Group

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

Where:
Microsoft Teams Meeting

Organizer: Torsten Rasmussen

Description:

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


Event: Zephyr: Toolchain Working Group - 10/04/2021 #cal-reminder

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

Reminder: Zephyr: Toolchain Working Group

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

Where:
Microsoft Teams Meeting

Organizer: Torsten Rasmussen

An RSVP is requested. Click here to RSVP

Description:

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


Networking Forum Agenda

Lubos, Robert
 

Hi all,

 

We currently have one item on the agenda for the networking forum Tomorrow:

 

Please let me know if there is any other topics you’d like to cover during the forum.

 

Meeting notes:

https://docs.google.com/document/d/1qFsOpvbyLzhflJbbv4Vl__497pKHDoUCy9hjAveyCX0

 

Shared Folder:

https://drive.google.com/drive/folders/1j6d0FLeOjiMil1Ellb59AsfHdzuWdAAc?usp=sharing

 

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

 

Regards,
ROBERT LUBOS | Senior Firmware Engineer
M +48 504 088 482 | Krakow, Poland
nordicsemi.com | devzone.nordicsemi.com

Nordic_logo_signature

 


Zephyr v2.7.0-rc4

Christopher Friedt
 

Hi Zephyr Community!

We are very happy to announce the 4th candidate for the v2.7.0 LTS release \o/

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

This release will be codenamed "Single-Handed Speed Run" for.. reasons [1].

Some important notes:
- We are introducing a new GitHub label "Blocker" to indicate an issue
blocks release
- Generally, the "Blocker" label is only assigned to existing medium
or high priority bugs
- To promote an issue to "Blocker" status, please bring it to the
attention of the release team [2]
- As of rc4, we will only be merging bug-fixes that have the label "Blocker"
- Code Freeze is on 2021-10-08. At that point, there will be no more
code changes to v2.7.0

Thanks to all of our valued members who have been verifying tagged
release candidates and for everyone who has contributed to this RC!

C

[1] https://www.youtube.com/watch?v=wVcmZJSxYPQ
[2] https://discord.com/channels/720317445772017664/733037890514321419


Re: TinyCrypt end of life - Help needed

Flavio Ceolin
 

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



Re: TinyCrypt end of life - Help needed

Flavio Ceolin
 

Good point, will forward to that list too.

Hi Flavio - it seems like this should be sent to users@ too, no?

On Fri, Oct 01 2021, Flavio Ceolin via lists.zephyrproject.org wrote:
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


561 - 580 of 8639