Zitat von Mark Kettenis <[email protected]>:
Date: Fri, 28 Jul 2023 14:32:30 +0200
From: [email protected]
Zitat von Miguel Landaeta <[email protected]>:
>> 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
>
[email protected]:/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);
Many thanks! Please, will you commit it so I can test it with the next
snapshot version ?
