Re: Article: 64-bit RISC-V with NuttX

[Lee, Lup Yuen]

Thanks Tomek! Yep I'm starting to port NuttX to the StarFive JH7110 SoC
(64-bit RISC-V) and Pine64 Star64 SBC. Should be really interesting :-)

https://doc-en.rvspace.org/Doc_Center/jh7110.html

https://wiki.pine64.org/wiki/STAR64

Lup

On Sat, Jun 24, 2023 at 8:05 AM Tomek CEDRO  wrote:

> VERY COOL!! :-)
>
> I have VisionFive2 SBC to play with.. would be nice to run NuttX on it :-)
>
> I made run Linux (available images) and FreeBSD (no drivers yet on BSD only
> kernel + apps over uart) on it already :-)
>
> --
> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
>

Re: Article: 64-bit RISC-V with NuttX

[Tomek CEDRO]

VERY COOL!! :-)

I have VisionFive2 SBC to play with.. would be nice to run NuttX on it :-)

I made run Linux (available images) and FreeBSD (no drivers yet on BSD only
kernel + apps over uart) on it already :-)

--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info

Article: 64-bit RISC-V with NuttX

[Lee, Lup Yuen]

In this article we explore NuttX on 64-bit RISC-V...

(1) Boot NuttX on the QEMU Emulator for 64-bit RISC-V
(2) Study the Boot Code that starts NuttX on RISC-V
(3) And learn a little RISC-V Assembly!

Check out the article here:

https://lupyuen.codeberg.page/articles/riscv.html

Lup

Re: MTD data corruption issue when written with DMA from different threads

[Oleg]

Hi Petro,

Thanks for the feedback!
CONFIG_ARMV7M_DCACHE = y //only this option related to DCACHE
CONFIG_STM32F7_DMACAPABLE = y
CONFIG_STM32F7_SPI_DMATHRESHOLD = 8

no CONFIG_ARMV7M_DCACHE_WRITETHROUGH
no CONFIG_SPI_TRIGGER
no CONFIG_STM32F7_SPI1_DMA_BUFFER

I've tried before with CONFIG_STM32F7_SPI1_DMA_BUFFER=1024 since I used
STM32F4
,
and also now with STM32F7, but DMAtransfers stops work at all (there is
empty data read and written for some reason), while I have such config
buffer for SPI3 and it's working correctly. I haven't found out the reason
for this and just skipped it. Could this be related to current problems and
I should debug this more deeply?

I've tried to use up_clean_dcach() in stm32f7/stm32_spi.c as you suggested.
It doesn't help, there is still data corruption, but subjectively it seems
that less often than before with the same actions I repeat trying to
reproduce the issue.

Just in case, there are no "extra" bytes, everything in place, but a couple
bytes are corrupted to zero, as I see, in the same places, but I haven't
noticed some pattern or specific offsets of corruption.
[image: изображение.png]

---
With best regards, Oleg.

пт, 23 июн. 2023 г. в 00:07, Petro Karashchenko <
petro.karashche...@gmail.com>:

> Hi,
>
> Could you please add some more information about the configuration like
> "CONFIG_STM32F7_DMACAPABLE", "CONFIG_SPI_TRIGGER",
> "CONFIG_STM32F7_SPIx_DMA_BUFFER" and "CONFIG_STM32F7_SPI_DMATHRESHOLD".
> Also the D-cache configuration like "CONFIG_ARMV7M_DCACHE_WRITETHROUGH".
>
> I do not see obvious issue except mirror improvement where
> "up_clean_dcache((uintptr_t)txbuffer, (uintptr_t)txbuffer + nbytes);" can
> be used instead of "up_flush_dcache((uintptr_t)txbuffer,
> (uintptr_t)txbuffer + nbytes);", but that obviously should not lead to
> random extra bytes.
>
> Best regards,
> Petro
>
> чт, 22 черв. 2023 р. о 16:14 Oleg  пише:
>
> >  Hi all,
> >
> > I'm working with custom stm32f7 board and PX4 old fork, where I have my
> > module that writes in several chunks some data (289 bytes) inside one of
> > the partition of MTD mx25lx at SPI1, while there is PX4 params module
> that
> > autosave parameters on changes in another partition of the same MTD.
> > And sometimes data in my part of MTD (at least) gets corrupted by a
> couple
> > of zeroed bytes, I can check it by rereading right after writing.
> >
> > It does not always happen and it's quite tricky to catch. There is no
> issue
> > if no parameters change in parallel or if I disable
> > CONFIG_STM32F7_SPI1_DMA.
> >
> > As for me looks like potential issue with dcache, especially taking into
> > account I'm quite "lucky" for such issues (: previously were "SD FAT32:
> > Write failed with err 28 (no space left on device)" that was fixed in
> > https://github.com/apache/nuttx/pull/5062 and "Potential UDP packets
> loss"
> > that was fixed in https://github.com/apache/nuttx/pull/6831.
> >
> > Unfortunately I don't have enough perception of dcache, how to debug such
> > time-related things, so I'm looking for any advice.
> >
> > ---
> > With best regards, Oleg.
> >
>