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@...

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

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

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