Jump to content

ROC-RK3399-PC (Renegade Elite)


tkaiser

Recommended Posts

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 :D
The m.2 is a Corsair Force MP510 NVMe drive. Power supply is a 60W PD unit,

Link to comment
Share on other sites

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.

 

spi-pinnar.png

Link to comment
Share on other sites

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

 

 

Link to comment
Share on other sites

[    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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

 

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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/

 

Link to comment
Share on other sites

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...

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.  :)

 

 

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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

 

 

 

 

 

 

Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines