frauhottelmann Posted February 5, 2021 Posted February 5, 2021 Am 25.2.2020 um 19:30 schrieb Panzerknacker: Probably not. The 0.9V regulator will come with 5.6 :-) but missing it causes no failure. Link training can time out when no NVME device is connected or a connected one is not powered. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/arch/arm64/boot/dts/rockchip/rk3399-roc-pc.dtsi?h=v5.6-rc3 I am getting the same error: [ 1.253914] vcc3v3_pcie: supplied by sys_12v [ 2.630978] rockchip-pcie f8000000.pcie: host bridge /pcie@f8000000 ranges: [ 2.631008] OF: /pcie@f8000000: Missing device_type [ 2.631041] rockchip-pcie f8000000.pcie: MEM 0x00fa000000..0x00fbdfffff -> 0x00fa000000 [ 2.631062] rockchip-pcie f8000000.pcie: IO 0x00fbe00000..0x00fbefffff -> 0x00fbe00000 [ 2.631950] rockchip-pcie f8000000.pcie: no vpcie12v regulator found [ 2.723678] ehci-pci: EHCI PCI platform driver [ 2.763643] ohci-pci: OHCI PCI platform driver [ 3.092350] rockchip-pcie f8000000.pcie: host bridge /pcie@f8000000 ranges: [ 3.092401] rockchip-pcie f8000000.pcie: MEM 0x00fa000000..0x00fbdfffff -> 0x00fa000000 [ 3.092423] rockchip-pcie f8000000.pcie: IO 0x00fbe00000..0x00fbefffff -> 0x00fbe00000 [ 3.093327] rockchip-pcie f8000000.pcie: no vpcie12v regulator found [ 3.645989] rockchip-pcie f8000000.pcie: PCIe link training gen1 timeout! [ 3.646968] rockchip-pcie: probe of f8000000.pcie failed with error -110 [ 33.762142] vcc3v3_pcie: disabling Any ideas? I have the mezzanine without PoE and I have enabled PCIe in armbian-config. The build is from today The m.2 is a Corsair Force MP510 NVMe drive. Power supply is a 60W PD unit, 0 Quote
Panzerknacker Posted February 5, 2021 Posted February 5, 2021 59 minutes ago, frauhottelmann said: [ 3.645989] rockchip-pcie f8000000.pcie: PCIe link training gen1 timeout! Can you try another drive? Samsung MZ-V7S1T0BW 970 EVO Plus 1 TB NVMe M.2 works for me. 0 Quote
frauhottelmann Posted February 5, 2021 Posted February 5, 2021 No, unfortunately it's the only one I have. But I did just try a known good wireless card - same result 😒 0 Quote
denni_isl Posted February 6, 2021 Posted February 6, 2021 On 2/3/2021 at 7:35 PM, Panzerknacker said: On roc-rk3399-pc you can short pin 6 of the 8pin SPI-Flash-Chip to GND during power on. Then rk3399 boots from SD/eMMC. Yes, short the clock to ground, similar to shorting pins 23 and 25 on rockpro64 board. There are also dedicated 4 spi pins on roc-rk3399-pc-plus, they are marked 3V3, WP, CLK, GND. So one might as well sort CLK and GND as pin 6 and 4 on the chip it self. 0 Quote
frauhottelmann Posted February 6, 2021 Posted February 6, 2021 What is everyone with a NVMe using to power it? Anyone using it with a PD power supply? 0 Quote
Fred St-Pierre Posted February 6, 2021 Posted February 6, 2021 41 minutes ago, frauhottelmann said: What is everyone with a NVMe using to power it? Anyone using it with a PD power supply? Power it with POE for now, before I was using a 60W PD power brick during staging 0 Quote
Panzerknacker Posted February 6, 2021 Posted February 6, 2021 1 hour ago, frauhottelmann said: What is everyone with a NVMe using to power it? Anyone using it with a PD power supply? Dumb USB 5V/3A Wallplug, USB-A->USB-C cable, USB-C power-in. 0 Quote
frauhottelmann Posted February 8, 2021 Posted February 8, 2021 I have also tried it with my big 5V power supply. Same problem. U-Boot looks good: Spoiler U-Boot TPL 2020.10-armbian (Feb 05 2021 - 15:50:41) Trying to boot from BOOTROM Returning to boot ROM... U-Boot SPL 2020.10-armbian (Feb 05 2021 - 15:50:41 +0000) Loading Environment from SPIFlash... *** Warning - bad CRC, using default environment Trying to boot from MMC1 NOTICE: BL31: v2.2(release):a04808c-dirty NOTICE: BL31: Built : 15:50:35, Feb 5 2021 U-Boot 2020.10-armbian (Feb 05 2021 - 15:50:41 +0000) SoC: Rockchip rk3399 Reset cause: POR Model: Firefly ROC-RK3399-PC Mezzanine Board DRAM: 3.9 GiB PMIC: RK808 MMC: mmc@fe310000: 2, mmc@fe320000: 1, sdhci@fe330000: 0 Loading Environment from SPIFlash... SF: Detected w25q128 with page size 256 Bytes, erase size 4 KiB, total 16 MiB *** Warning - bad CRC, using default environment In: serial Out: serial Err: serial Model: Firefly ROC-RK3399-PC Mezzanine Board Net: eth0: ethernet@fe300000 Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc1 is current device Scanning mmc 1:1... Found U-Boot script /boot/boot.scr 3185 bytes read in 5 ms (622.1 KiB/s) ## Executing script at 00500000 Boot script loaded from mmc 1 230 bytes read in 5 ms (44.9 KiB/s) 15339012 bytes read in 652 ms (22.4 MiB/s) 28582400 bytes read in 1213 ms (22.5 MiB/s) 77058 bytes read in 12 ms (6.1 MiB/s) 267 bytes read in 8 ms (32.2 KiB/s) Applying kernel provided DT overlay rockchip-pcie-gen2.dtbo 2698 bytes read in 8 ms (329.1 KiB/s) Applying kernel provided DT fixup script (rockchip-fixup.scr) ## Executing script at 09000000 Moving Image from 0x2080000 to 0x2200000, end=3de0000 ## Loading init Ramdisk from Legacy Image at 06000000 ... Image Name: uInitrd Image Type: AArch64 Linux RAMDisk Image (gzip compressed) Data Size: 15338948 Bytes = 14.6 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 01f00000 Booting using the fdt blob at 0x1f00000 Loading Ramdisk to f1078000, end f1f18dc4 ... OK Loading Device Tree to 00000000f0ffc000, end 00000000f1077fff ... OK Starting kernel ... Armbianmonitor: http://ix.io/2OIx 0 Quote
Panzerknacker Posted February 8, 2021 Posted February 8, 2021 [ 0.733926] vcc3v3_pcie: supplied by sys_12v [ 0.927228] rockchip-pcie f8000000.pcie: host bridge /pcie@f8000000 ranges: [ 0.927911] rockchip-pcie f8000000.pcie: MEM 0x00fa000000..0x00fbdfffff -> 0x00fa000000 [ 0.928695] rockchip-pcie f8000000.pcie: IO 0x00fbe00000..0x00fbefffff -> 0x00fbe00000 [ 0.930542] rockchip-pcie f8000000.pcie: no vpcie12v regulator found [ 1.006248] rockchip-pcie f8000000.pcie: PCI host bridge to bus 0000:00 [ 1.006851] pci_bus 0000:00: root bus resource [bus 00-1f] [ 1.007343] pci_bus 0000:00: root bus resource [mem 0xfa000000-0xfbdfffff] [ 1.007956] pci_bus 0000:00: root bus resource [io 0x0000-0xfffff] (bus address [0xfbe00000-0xfbefffff]) [ 1.008833] pci 0000:00:00.0: [1d87:0100] type 01 class 0x060400 [ 1.009486] pci 0000:00:00.0: supports D1 [ 1.009849] pci 0000:00:00.0: PME# supported from D0 D1 D3hot [ 1.013657] pci 0000:00:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring [ 1.014561] pci 0000:01:00.0: [144d:a808] type 00 class 0x010802 [ 1.015175] pci 0000:01:00.0: reg 0x10: [mem 0x00000000-0x00003fff 64bit] [ 1.015931] pci 0000:01:00.0: Max Payload Size set to 256 (was 128, max 256) [ 1.017053] pci 0000:01:00.0: 8.000 Gb/s available PCIe bandwidth, limited by 2.5 GT/s PCIe x4 link at 0000:00:00.0 (capable of 31.504 Gb/s with 8.0 GT/s PCIe x4 link) [ 1.033595] pci_bus 0000:01: busn_res: [bus 01-1f] end is updated to 01 [ 1.034235] pci 0000:00:00.0: BAR 8: assigned [mem 0xfa000000-0xfa0fffff] [ 1.034854] pci 0000:01:00.0: BAR 0: assigned [mem 0xfa000000-0xfa003fff 64bit] [ 1.035551] pci 0000:00:00.0: PCI bridge to [bus 01] [ 1.036004] pci 0000:00:00.0: bridge window [mem 0xfa000000-0xfa0fffff] [ 1.036811] pcieport 0000:00:00.0: enabling device (0000 -> 0002) [ 1.037672] pcieport 0000:00:00.0: PME: Signaling with IRQ 87 [ 1.039033] pcieport 0000:00:00.0: AER: enabled with IRQ 87 [ 1.331091] nvme nvme0: pci function 0000:01:00.0 0 Quote
frauhottelmann Posted February 8, 2021 Posted February 8, 2021 Which kernel and u-boot are you on? 0 Quote
Panzerknacker Posted February 8, 2021 Posted February 8, 2021 U-Boot v2021.01 + SPI-Patch Linux roc-pc 5.11.0-rc6-next-20210205 #166 SMP PREEMPT Fri Feb 5 12:05:45 CET 2021 aarch64 GNU/Linux But did also work with December kernels. pci was broken on linux-next/arm64 from 8. Jan. until end of Jan or beginning of Feb. 0 Quote
frauhottelmann Posted February 8, 2021 Posted February 8, 2021 vor 5 Minuten schrieb Panzerknacker: U-Boot v2021.01 + SPI-Patch Linux roc-pc 5.11.0-rc6-next-20210205 #166 SMP PREEMPT Fri Feb 5 12:05:45 CET 2021 aarch64 GNU/Linux But did also work with December kernels. pci was broken on linux-next/arm64 from 8. Jan. until end of Jan or beginning of Feb. Then that might be the problem. I am building 20.11 right now. Let's see if that helps. Otherwise I'll try master+dev kernel 0 Quote
Panzerknacker Posted February 8, 2021 Posted February 8, 2021 root@roc-pc:/usr/src/linux-next# cat .config |grep PCI |grep =y CONFIG_BLK_MQ_PCI=y CONFIG_HAVE_PCI=y CONFIG_PCI=y CONFIG_PCI_DOMAINS=y CONFIG_PCI_DOMAINS_GENERIC=y CONFIG_PCI_SYSCALL=y CONFIG_PCIEPORTBUS=y CONFIG_PCIEAER=y CONFIG_PCIEASPM=y CONFIG_PCIEASPM_DEFAULT=y CONFIG_PCIE_PME=y CONFIG_PCI_MSI=y CONFIG_PCI_MSI_IRQ_DOMAIN=y CONFIG_PCI_QUIRKS=y CONFIG_PCI_LABEL=y CONFIG_PCIE_ROCKCHIP=y CONFIG_PCIE_ROCKCHIP_HOST=y CONFIG_PCIE_DW=y CONFIG_PCIE_DW_HOST=y CONFIG_PCIE_DW_PLAT=y CONFIG_PCIE_DW_PLAT_HOST=y CONFIG_SERIAL_8250_PCI=y CONFIG_SND_PCI=y CONFIG_ARM_GIC_V3_ITS_PCI=y CONFIG_PHY_ROCKCHIP_PCIE=y CONFIG_GENERIC_PCI_IOMAP=y 0 Quote
Fred St-Pierre Posted February 8, 2021 Posted February 8, 2021 3 hours ago, Panzerknacker said: U-Boot v2021.01 + SPI-Patch Linux roc-pc 5.11.0-rc6-next-20210205 #166 SMP PREEMPT Fri Feb 5 12:05:45 CET 2021 aarch64 GNU/Linux But did also work with December kernels. pci was broken on linux-next/arm64 from 8. Jan. until end of Jan or beginning of Feb. That could explain why I couldn't boot the kernel a couple of weeks ago. I'll probably pull another attempt later this week, so I don't have to mess with initramfs off SPI. 0 Quote
Panzerknacker Posted February 8, 2021 Posted February 8, 2021 6 minutes ago, Fred St-Pierre said: That could explain why I couldn't boot the kernel a couple of weeks ago. Probably not, it affected only linux-next and the kernel booted always fine, just without initializing pcie. 0 Quote
Fred St-Pierre Posted February 8, 2021 Posted February 8, 2021 2 minutes ago, Panzerknacker said: Probably not, it affected only linux-next and the kernel booted always fine, just without initializing pcie. Well correct me if I'm wrong, but if it doesn't initialize pcie, it won't boot off the nvme drive? 0 Quote
Panzerknacker Posted February 8, 2021 Posted February 8, 2021 5 minutes ago, Fred St-Pierre said: but if it doesn't initialize pcie, it won't boot off the nvme drive? No, because U-Boot loads the kernel from nvme and boots it. Then the defect kernel would find no pcie/nvme and therefore has no root fs. You land with a booted kernel in the ramdisk. 0 Quote
Fred St-Pierre Posted February 8, 2021 Posted February 8, 2021 3 minutes ago, Panzerknacker said: No, because U-Boot loads the kernel from nvme and boots it. Then the defect kernel would find no pcie/nvme and therefore has no root fs. You land with a booted kernel in the ramdisk. Yeah, that's what I thought. I'll recompile everything again and reattempt loading the kernel from nvme 0 Quote
frauhottelmann Posted February 9, 2021 Posted February 9, 2021 Am 8.2.2021 um 10:29 schrieb frauhottelmann: I have also tried it with my big 5V power supply. Same problem. U-Boot looks good: Versteckten Inhalt anzeigen U-Boot TPL 2020.10-armbian (Feb 05 2021 - 15:50:41) Trying to boot from BOOTROM Returning to boot ROM... U-Boot SPL 2020.10-armbian (Feb 05 2021 - 15:50:41 +0000) Loading Environment from SPIFlash... *** Warning - bad CRC, using default environment Trying to boot from MMC1 NOTICE: BL31: v2.2(release):a04808c-dirty NOTICE: BL31: Built : 15:50:35, Feb 5 2021 U-Boot 2020.10-armbian (Feb 05 2021 - 15:50:41 +0000) SoC: Rockchip rk3399 Reset cause: POR Model: Firefly ROC-RK3399-PC Mezzanine Board DRAM: 3.9 GiB PMIC: RK808 MMC: mmc@fe310000: 2, mmc@fe320000: 1, sdhci@fe330000: 0 Loading Environment from SPIFlash... SF: Detected w25q128 with page size 256 Bytes, erase size 4 KiB, total 16 MiB *** Warning - bad CRC, using default environment In: serial Out: serial Err: serial Model: Firefly ROC-RK3399-PC Mezzanine Board Net: eth0: ethernet@fe300000 Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc1 is current device Scanning mmc 1:1... Found U-Boot script /boot/boot.scr 3185 bytes read in 5 ms (622.1 KiB/s) ## Executing script at 00500000 Boot script loaded from mmc 1 230 bytes read in 5 ms (44.9 KiB/s) 15339012 bytes read in 652 ms (22.4 MiB/s) 28582400 bytes read in 1213 ms (22.5 MiB/s) 77058 bytes read in 12 ms (6.1 MiB/s) 267 bytes read in 8 ms (32.2 KiB/s) Applying kernel provided DT overlay rockchip-pcie-gen2.dtbo 2698 bytes read in 8 ms (329.1 KiB/s) Applying kernel provided DT fixup script (rockchip-fixup.scr) ## Executing script at 09000000 Moving Image from 0x2080000 to 0x2200000, end=3de0000 ## Loading init Ramdisk from Legacy Image at 06000000 ... Image Name: uInitrd Image Type: AArch64 Linux RAMDisk Image (gzip compressed) Data Size: 15338948 Bytes = 14.6 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 01f00000 Booting using the fdt blob at 0x1f00000 Loading Ramdisk to f1078000, end f1f18dc4 ... OK Loading Device Tree to 00000000f0ffc000, end 00000000f1077fff ... OK Starting kernel ... Armbianmonitor: http://ix.io/2OIx @piter75 any ideas why it wouldn't work? You also have one right? 0 Quote
denni_isl Posted February 9, 2021 Posted February 9, 2021 How can one clock roc-rk3399-pc to 2016000 Armbian 21.02.1 kern 5.10.12 Bullseye - already done armbian-config, Hardware, rk3399-opp-2ghz, 2 hours ago, frauhottelmann said: @piter75 any ideas why it wouldn't work? You also have one right? boot with sd and cd and sudo mkdir /mnt/mmcblk2 - sudo mount /dev/mmcblk2 /mnt/mmcblk2/boot - ls -alh - in my case after update another one of the image at link was linked wrongly Image or uInitrd - had to remove and ln -s target link again. If it is the same issue. 0 Quote
frauhottelmann Posted February 9, 2021 Posted February 9, 2021 vor einer Stunde schrieb denni_isl: How can one clock roc-rk3399-pc to 2016000 Armbian 21.02.1 kern 5.10.12 Bullseye - already done armbian-config, Hardware, rk3399-opp-2ghz, After applying the overlay you also have to go to armbian-config -> system -> governor and frequency (or whatever it's called). Then select the lowest and highest frequency and the governor and reboot. 0 Quote
denni_isl Posted February 9, 2021 Posted February 9, 2021 29 minutes ago, frauhottelmann said: After applying the overlay you also have to go to armbian-config -> system -> governor and frequency (or whatever it's called). Then select the lowest and highest frequency and the governor and reboot. The max is still 1800000 - it has something to do with compiling the .dtb - have not looked much into that yet - https://docs.armbian.com/Developer-Guide_User-Configurations/ 0 Quote
piter75 Posted February 9, 2021 Posted February 9, 2021 8 hours ago, frauhottelmann said: any ideas why it wouldn't work? You also have one right? When I first read your post about MP510 not working I was a bit surprised because I was testing my SPI/NVMe changes with Silicon Power's SP34A80 512GB which uses exactly the same controller - Phison E12. I verified again with SP and it still works properly. I also have a few MP510s and decided to retest it with MP510 240GB which is normally mounted in ROCK Pi 4B. To my surprise MP510 240GB is not recognised in roc-rk3399-pc with neither u-boot nor kernel. I then tested another MP510 (480GB) that is newer and using a bit worse flash chips. This one is recognised in both u-boot and kernel. I guess this is good because I can reproduce it (and maybe try to fix when I find some spare time) but it still keeps me wondering why... All drives use a standard Phison E12 design and should be AFAIK (almost) identical. Maybe it's the firmware version that makes a difference... 0 Quote
frauhottelmann Posted February 10, 2021 Posted February 10, 2021 vor 18 Stunden schrieb piter75: When I first read your post about MP510 not working I was a bit surprised because I was testing my SPI/NVMe changes with Silicon Power's SP34A80 512GB which uses exactly the same controller - Phison E12. I verified again with SP and it still works properly. I also have a few MP510s and decided to retest it with MP510 240GB which is normally mounted in ROCK Pi 4B. To my surprise MP510 240GB is not recognised in roc-rk3399-pc with neither u-boot nor kernel. I then tested another MP510 (480GB) that is newer and using a bit worse flash chips. This one is recognised in both u-boot and kernel. I guess this is good because I can reproduce it (and maybe try to fix when I find some spare time) but it still keeps me wondering why... All drives use a standard Phison E12 design and should be AFAIK (almost) identical. Maybe it's the firmware version that makes a difference... Thanks Unfortunately I don't have another device right now to test the ssd or update the firmware. But that'll change soon. 0 Quote
balbes150 Posted February 18, 2021 Posted February 18, 2021 I checked the Legacy and Current versions (for Firefly Station P1) on Renegade Elite , everything works, u-boot normally starts the system from the SD card and USB media. When running Buster-Legacy + NVMe, I used DTB from the site (the version is not plus), NVMe works and the rest of the hardware works with the media script. On the Curren version, I used DTB (mezzanine from the image composition), NVMe works, LAN works, HDMI sound. I think can consider the Renegade Elite compatible equipment with Station P1 and specify this information on the download page or in the forum thread. 0 Quote
RussianNeuroMancer Posted March 2, 2021 Posted March 2, 2021 Is there any way to get DisplayPort over USB Type-C working on anything besides Firefly image? I tried Armbian legacy once again (this time I tested images for both of Renegade Elite and Station P1; latter image was tested with rk3399-roc-pc-mezzanine.dtb too) but unfortunately DisplayPort doesn't work at all (tested Dell DA300 and Belkin F4U093) - I guess due to difference in uboot version? Or maybe 4.4 tree by ayufan missing something for this board? 0 Quote
denni_isl Posted June 3, 2021 Posted June 3, 2021 To turn off the annoying heartbeat blue light. Quote Become a root; su to see the possibilities; cat /sys/class/leds/green:work/trigger to turn off the blue heartbeat light; echo none > /sys/class/leds/green:work/trigger make a script and let /etc/rc.local run it at startup script; #!/bin/bash echo none > /sys/class/leds/green:work/trigger make the script executable chmod +x turn_off_blue_light.sh /etc/rc.local #!/bin/sh -e /path/to/turn_off_blue_light.sh exit 0 0 Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.