softperipheral: Add initial sQSPI #1694

lopeztel · 2025-03-31T08:55:03Z

softperipheral/CHANGELOG.rst contains the list of changes.

CLAassistant · 2025-03-31T08:55:10Z

All committers have signed the CLA.

annwoj · 2025-04-01T10:36:29Z

softperipheral/CHANGELOG.rst

+See the following list changes:
+
+* Added:
+  * First implementation of Soft Peripheral **sQSPI**.


Suggested change

* First implementation of Soft Peripheral **sQSPI**.

* The first implementation of Soft Peripheral sQSPI for the nRF54L15 and nRF54H20 SoCs.

empty line needed

Addressed in f5a9456

annwoj · 2025-04-01T10:39:35Z

softperipheral/doc/introduction.rst

+It also allows to include additional instances of a peripheral in case the platform lacks sufficient hardware peripherals.
+
+In most cases, the features and performance of a soft peripheral are equivalent to those of a hardware peripheral.
+However, there may be some limitations. For more information, see the corresponding limitations page.


Suggested change

However, there may be some limitations. For more information, see the corresponding limitations page.

However, there may be some limitations. For more information, see the :ref:`sqspi_limitations` page.

Addressed in f5a9456

softperipheral/doc/introduction.rst

annwoj · 2025-04-01T10:47:58Z

softperipheral/doc/sQSPI/CHANGELOG.rst

+v0.1.0
+************


tbc - Is a separate versioning needed?

Suggested change

v0.1.0

************

|NCS| v3.0.0

************

Changelog at root level is meant to track changes for NCS releases, but as we add more softperipherals we will have each of them have their own version

annwoj · 2025-04-01T10:50:50Z

softperipheral/doc/sQSPI/CHANGELOG.rst

+
+* Added:
+
+  * TX, RX, and TX/RX :ref:`SPI transfer modes<sqspi_features_spi_modes>`.


Suggested change

* TX, RX, and TX/RX :ref:`SPI transfer modes<sqspi_features_spi_modes>`.

* TX, RX, and TX/RX :ref:`SPI transfer modes<sqspi_features_spi_modes>` support.

Addressed in f5a9456

annwoj · 2025-04-01T11:36:29Z

softperipheral/doc/sQSPI/nrf54H20_porting_v0_1_0.rst

+
+The sQSPI application requires FastPad bias configuration to run at high frequency on SCLK.


Suggested change

The sQSPI application requires FastPad bias configuration to run at high frequency on SCLK.

Additionally, the sQSPI application requires FastPad bias configuration to run at high frequency on SCLK.

Addressed in f5a9456

annwoj · 2025-04-01T11:37:58Z

softperipheral/doc/sQSPI/nrf54H20_porting_v0_1_0.rst

+Memory retention configuration
+******************************
+
+The sQSPI Soft Peripheral requires RAM retention in order to go into the lowest power consumption mode (API call to :c:func:`nrfx_qspi2_deactivate`).


Suggested change

The sQSPI Soft Peripheral requires RAM retention in order to go into the lowest power consumption mode (API call to :c:func:`nrfx_qspi2_deactivate`).

The sQSPI Soft Peripheral requires RAM retention in order to go into the lowest power consumption mode, which can be called through the :c:func:`nrfx_qspi2_deactivate` API.

Addressed in f5a9456

annwoj · 2025-04-01T11:38:18Z

softperipheral/doc/sQSPI/nrf54H20_porting_v0_1_0.rst

+*****************
+
+The sQSPI Soft Peripheral operates directly from non-cached RAM.
+Your build environment must reserve the required RAM and ensure that it is readable/writable by both the Application Core and the FLPR.


Suggested change

Your build environment must reserve the required RAM and ensure that it is readable/writable by both the Application Core and the FLPR.

Your build environment must reserve the required RAM and ensure that it is readable and writable by both the application core and the FLPR core.

Addressed in f5a9456

annwoj · 2025-04-01T11:39:53Z

softperipheral/doc/sQSPI/nrf54H20_porting_v0_1_0.rst

+The build environment described in the :ref:`nrf54h20_porting_guide_code` section must comply with this requirements.
+This includes proper settings in linker scripts, device tree specifications (DTS), and resource allocation.


