> Date: Fri, 28 Jul 2023 14:32:30 +0200
> From: develo...@robert-palm.de
>
> Zitat von Miguel Landaeta <mig...@miguel.cc>:
>
> >> Synopsis: Samsung NVMe M.2 SSD 970 EVO Plus fails to attach on
> >> VisionFive 2 (JH7110 SoC) board
> >> Category: riscv64
> >> Environment:
> > System : OpenBSD 7.3
> > Details : OpenBSD 7.3-current (GENERIC.MP) #377: Fri Jul 14
> > 04:39:21 MDT 2023
> >
> > dera...@riscv64.openbsd.org:/usr/src/sys/arch/riscv64/compile/GENERIC.MP
> >
> > Architecture: OpenBSD.riscv64
> > Machine : riscv64
> >> Description:
> > Samsung NVMe M.2 SSD 970 EVO Plus fails to attach on VisionFive 2
> > (JH7110 SoC) board
> >
> >
> > I just got a Samsung NVMe M.2 SSD 970 EVO Plus to test the recently added
> > support for PCIE devices to JH7110 SoC but it has not been working correctly
> > with this disk.
> >
> > The behavior I'm observing is a little erratic, the NVMe disk only attached
> > correctly like in 1 of 10 or more boot attempts.
> >
> > Only a couple of times worked OK, but most of the times one of the following
> > is observed:
> >
> > - No nvme0 device detected during autoconf phase, nothing related to the
> > device shows up in dmesg and no sd0 device is attached. When this
> > happens the board boots OK and SD/MMC devices are detected and attached.
> >
> > - nvme0 device is detected during autoconf, sd0 device attaches but boot
> > hangs. Looks like kernel never reaches diskconf() or if it reached it
> > something is preventing the kernel from print the typical message:
> >
> > root on sd0a (062aeb9d33543517.a) swap on sd0b dump on sd0b
> >
> > - nvme0 device appears in dmesg but the device fails to attach with the
> > following message:
> >
> > nvme0 at pci3 dev 0 function 0 "Samsung SM981/PM981 NVMe" rev 0x00:
> > unable to map registers
> >
> > - To workaround this I'm just booting the kernel with -c option to disable
> > nvme driver in UKC and proceed with the boot.
> >
> >
> > I tried to debug more by building a kernel with DEBUG option set to
> > gather more
> > info but unfortunately if I boot such a kernel my board gets stuck very
> > early
> > in the boot process just after printing how much real memory is available.
> >
> > I'm more than happy to provide more info if required or to try patches if
> > that helps to troubleshoot the issue.
> >
> > Thanks.
> > Miguel.
> >
>
>
> Someone assumes it has to do with a delay:
>
> At a guess the very large and very fast (very higher power) NVMe
> devices draw so much current that they are glitching the power and
> clocks of the VF2, and it needs an extra delay beyond what the
> specification suggests from them to both stabilise to before the NVMe
> can be accessed.
>
> http://forum.rvspace.org/t/unlocking-new-possibilities-starfive-visionfive-2-sbc-now-supports-tianocore-edk-ii-uefi/2779/44?u=rpx
>
>
> Is this the place to look for in OpenBSD ?
>
> https://github.com/openbsd/src/blob/master/sys/dev/ic/nvme.c
>
> Maybe anybody knows how to change this delay ?
Might be worth trying a kernel with this diff then:
Index: arch/riscv64/dev/stfpcie.c
===================================================================
RCS file: /cvs/src/sys/arch/riscv64/dev/stfpcie.c,v
retrieving revision 1.1
diff -u -p -r1.1 stfpcie.c
--- arch/riscv64/dev/stfpcie.c 8 Jul 2023 10:06:13 -0000 1.1
+++ arch/riscv64/dev/stfpcie.c 28 Jul 2023 13:19:28 -0000
@@ -430,7 +430,7 @@ stfpcie_attach(struct device *parent, st
* active at least 100ms after power up. Since we may have
* just powered on the device, play it safe and use 100ms.
*/
- delay(100000);
+ delay(300000);
/* Deassert PERST#. */
gpio_controller_set_pin(reset_gpio, 0);
