Issue with fat_fs example on nucleo_f767zi #35561

ddkn · 2021-05-22T19:31:39Z

Hello,

I believe this is something that may be obvious, but I cannot see the issue. I am trying to use the samples/subsys/fs/fat_fs project to read an SD card using the nucleo_f767zi board with a Adafruit microSD SPI+SDIO board. I am hoping to just use the SPI interface, which should be supported by the nucleo. However, like others before me, #21899 and #27841, I am having no luck. I am attaching the relevant *.{conf,overlay} files that I am using with the sample project, below.

Unfortunately, I do not have access to a logic analyzer to give some of the outputs for troubleshooting. Any advice or direction would be greatly appreciated!

Steps to reproduce the behavior:

west build -p auto -b boards/arm/nucleo_f767zi samples/subsys/fs/fat_fs
west flash
See error below

*** Booting Zephyr OS build zephyr-v2.5.0-965-g33c9be90ccea  ***
Error mounting disk.
[00:00:00.007,000] ␛[1;31m<err> main: Storage init ERROR!␛[0m
[00:00:00.010,000] ␛[1;31m<err> fs: fs mount error (-5)␛[0m

Expected behavior
I expect the contents of a MS-DOS FAT32 formatted microSD (SanDisk SDHC Ultra 32GB) to be displayed, which is just a hello.txt file.

Impact
As I am trying to store ADC values on the SD card.

Configuration and additional files
I have hooked up the following pins,

Adafruit microSD	NucleoF767ZI	F767ZI Pin
CLK	SPI_SCK	PA5
SO	SPI1_MISO	PA6
SI	SPI1_MOSI	PA7
CS	SPI1_CS	PA4

boards/nucleo_f767zi.overlay

&spi1 {
        status = "okay";
        /* I changed 0, to GPIO_ACTIVE_{HIGH,LOW} and tried that OR'd with GPIO_PULL_UP */
        cs-gpios = <&gpioa 4 0>;

        sdhc0: sdhc@0 {
                compatible = "zephyr,mmc-spi-slot";
                reg = <0>;
                status = "okay";
                label = "SDHC0";
                spi-max-frequency = <24000000>;
        };
};

boards/nucleo_f767zi.conf

CONFIG_DISK_ACCESS_SDHC=y
CONFIG_DISK_ACCESS_SPI_SDHC=y
CONFIG_SPI=y
CONFIG_SPI_STM32=y
CONFIG_SPI_1=y

Environment (please complete the following information):

OS: MacOS High Sierra
Toolchain macPorts High Sierra arm-none-eabi
Commit 33c9be9

Additional context
Add any other context about the problem here.

The text was updated successfully, but these errors were encountered:

jfischer-no · 2021-05-24T11:38:10Z

It could be SPI issue reported in #35539.

ddkn · 2021-05-24T16:29:28Z

Well there seems to be an issue related to the SPI interface as you suggested. As I am on Zephyr v2.5.0-965, running

$ west build -p auto -b boards/arm/nucleo_f767zi tests/drivers/spi/spi_loopback
$ west flash

Returns the following on the terminal,

␀*** Booting Zephyr OS build zephyr-v2.5.0-965-g33c9be90ccea  ***
Running test suite test_spi
===================================================================
START - test_spi_loopback
I: SPI test on buffers TX/RX 0x20020131/0x2002094a
E: Cannot find !


    Assertion failed at WEST_TOPDIR/zephyr/tests/drivers/spi/spi_loopback/src/spi.c:597: test_spi_loopback: (spi_slow is NULL)
Invalid SPI device
 FAIL - test_spi_loopback
===================================================================
Test suite test_spi failed.
===================================================================
PROJECT EXECUTION FAILED

For now I copied over the nucleo_f746zg.conf -> nucleo_f767zi.conf

*** Booting Zephyr OS build zephyr-v2.5.0-965-g33c9be90ccea  ***
Running test suite test_spi
===================================================================
START - test_spi_loopback
I: SPI test on buffers TX/RX 0x20020131/0x2002094a
I: SPI test slow config
I: Start complete multiple
I: CS control inhibited (no GPIO device)
E: Buffer contents are different: 0x30,0x31,0x32,0x33,0x34,0x35,0x36,0x37,0x38,0x39,0x61,0x62,0x63,0x64,0x65,0x66,0x00,
E:                            vs: 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,

    Assertion failed at WEST_TOPDIR/zephyr/tests/drivers/spi/spi_loopback/src/spi.c:151: spi_complete_multiple: (1 is true)
Buffer contents are different
 FAIL - test_spi_loopback
===================================================================
Test suite test_spi failed.
===================================================================
PROJECT EXECUTION FAILED

    Assertion failed at WEST_TOPDIR/zephyr/tests/drivers/spi/spi_loopback/src/spi.c:489: spi_async_call_cb: (ret is true)
one or more events are not ready

This seems like a possible duplicate issue, I will post in the issue you mentioned to add to it.

FRASTM · 2021-05-26T11:04:47Z

Do you want to run the spi_loopback test on the nucleo_f767zi ? There some adaptations to include:

add the nucleo_f767zi.conf:

CONFIG_SPI_LOOPBACK_DRV_NAME="SPI_1"
CONFIG_SPI_STM32_DMA=y
CONFIG_SPI_STM32_INTERRUPT=n
CONFIG_SPI_ASYNC=n
CONFIG_SPI_LOOPBACK_MODE_LOOP=n
CONFIG_NOCACHE_MEMORY=y

add the nucleo_f767zi.overlay


&spi1 {
	dmas = <&dma2 5 3 0x28440 0x03
		&dma2 2 3 0x28480 0x03>;
	dma-names = "tx", "rx";
};

&dma2 {
	status = "okay";
};

remove the use of the CACHE MEMORY in the soc/arm/st_stm32/stm32f7/soc.c
(since the CONFIG_NOCACHE_MEMORY is defined)
connect the MISO pin to MOSI pin (D12/D11 on the CN7)

ddkn · 2021-05-26T12:50:15Z

Hi @FRASTM,

I am an idiot, you deserve a coffee haha.

connect the MISO pin to MOSI pin (D12/D11 on the CN7)

I thought the SPI was doing something internal, but connecting the pins had everything succeed with my original nucleo_f767zi.conf. I had added the pin before I flashed and reset and it worked! (See after, for other notes on what you specifically asked me to do)

*** Booting Zephyr OS build v2.6.0-rc1-51-g13303c4351d9  ***
Running test suite test_spi
===================================================================
START - test_spi_loopback
I: SPI test on buffers TX/RX 0x20020131/0x20020a1a
I: SPI test slow config
I: Start complete multiple
I: CS control inhibited (no GPIO device)
I: Passed
I: Start complete loop
I: Passed
I: Start null tx
I: Passed
I: Start half start
I: Passed
I: Start half end
I: Passed
I: Start every 4
I: Passed
I: Start async call
I: Passed
I: SPI test fast config
I: Start complete multiple
I: CS control inhibited (no GPIO device)
I: Passed
I: Start complete loop
I: Passed
I: Start null tx
I: Passed
I: Start half start
I: Passed
I: Start half end
I: Passed
I: Start every 4
I: Passed
I: Start async call
I: Passed
I: Start complete loop
I: CS control inhibited (no GPIO device)
I: Passed
I: Start complete loop
I: CS control inhibited (no GPIO device)
I: Passed
I: All tx/rx passed
 PASS - test_spi_loopback in 0.75 seconds
===================================================================
Test suite test_spi succeeded
===================================================================
PROJECT EXECUTION SUCCESSFUL

But to add to what you asked me to do. I still did what you asked: 1,2,3,4,

For step (3) I assume you meant to comment out,

/* soc/arm/st_stm32/stm32f7/soc.c */
//SCB_EnableICache();
//if (!(SCB->CCR & SCB_CCR_DC_Msk)) {
//    SCB_EnableDCache();
//}

I did try with and without this just in case.

Doing those steps I get the following error message,

*** Booting Zephyr OS build v2.6.0-rc1-51-g13303c4351d9  ***
Running test suite test_spi
===================================================================
START - test_spi_loopback
I: SPI test on buffers TX/RX 0x20020195/0x20020a72
I: SPI test slow config
I: Start complete multiple
I: CS control inhibited (no GPIO device)
E: dma stream 2 is busy.
E: Code -16

    Assertion failed at WEST_TOPDIR/zephyr/tests/drivers/spi/spi_loopback/src/spi.c:140: spi_complete_multiple: (ret is true)
SPI transceive failed
 FAIL - test_spi_loopback in 0.30 seconds
===================================================================
Test suite test_spi failed.
===================================================================
PROJECT EXECUTION FAILED

FRASTM · 2021-05-26T13:15:44Z

Did you use the stream for another DMA request (terminology is a bit confusing) ?
The stm32f767 can propose several streams for SPI1 on the DMA request=3:
stream 3 or stream 5 for SPI1_TX, stream 0 or stream 2 for SPI1_RX, with possible dts as follows:
&spi1 {
dmas = <&dma2 _stream=5 or 3 on peripheral request=3 0x28440 0x03
&dma2 stream=0 or 2 on peripheral request=3 0x28480 0x03>;
dma-names = "tx", "rx";
}

ddkn · 2021-05-26T14:21:52Z

Hi @FRASTM ,

Did you use the stream for another DMA request ?

Not to my knowledge? I am just using tests/drivers/spi/spi_loopback for now. So I just set what you asked me to set.

Just making sure we are on the same page, looking at the datasheet for the STM32F767 these are the valid options,

I tried all combinations. For Tx: Stream 5, Channel 3; Stream 3, Channel 3. For Rx: Stream 0, Channel 3; Stream 2, Channel 3. What I found worked was my original DCache issue. By adding SCB_DisableDCache(); the following to

/* tests/drivers/spi/spi_loopback/src/spi.c */
void test_main(void)
{
    SCB_DisableDCache();
    ztest_test_suite(test_spi, ztest_unit_test(test_spi_loopback));
    ztest_run_test_suite(test_spi);
}

Which gives,

*** Booting Zephyr OS build v2.6.0-rc1-337-gf204de03cf91  ***
Running test suite test_spi
===================================================================
START - test_spi_loopback
I: SPI test on buffers TX/RX 0x20020195/0x20020a72
I: SPI test slow config
I: Start complete multiple
I: CS control inhibited (no GPIO device)
I: Passed
I: Start complete loop
I: Passed
I: Start null tx
I: Passed
I: Start half start
I: Passed
I: Skip half end
I: Skip every 4
I: SPI test fast config
I: Start complete multiple
I: CS control inhibited (no GPIO device)
I: Passed
I: Start complete loop
I: Passed
I: Start null tx
I: Passed
I: Start half start
I: Passed
I: Skip half end
I: Skip every 4
I: Start complete loop
I: CS control inhibited (no GPIO device)
I: Passed
I: Start complete loop
I: CS control inhibited (no GPIO device)
I: Passed
I: All tx/rx passed
 PASS - test_spi_loopback in 0.65 seconds
===================================================================
Test suite test_spi succeeded
===================================================================
PROJECT EXECUTION SUCCESSFUL

So aside from the DCache issue, the DMA+SPI works as excepted. However, I now need to go back to my original fat_fs issue.

ddkn · 2021-05-26T14:36:07Z

Not sure if you can help me here @FRASTM, so now that I know the SPI interface works as expected, I went back to the samples/subsys/fs/fat_fs project to ensure I can read the microSD card. Unfortunately, I wasn't able to have any luck. I tried trimming the board specific files I had to this,

nucleo_f767zi.conf

CONFIG_DISK_DRIVER_SDMMC=y
CONFIG_SPI=y
CONFIG_SPI_STM32=y
CONFIG_SPI_STM32_INTERRUPT=y

nucleo_f767zi.overlay

&spi1 {
        pinctrl-0 = <&spi1_nss_pa4 &spi1_sck_pa5
                     &spi1_miso_pa6 &spi1_mosi_pa7>;
        status = "okay";
        cs-gpios = <&gpioa 4 GPIO_ACTIVE_HIGH>;

        sdhc0: sdhc@0 {
                compatible = "zephyr,mmc-spi-slot";
                reg = <0>;
                status = "okay";
                label = "SDHC0";
                spi-max-frequency = <24000000>;
        };
};

Which mimic what the olimexino_stm32.dts (from the boards/arm/olimnexino_stm32), and olimexino_stm32.conf (from the fat_fs/boards). As well as the fat_fs/boards/nrf52840_blip.{conf,overlay}

I am getting the following error now from running fat_fs,

*** Booting Zephyr OS build v2.6.0-rc1-338-g7bcd88a89a03  ***
Error mounting disk.
[00:00:00.007,000] <err> main: Storage init ERROR!
[00:00:00.010,000] <err> fs: fs mount error (-5)

Where I am back to square one.

I am including on how I set up the pins on the board I routed. I do have a chip detect (CD) pin, but not using it at the moment.

I am at a bit of a loss here on how to debug this.

erwango · 2021-05-26T14:43:54Z

@ddkn Can you enable some log ?
For instance CONFIG_SDMMC_LOG_LEVEL_DBG=y.

Also, please note that spi1_nss_pa4 might not play well with cs-gpios, so I'd propose to remove it.

ddkn · 2021-05-26T14:51:12Z

Hi @erwango,

Sorry, I am not used to all of the options available. Here is the debug output,

*** Booting Zephyr OS build v2.6.0-rc1-338-g7bcd88a89a03  ***
Error mounting disk.
[00:00:00.005,000] <dbg> sdmmc_spi.sdhc_spi_tx_cmd: cmd0 payload=0
[00:00:00.006,000] <dbg> sdmmc_spi.sdhc_spi_tx_cmd: cmd8 payload=426
[00:00:00.006,000] <dbg> sdmmc_spi.sdhc_spi_tx_cmd: cmd59 payload=1
[00:00:00.006,000] <dbg> sdmmc_spi.sdhc_spi_tx_cmd: cmd55 payload=0
[00:00:00.006,000] <dbg> sdmmc_spi.sdhc_spi_tx_cmd: cmd41 payload=0
[00:00:00.007,000] <dbg> sdmmc_spi.sdhc_spi_tx_cmd: cmd16 payload=512
[00:00:00.007,000] <dbg> sdmmc_spi.sdhc_spi_tx_cmd: cmd9 payload=0
[00:00:00.007,000] <err> main: Storage init ERROR!
[00:00:00.008,000] <dbg> sdmmc_spi.sdhc_spi_tx_cmd: cmd0 payload=0
[00:00:00.008,000] <dbg> sdmmc_spi.sdhc_spi_tx_cmd: cmd8 payload=426
[00:00:00.008,000] <dbg> sdmmc_spi.sdhc_spi_tx_cmd: cmd59 payload=1
[00:00:00.009,000] <dbg> sdmmc_spi.sdhc_spi_tx_cmd: cmd55 payload=0
[00:00:00.009,000] <dbg> sdmmc_spi.sdhc_spi_tx_cmd: cmd41 payload=0
[00:00:00.009,000] <dbg> sdmmc_spi.sdhc_spi_tx_cmd: cmd16 payload=512
[00:00:00.009,000] <dbg> sdmmc_spi.sdhc_spi_tx_cmd: cmd9 payload=0
[00:00:00.010,000] <err> fs: fs mount error (-5)

I wasn't sure what you meant by remove it. So just in case I ran it 2 times, one with the spi1_nss_pa4 removed, and the other with the cs-gpios line removed; this gave the same debug output.

Thanks again for helping.

Edit: I also ran it with both options enabled as well.

erwango · 2021-05-26T15:00:24Z

Ok, not much info here.

What about CONFIG_SPI_LOG_LEVEL_BDG=y ?
Also, just to be sure, are you using #35661 ?

ddkn · 2021-05-26T15:20:30Z

Also, just to be sure, are you using #35661 ?

I have my own branch from 457a28b where I just ran git revert 012884, to get the above stuff working in spi_lookback.

The output of the SPI log is as such,

CTRL-A Z for help | 115200 8N1 | NOR | Minicom 2.7.1 | VT102 | Offline | mFD133
*** Booting Zephyr OS build v2.6.0-rc1-338-g7bcd88a89a03  ***
Error mounting disk.
[00:00:00.011,000] <dbg> spi_ll_stm32.spi_context_update_tx: tx buf/len (nil)/0
--- 248 messages dropped ---
[00:00:00.012,000] <dbg> spi_ll_stm32.spi_context_update_rx: rx buf/len (nil)/0
[00:00:00.012,000] <dbg> spi_ll_stm32.spi_context_buffers_setup: tx_bufs 0x200211d0 - rx_bufs 0x200211e0 - 1
[00:00:00.012,000] <dbg> spi_ll_stm32.spi_context_buffers_setup: current_tx 0x200211c8 (1), current_rx 0x200211d8 (1), tx buf/len 0x800974b/1, rx buf/len 01
[00:00:00.012,000] <dbg> spi_ll_stm32.spi_context_update_tx: tx buf/len (nil)/0
[00:00:00.012,000] <dbg> spi_ll_stm32.spi_context_update_rx: rx buf/len (nil)/0
[00:00:00.012,000] <dbg> spi_ll_stm32.spi_context_buffers_setup: tx_bufs 0x200211e0 - rx_bufs (nil) - 1
[00:00:00.012,000] <dbg> spi_ll_stm32.spi_context_buffers_setup: current_tx 0x200211d8 (1), current_rx (nil) (0), tx buf/len 0x200211f0/6, rx buf/len (nil)0
[00:00:00.012,000] <dbg> spi_ll_stm32.spi_context_update_tx: tx buf/len 0x200211f1/5
[00:00:00.012,000] <dbg> spi_ll_stm32.spi_context_update_tx: tx buf/len 0x200211f2/4
[00:00:00.012,000] <dbg> spi_ll_stm32.spi_context_update_tx: tx buf/len 0x200211f3/3
[00:00:00.012,000] <dbg> spi_ll_stm32.spi_context_update_tx: tx buf/len 0x200211f4/2
[00:00:00.012,000] <dbg> spi_ll_stm32.spi_context_update_tx: tx buf/len 0x200211f5/1
[00:00:00.012,000] <dbg> spi_ll_stm32.spi_context_update_tx: tx buf/len (nil)/0
[00:00:00.012,000] <dbg> spi_ll_stm32.spi_context_buffers_setup: tx_bufs 0x200211c0 - rx_bufs 0x200211d0 - 1
[00:00:00.012,000] <dbg> spi_ll_stm32.spi_context_buffers_setup: current_tx 0x200211b8 (1), current_rx 0x200211c8 (1), tx buf/len 0x800974b/1, rx buf/len 01
[00:00:00.012,000] <dbg> spi_ll_stm32.spi_context_update_tx: tx buf/len (nil)/0
[00:00:00.012,000] <dbg> spi_ll_stm32.spi_context_update_rx: rx buf/len (nil)/0
[00:00:00.012,000] <dbg> spi_ll_stm32.spi_context_buffers_setup: tx_bufs 0x200211a8 - rx_bufs 0x200211b8 - 1
[00:00:00.012,000] <dbg> spi_ll_stm32.spi_context_buffers_setup: current_tx 0x200211a0 (1), current_rx 0x200211b0 (1), tx buf/len 0x800974b/1, rx buf/len 01
[00:00:00.012,000] <dbg> spi_ll_stm32.spi_context_update_tx: tx buf/len (nil)/0
[00:00:00.012,000] <dbg> spi_ll_stm32.spi_context_update_rx: rx buf/len (nil)/0
[00:00:00.012,000] <err> fs: fs mount error (-5)

erwango · 2021-05-26T15:44:53Z

Moving issue to "low" as different from #35661

ddkn · 2021-05-27T20:06:46Z

Hi @erwango and @FRASTM,

I wanted to update, I got the board working. I ended up changing out the microSD SPI+SDIO breakout board with a spare one I had. I may have a bad soldering job on my end or a faulty part, however, it works now.

Here are the current config files I have to ensure this works,

boards/nucleo_f767zi.overlay

&spi1 {
        /* including &spi1_nss_pa4 in pinctrl-0 has no discernible effect at the moment */
        pinctrl-0 = <&spi1_sck_pa5
                     &spi1_miso_pa6 &spi1_mosi_pa7>;
        status = "okay";
        cs-gpios = <&gpioa 4 GPIO_ACTIVE_LOW>;

        sdhc0: sdhc@0 {
                compatible = "zephyr,mmc-spi-slot";
                reg = <0>;
                status = "okay";
                label = "SDHC0";
                spi-max-frequency = <24000000>;
        };
};

boards/nucleo_f767zi.conf

CONFIG_DISK_DRIVER_SDMMC=y
CONFIG_SPI=y
CONFIG_SPI_STM32=y

serial output

*** Booting Zephyr OS build v2.6.0-rc1-338-g7bcd88a89a03  ***
Sector size 512
Memory Size(MB) 30436
Disk mounted.

Listing dir /SD: ...
[DIR ] SPOTLI~1
[FILE] HELLO.TXT (size = 13)
[FILE] _HELL~1.TXT (size = 4096)

Did you want me to do a pull request and add those in for the samples/subsys/fs/fat_fs app?

erwango · 2021-05-28T06:42:33Z

I wanted to update, I got the board working. I ended up changing out the microSD SPI+SDIO breakout board with a spare one I had. I may have a bad soldering job on my end or a faulty part, however, it works now.

@ddkn Thanks for the update. I'm gonna close the issue then.

Did you want me to do a pull request and add those in for the samples/subsys/fs/fat_fs app?

Nice offer, but we generally limit upstream to the hw that's actually on boards. Otherwise we would be overwhelmed with overlays.

erwango · 2021-05-28T06:46:46Z

@ddkn Thinking a bit more to it, what can be done is to port Adafruit microSD SPI+SDIO as a shield. So it can then benefit to all. Cf boards/shields/adafruit_winc1500 as example

ddkn · 2021-05-28T11:38:10Z

Nice offer, but we generally limit upstream to the hw that's actually on boards. Otherwise we would be overwhelmed with overlays.

That is fair, haha. I will just post this on a blog or something in case someone needs it. I do appreciate all of the help!

Thinking a bit more to it, what can be done is to port Adafruit microSD SPI+SDIO as a shield. So it can then benefit to all. Cf boards/shields/adafruit_winc1500 as example.

I could try and look into this. For the SPI it was as direct as hooking up the pins. I would need to test out the SDIO stuff as well (but my school project has a small priority at the moment, hence the need for help). I could then just make port/shield like the adafruit_winc1500 as you suggest, if it is applicable. I can at least test it out on a Nucleo_{F103,F767,L152}. I have added it to my todo list.

By then I will make a new issue or pull request once I have things sorted out.

FYI, just got the read/write working! So I am quite happy now and can make some progress.

ddkn added the bug The issue is a bug, or the PR is fixing a bug label May 22, 2021

FRASTM added the platform: STM32 ST Micro STM32 label May 24, 2021

ddkn mentioned this issue May 24, 2021

tests: drivers: spi: spi_loopback: test failed since #34731 is merged #35539

Closed

erwango self-assigned this May 25, 2021

galak added the priority: medium Medium impact/importance bug label May 25, 2021

erwango added priority: low Low impact/importance bug and removed priority: medium Medium impact/importance bug labels May 26, 2021

erwango closed this as completed May 28, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Issue with fat_fs example on nucleo_f767zi #35561

Issue with fat_fs example on nucleo_f767zi #35561

ddkn commented May 22, 2021

jfischer-no commented May 24, 2021

ddkn commented May 24, 2021

FRASTM commented May 26, 2021

ddkn commented May 26, 2021

FRASTM commented May 26, 2021 •

edited

Loading

ddkn commented May 26, 2021

ddkn commented May 26, 2021 •

edited

Loading

erwango commented May 26, 2021 •

edited

Loading

ddkn commented May 26, 2021 •

edited

Loading

erwango commented May 26, 2021

ddkn commented May 26, 2021

erwango commented May 26, 2021

ddkn commented May 27, 2021 •

edited

Loading

erwango commented May 28, 2021

erwango commented May 28, 2021

ddkn commented May 28, 2021

Issue with fat_fs example on nucleo_f767zi #35561

Issue with fat_fs example on nucleo_f767zi #35561

Comments

ddkn commented May 22, 2021

jfischer-no commented May 24, 2021

ddkn commented May 24, 2021

FRASTM commented May 26, 2021

ddkn commented May 26, 2021

FRASTM commented May 26, 2021 • edited Loading

ddkn commented May 26, 2021

ddkn commented May 26, 2021 • edited Loading

erwango commented May 26, 2021 • edited Loading

ddkn commented May 26, 2021 • edited Loading

erwango commented May 26, 2021

ddkn commented May 26, 2021

erwango commented May 26, 2021

ddkn commented May 27, 2021 • edited Loading

erwango commented May 28, 2021

erwango commented May 28, 2021

ddkn commented May 28, 2021

FRASTM commented May 26, 2021 •

edited

Loading

ddkn commented May 26, 2021 •

edited

Loading

erwango commented May 26, 2021 •

edited

Loading

ddkn commented May 26, 2021 •

edited

Loading

ddkn commented May 27, 2021 •

edited

Loading