If it's a general remark, shouldn't this appear somewhere at the beginning of this guide?

Suggested change

The build environment described in the :ref:`nrf54h20_porting_guide_code` section must comply with this requirements.

This includes proper settings in linker scripts, device tree specifications (DTS), and resource allocation.

The build environment described in the :ref:`nrf54h20_porting_guide_code` section must comply with these requirements.

This includes proper settings in linker scripts, device tree specifications (DTS), and resource allocation.

Addressed in f5a9456

annwoj · 2025-04-01T11:40:49Z

softperipheral/doc/sQSPI/nrf54L15_porting_v0_1_0.rst

+Application Core and FLPR configuration
+***************************************
+
+For an sQSPI application to run properly, nRF54L15 must run at highest base clock frequency. The user/integrator should take care of this.


all suggestions are the same for nRF54L15 (as in case of nRF54H20 section)

Addressed in f5a9456

carlescufi · 2025-04-01T11:34:27Z

softperipheral/doc/sQSPI/nrf54H20_porting_v0_1_0.rst

@@ -0,0 +1,231 @@
+.. _nrf54H20_porting_guide:
+
+nRF54H20 porting guide


I find there is too much duplication between this section and the 54L15 one, but I will leave it to @annwoj and @b-gent to comment on it.

I agree, there's a lot of duplication, but when I ran a diff on it, it showed few changes across the doc (additional tables and code-blocks), so if we were to create tabs for it I think it could be confusing. For now I'd leave it as is but I'll keep thinking of some other solution

carlescufi · 2025-04-01T11:35:11Z

softperipheral/sQSPI/include/nrf54h20/sqspi_firmware_v0.1.0.h

+ * SPDX-License-Identifier: LicenseRef-Nordic-5-Clause
+ */
+
+#ifndef SP_SQSPI_FIRMWARE_H__


I personally dislike using "firmware" here. This is really a full VPR image, so I would call it "image".

carlescufi · 2025-04-01T11:44:10Z

softperipheral/sQSPI/include/nrfx_qspi2.h

+#endif
+
+/**
+ * @defgroup nrfx_qspi2 QSPI2 driver


I think we should rename this to something clearer and cleaner. For starters, this is not only QSPI, so it should not be called QSPI. I would suggest xspi or mspi. If we don't do it now, then we will have to do it later, breaking compatibility.

CC @masz-nordic

I agree this name is not perfect. The source of it is here: https://projecttools.nordicsemi.no/nightly/topic/wezen/qspi.html?cp=3_8_0_0_8_20 . So, unless we change the source, I don't think we should change the driver prefix.

I would suggest reconsidering further name changes to your APIs:

for the HW SSI, there is an existing Zephyr driver using registers directly (so no reason for nrfx_qspi2.h)

we will need a secondary SHIM for any SW peripheral anyways as there is no mechanism in place to distinguish between HW and SW instances on nrfx level (so not possible to reuse SHIM)

reusing the same names it will not be possible to run in parallel HW and SW instances

using different APIs and SHIMs will enable sw developments at own paces

two sources of nrfx_* names may be confusing for customers

Perhaps renaming is out of scope for this PR? We took the existing API approved in this PR: https://github.com/nrfconnect/nrfx/pull/724

I disagree. Either we do it now or else we will be stuck with this name forever. I think we should rename the nrfx API and then merge this PR here.

https://projecttools.nordicsemi.no/nightly/topic/wezen/qspi.html?cp=3_8_0_0_8_20 . So, unless we change the source, I don't think we should change the driver prefix.

@hubertmis I disagree, you wrote in https://github.com/nrfconnect/nrfx/pull/724 that this API would serve multiple peripherals with different names, so I think we should rename the nrfx API to something like nrfx_xspi or nrfx_mspi

@barsok I am not quite sure what you are suggesting here. You are happy with the current name or do you think we should change it?

@barsok I am not quite sure what you are suggesting here. You are happy with the current name or do you think we should change it?

I suggest changing not only the "peripheral" part of the name, but nrfx prefix as well. The reasons are above, most important are confusion for customers and making it even more confusing when nrfx will get a hw version of the same driver. Then nrfxlib and hal_nordic will contain functions with the same names

I disagree, you wrote in nrfconnect/nrfx#724 that this API would serve multiple peripherals with different names, so I think we should rename the nrfx API to something like nrfx_xspi or nrfx_mspi

The two peripherals this API currently targets are called QSPI and sQSPI. So far, all nrfx drivers follow the nrfx_peripheralname prefix. As agreed in https://github.com/nrfconnect/nrfx/pull/724 and other discussions, I would prefer not to change this rule now.

I have dismissed my nack, but I want to state that I think this is a mistake that will confuse users and developers alike.

softperipheral/doc/sQSPI/nrf54H20_porting_v0_1_0.rst

softperipheral/doc/sQSPI/nrf54L15_porting_v0_1_0.rst

softperipheral/include/softperipheral_regif.h

anangl · 2025-04-01T11:56:03Z

softperipheral/sQSPI/include/nrf54h20/sqspi_firmware.h

+
+#ifndef SQSPI_FIRMWARE_H__
+#define SQSPI_FIRMWARE_H__
+#include "sqspi_firmware_v0.1.0.h"


How about changing this to:

#if defined(NRF54L15_XXAA) #include "nrf54l15/sqspi_firmware_v0.1.0.h" #elif defined(NRF54H20_XXAA) #include "nrf54h20/sqspi_firmware_v0.1.0.h" #endif

and moving the file one level up (or maybe even place all of this next to nrfx_qspi2.c, I guess only this file is supposed to include this stuff)? This would simplify a bit the integration of the driver.

nordicjm · 2025-04-02T07:39:38Z

softperipheral/doc/sQSPI/limitations.rst

+
+Refer to the following detailed descriptions of current limitations:
+
+* sQSPI does not support slave mode operations; it can only operate as a controller (master).


spi slave has changed to spi peripheral I think

my understanding is that the names were controller and target? is this what you mean?

nordicjm · 2025-04-02T07:40:32Z

softperipheral/doc/sQSPI/nrf54H20_porting_v0_1_0.rst

+* If you set the :c:var:`nrfx_qspi2_cfg_t.skip_gpio_cfg` variable to ``true``, the GPIO configuration is not managed by the sQSPI driver and it must be manually handled by the application. 
+  This is a requirement for the nRF54H20 device.
+* If you set the :c:var:`nrfx_qspi2_cfg_t.skip_pmux_cfg` variable to ``true``, the GPIO multiplexing is not managed by the sQSPI driver and it must be manually handled by the application. 
+  This is a requirement for the nRF54H20 device.


why can't dts be used for this?

Any comments here @anangl ?

This driver does not depend on the .dts infrastructure. You can set skip_pmux_cfg = true and configure the GPIO multiplexing in any way available to the application, potentially using the device tree if that's the proper way in the integration environment (e.g. Zephyr).

annwoj

some more suggestions, thanks!

annwoj · 2025-04-02T09:06:25Z

softperipheral/CHANGELOG.rst

+************
+
+This is an initial release for Soft Peripherals.
+See the following list changes:


Suggested change

See the following list changes:

See the following list of changes:

Addressed in c5b23b6

annwoj · 2025-04-02T09:20:00Z

softperipheral/doc/introduction.rst

+It also allows to include additional instances of a peripheral in case the platform lacks sufficient hardware peripherals.
+
+In most cases, the features and performance of a soft peripheral are equivalent to those of a hardware peripheral.
+However, there may be some limitations. For more information, see the :ref:`sqspi_limitations` page.


Suggested change

However, there may be some limitations. For more information, see the :ref:`sqspi_limitations` page.

However, there may be some limitations.

For more information, see the :ref:`sqspi_limitations` page.

Addressed in c5b23b6

annwoj · 2025-04-02T09:42:42Z

softperipheral/doc/introduction.rst

+Comparison between QSPI and sQSPI support
+*****************************************
+
+You should be aware of the differences between sQSPI and QSPI features:


Suggested change

You should be aware of the differences between sQSPI and QSPI features:

The following section provides a detailed comparison of the features supported by the standard Quad Serial Peripheral Interface (QSPI) and the sQSPI.

The comparison highlights the capabilities and limitations of each interface to aid in technical decision-making for your system design.

For more details on sQSPI support, see the :ref:`sqspi_features` page.

Addressed in c5b23b6

annwoj · 2025-04-02T09:55:45Z

softperipheral/doc/sQSPI/README.rst

+sQSPI
+################


Suggested change

sQSPI

################

sQSPI

#####

Addressed in c5b23b6

annwoj · 2025-04-02T10:01:50Z

softperipheral/doc/sQSPI/features.rst

+    * Full Duplex: SPI reads by switching to receiving data (MISO) after transmitting data (MOSI).
+    * Half Duplex: Three-wire setup (MOSI/MISO, SCLK, CSN).


Suggested change

* Full Duplex: SPI reads by switching to receiving data (MISO) after transmitting data (MOSI).

* Half Duplex: Three-wire setup (MOSI/MISO, SCLK, CSN).

* Full duplex - SPI reads by switching to receiving data (MISO) after transmitting data (MOSI).

* Half duplex - Three-wire setup (MOSI/MISO, SCLK, CSN).

Addressed in c5b23b6

annwoj · 2025-04-02T12:16:35Z

softperipheral/doc/sQSPI/nrf54H20_porting_v0_1_0.rst

+Application core and FLPR configuration
+***************************************
+
+For an sQSPI application to run properly, you must adjust the settings for the nRF54H20 SoC to run at highest base clock frequency. The user/integrator should take care of this.


Suggested change

For an sQSPI application to run properly, you must adjust the settings for the nRF54H20 SoC to run at highest base clock frequency. The user/integrator should take care of this.

For an sQSPI application to run properly, you must adjust the settings for the nRF54H20 SoC to run at highest base clock frequency.

These were not addressed for any of the occurrences, please fix

annwoj · 2025-04-02T12:17:18Z

softperipheral/doc/sQSPI/nrf54H20_porting_v0_1_0.rst

+
+In as secure configuration, both the application core and the FLPR core of the nRF54H20 device must operate within a secure environment enabled by TrustZone Secure.
+
+Non-Secure settings


Suggested change

Non-Secure settings

Non-secure settings

annwoj · 2025-04-02T12:17:59Z

softperipheral/doc/sQSPI/nrf54H20_porting_v0_1_0.rst

+
+.. _nrf54H20_porting_guide_ram_configuration:
+
+RAM Configuration


Suggested change

RAM Configuration

RAM configuration

annwoj · 2025-04-02T12:19:15Z

softperipheral/doc/sQSPI/nrf54L15_porting_v0_1_0.rst

+Application core and FLPR configuration
+***************************************
+
+For an sQSPI application to run properly, you must adjust the settings for the nRF54L15 SoC to run at highest base clock frequency. The user/integrator should take care of this.


same as for nRF54H20, suggestions not applied

annwoj · 2025-04-02T12:19:27Z

softperipheral/doc/sQSPI/nrf54L15_porting_v0_1_0.rst

+    // NOTE: Setting FLPR to secure
+    NRF_SPU00_S->PERIPH[0xC].PERM = (SPU_PERIPH_PERM_SECATTR_Secure << SPU_PERIPH_PERM_SECATTR_Pos);
+
+Non-Secure settings


Suggested change

Non-Secure settings

Non-secure settings

annwoj · 2025-04-02T12:24:05Z

softperipheral/doc/sQSPI/nrf54L15_porting_v0_1_0.rst

+RAM Configuration
+*****************


Suggested change

RAM Configuration

*****************

RAM configuration

*****************

annwoj · 2025-04-02T12:24:38Z

softperipheral/doc/sQSPI/timing.rst

+
+Timing parameters
+*****************
+


is this section (heading) necessary?

annwoj · 2025-04-02T12:24:56Z

softperipheral/doc/sQSPI/timing.rst

+Timing
+######


Suggested change

Timing

######

Timing parameters

#################

softperipheral/doc/sQSPI/nrf54H20_porting_v0_1_0.rst

softperipheral/doc/sQSPI/nrf54L15_porting_v0_1_0.rst

lopeztel · 2025-04-02T13:28:24Z

After talking to @annwoj , we've decided to have a separate documentation only PR, the scope of this PR will be limited to source code

Stale, the API name will be looked at in a separate PR

carlescufi · 2025-04-02T14:06:07Z

@lopeztel @gbakke I will ack this PR to help you get it in on time but we do have an agreement on revisiting the nrfx_qspi2 API name with @hubertmis after this is merged.

b-gent · 2025-04-02T14:30:19Z

Some doc work is still needed ; will be done after rc-1.

annwoj

Approving, the doc review will continue on a separate PR

b-gent · 2025-04-02T14:34:50Z

Doc build needs to be fixed on the manifest PR if this is to be merged:
nrfconnect/sdk-nrf#21239

softperipheral/CHANGELOG.rst contains the list of changes. Signed-off-by: Luis David Lopez <[email protected]>

lopeztel requested a review from b-gent as a code owner March 31, 2025 08:55

github-actions bot added the doc-required PR must not be merged without tech writer approval. label Mar 31, 2025

NordicBuilder mentioned this pull request Mar 31, 2025

manifest: sdk-nrfxlib: softperipheral: rev cf28ddf86b89fb647ee876546770c2676b3bc63c nrfconnect/sdk-nrf#21239

Closed

lopeztel changed the title ~~softperipheral: rev cf28ddf86b89fb647ee876546770c2676b3bc63c~~ softperipheral: Add sQSPI Mar 31, 2025

lopeztel changed the title ~~softperipheral: Add sQSPI~~ softperipheral: Add initial sQSPI Mar 31, 2025

b-gent requested a review from annwoj March 31, 2025 10:48

lopeztel force-pushed the v0.1.0-rc1 branch 2 times, most recently from 7c47965 to bb0e307 Compare April 1, 2025 08:49

lopeztel requested a review from carlescufi as a code owner April 1, 2025 08:49

lopeztel force-pushed the v0.1.0-rc1 branch 2 times, most recently from 4dd7e0e to a25fe76 Compare April 1, 2025 09:18

carlescufi requested review from anangl and nordicjm April 1, 2025 11:27

annwoj reviewed Apr 1, 2025

View reviewed changes

carlescufi previously requested changes Apr 1, 2025

View reviewed changes

hubertmis reviewed Apr 1, 2025

View reviewed changes

anangl reviewed Apr 1, 2025

View reviewed changes

lopeztel force-pushed the v0.1.0-rc1 branch from a25fe76 to f5a9456 Compare April 1, 2025 14:36

nordicjm reviewed Apr 2, 2025

View reviewed changes

annwoj mentioned this pull request Apr 2, 2025

doc: add tabs extension nrfxlib nrfconnect/sdk-nrf#21300

Merged

annwoj reviewed Apr 2, 2025

View reviewed changes

lopeztel force-pushed the v0.1.0-rc1 branch from f5a9456 to 20f7251 Compare April 2, 2025 12:21

annwoj reviewed Apr 2, 2025

View reviewed changes

rlubos force-pushed the main branch from 14754f9 to f847c69 Compare April 2, 2025 12:36

lopeztel force-pushed the v0.1.0-rc1 branch 2 times, most recently from c5b23b6 to 706941e Compare April 2, 2025 13:25

hubertmis approved these changes Apr 2, 2025

View reviewed changes

softperipheral/doc/sQSPI/nrf54H20_porting_v0_1_0.rst Outdated Show resolved Hide resolved

softperipheral/doc/sQSPI/nrf54H20_porting_v0_1_0.rst Outdated Show resolved Hide resolved

softperipheral/doc/sQSPI/nrf54L15_porting_v0_1_0.rst Outdated Show resolved Hide resolved

lopeztel force-pushed the v0.1.0-rc1 branch from 706941e to 35fd397 Compare April 2, 2025 13:38

anangl approved these changes Apr 2, 2025

View reviewed changes

b-gent added the doc-postponed PR requires documentation updates, tech writer review happens later. label Apr 2, 2025

b-gent approved these changes Apr 2, 2025

View reviewed changes

annwoj approved these changes Apr 2, 2025

View reviewed changes

lopeztel force-pushed the v0.1.0-rc1 branch from 35fd397 to 183c209 Compare April 2, 2025 15:14

softperipheral: rev cf28ddf86b89fb647ee876546770c2676b3bc63c

70cb0b0

softperipheral/CHANGELOG.rst contains the list of changes. Signed-off-by: Luis David Lopez <[email protected]>

lopeztel force-pushed the v0.1.0-rc1 branch from 183c209 to 70cb0b0 Compare April 2, 2025 15:33

carlescufi approved these changes Apr 2, 2025

View reviewed changes

carlescufi merged commit b4ebdea into nrfconnect:main Apr 2, 2025
5 checks passed

lopeztel deleted the v0.1.0-rc1 branch April 23, 2025 06:45

	* First implementation of Soft Peripheral sQSPI.

	* The first implementation of Soft Peripheral sQSPI for the nRF54L15 and nRF54H20 SoCs.

	However, there may be some limitations. For more information, see the corresponding limitations page.
	However, there may be some limitations. For more information, see the :ref:`sqspi_limitations` page.


		* Added:

		* TX, RX, and TX/RX :ref:`SPI transfer modes<sqspi_features_spi_modes>`.


		The sQSPI application requires FastPad bias configuration to run at high frequency on SCLK.


	The sQSPI application requires FastPad bias configuration to run at high frequency on SCLK.
	Additionally, the sQSPI application requires FastPad bias configuration to run at high frequency on SCLK.

	The sQSPI Soft Peripheral requires RAM retention in order to go into the lowest power consumption mode (API call to :c:func:`nrfx_qspi2_deactivate`).
	The sQSPI Soft Peripheral requires RAM retention in order to go into the lowest power consumption mode, which can be called through the :c:func:`nrfx_qspi2_deactivate` API.

	Your build environment must reserve the required RAM and ensure that it is readable/writable by both the Application Core and the FLPR.
	Your build environment must reserve the required RAM and ensure that it is readable and writable by both the application core and the FLPR core.

		The build environment described in the :ref:`nrf54h20_porting_guide_code` section must comply with this requirements.
		This includes proper settings in linker scripts, device tree specifications (DTS), and resource allocation.

		@@ -0,0 +1,231 @@
		.. _nrf54H20_porting_guide:

		nRF54H20 porting guide


		Refer to the following detailed descriptions of current limitations:

		* sQSPI does not support slave mode operations; it can only operate as a controller (master).

	See the following list changes:
	See the following list of changes:

	However, there may be some limitations. For more information, see the :ref:`sqspi_limitations` page.
	However, there may be some limitations.
	For more information, see the :ref:`sqspi_limitations` page.

-You should be aware of the differences between sQSPI and QSPI features:
+The following section provides a detailed comparison of the features supported by the standard Quad Serial Peripheral Interface (QSPI) and the sQSPI.
+The comparison highlights the capabilities and limitations of each interface to aid in technical decision-making for your system design.
+For more details on sQSPI support, see the :ref:`sqspi_features` page.

		* Full Duplex: SPI reads by switching to receiving data (MISO) after transmitting data (MOSI).
		* Half Duplex: Three-wire setup (MOSI/MISO, SCLK, CSN).

	For an sQSPI application to run properly, you must adjust the settings for the nRF54H20 SoC to run at highest base clock frequency. The user/integrator should take care of this.
	For an sQSPI application to run properly, you must adjust the settings for the nRF54H20 SoC to run at highest base clock frequency.


		In as secure configuration, both the application core and the FLPR core of the nRF54H20 device must operate within a secure environment enabled by TrustZone Secure.

		Non-Secure settings


		.. _nrf54H20_porting_guide_ram_configuration:

		RAM Configuration

softperipheral: Add initial sQSPI #1694

softperipheral: Add initial sQSPI #1694

Uh oh!

Conversation

lopeztel commented Mar 31, 2025

Uh oh!

CLAassistant commented Mar 31, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

carlescufi Apr 1, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

barsok Apr 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

CLAassistant commented Mar 31, 2025 •

edited

Loading

carlescufi Apr 1, 2025 •

edited

Loading

barsok Apr 2, 2025 •

edited

Loading