After reading today's irc logs I've realized that ayufan has found the solution.
You need to change "rx_delay" in file "arch/arm64/boot/dts/rockchip/rk3328-rock64.dts".
From:
rx_delay = <0x11>;
To:
rx_delay = <0x18>;
After that change everything is peachy:
Code:
[root@cep03 ~]# uname -a
Linux cep03 4.15.0-rc6 #2 SMP PREEMPT Sat Jan 6 18:45:37 UTC 2018 aarch64 aarch64 aarch64 GNU/Linux
[root@cep03 ~]# iperf3 -c 192.168.11.100 -R
Connecting to host 192.168.11.100, port 5201
Reverse mode, remote host 192.168.11.100 is sending
[ 4] local 192.168.11.103 port 48676 connected to 192.168.11.100 port 5201
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 60.6 MBytes 508 Mbits/sec
[ 4] 1.00-2.00 sec 79.0 MBytes 663 Mbits/sec
[ 4] 2.00-3.00 sec 96.8 MBytes 812 Mbits/sec
[ 4] 3.00-4.00 sec 96.7 MBytes 811 Mbits/sec
[ 4] 4.00-5.00 sec 96.6 MBytes 811 Mbits/sec
[ 4] 5.00-6.00 sec 96.9 MBytes 813 Mbits/sec
[ 4] 6.00-7.00 sec 97.0 MBytes 814 Mbits/sec
[ 4] 7.00-8.00 sec 96.8 MBytes 812 Mbits/sec
[ 4] 8.00-9.00 sec 97.0 MBytes 813 Mbits/sec
[ 4] 9.00-10.00 sec 96.2 MBytes 807 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 914 MBytes 767 Mbits/sec 0 sender
[ 4] 0.00-10.00 sec 914 MBytes 767 Mbits/sec receiver
iperf Done.
[root@cep03 ~]# ethtool -S eth0 | grep err | grep -v ": 0"
[root@cep03 ~]#
I would like to thank ayufan for his contributions to linux on Rock64.
Hello, I have LibreELEC-ROCK64.arm-rb-leia21 installed on the Rock64 4GB and connected to the Sony Bravia 55xd85 4k TV. Everything works fine except that while watching a movie in random time I have something like connection lag (similar when resolution is changed) - video does not disappear but audio disappear for ~3 sec. It happens about every 5-25 mins. I've changed HDMI cable but it doesn't help.
Here is error that is written in log when it happens:
Code:
Jan 08 10:15:12 LibreELEC kernel: rk-vcodec ff360000.rkvdec: closed
Jan 08 10:19:31 LibreELEC kernel: rockchip-pm-domain ff100000.syscon:power-controller: failed to get ack on domain 'pd_video', val=0x0
Jan 08 10:19:38 LibreELEC connmand[317]: ntp: adjust (slew): +0.001027 sec
Jan 08 10:20:36 LibreELEC kernel: dwhdmi-rockchip ff3c0000.hdmi: Rate 296703000 missing; compute N dynamically
Jan 08 10:24:16 LibreELEC kernel: rockchip-pm-domain ff100000.syscon:power-controller: failed to get ack on domain 'pd_video', val=0x0
Jan 08 10:36:42 LibreELEC connmand[317]: ntp: adjust (slew): +0.000761 sec
Jan 08 10:36:49 LibreELEC kernel: rockchip-pm-domain ff100000.syscon:power-controller: failed to get ack on domain 'pd_video', val=0x0
Yesterday I tried the latest
0.6.13 release, and this is the last part of the output of
dmesg command
Code:
[ OK ] Started Daily apt upgrade and clean activities.
[ OK ] Reached target Timers.
[ OK ] Started Regular background program processing daemon.
[ OK ] Started Save/Restore Sound Card State.
[ OK ] Started Avahi mDNS/DNS-SD Stack.
[ OK ] Started LSB: Start/stop sysstat's sadc.
[ OK ] Started Login Service.
[ OK ] Started System Logging Service.
[ OK ] Started Raise network interfaces.
[ 7.416981] random: nonblocking pool is initialized
[ 8.299173] rk_gmac-dwmac ff540000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
[ OK ] Started Network Manager.
Starting Network Manager Wait Online...
[ OK ] Reached target Network.
Starting Permit User Sessions...
Starting Network Manager Script Dispatcher Service...
[ OK ] Started Permit User Sessions.
[ OK ] Started Serial Getty on ttyFIQ0.
[ OK ] Started Getty on tty1.
[ OK ] Reached target Login Prompts.
[ OK ] Started Network Manager Script Dispatcher Service.
Starting Hostname Service...
[ OK ] Started Hostname Service.
[ 9.184481] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
Starting Authorization Manager...
[ OK ] Started Authorization Manager.
[ 9.534881] EXT4-fs (mmcblk1p7): resizing filesystem from 524288 to 1907707 blocks
[ 9.730209] EXT4-fs (mmcblk1p7): resized filesystem to 1907707
[ OK ] Started Rock 64 First boot.
[ OK ] Started Generate SSH keys if not there.
Starting OpenBSD Secure Shell server...
[ OK ] Started OpenBSD Secure Shell server.
[ 12.775433] rk_gmac-dwmac ff550000.ethernet eth1: Link is Up - 100Mbps/Half - flow control off
[ 12.781019] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
[ 13.834677] tty_port_close_start: tty->count = 1 port count = 2.
Notice in particular these 2 lines
[ 8.299173] rk_gmac-dwmac ff540000.ethernet eth0:
Link is Up - 1Gbps/Full - flow control rx/tx
[ 12.775433] rk_gmac-dwmac ff550000.ethernet eth1:
Link is Up - 100Mbps/Half - flow control off
Same behaviour with both 4.4.103 and 4.15.0 kernel.
The problem is still there.
I don't think it's a problem.
From datasheet (
http://opensource.rock-chips.com/images/...170309.pdf):
GMAC 10/100/1000M Ethernet Controller
Supports 10/100/1000-Mbps data transfer rates with the RGMII interfaces
Supports 10/100-Mbps data transfer rates with the RMII interfaces
There are 2 controllers, one is connected to internal FE PHY, the other is for external PHY device
Supports both full-duplex and half-duplex operation
Supports IEEE 802.1Q VLAN tag detection for reception frames
Support detection of LAN wake-up frames and AMD Magic Packet frames
Handles automatic retransmission of Collision frames for transmission
Ethernet PHY
Integrated IEEE 802.3/802.3u compliant 10/100Mbps Ethernet PHY
Supporting both full and half duplex for either 10 or 100 Mb/s data rate
Auto MDIX capable
Supports wake-on-LAN, EEE
100Base-FX support
Supports auto-negotiation
According to dmesg messages both Ethernet controllers are connected: first at 1 Gbit/s, second at 100 Mbit/s (max supported by internal PHY).
(09-24-2017, 05:26 AM)scat70 Wrote: [ -> ]Hi !
Seems that there is an issue in kernel 4.13 in handling the eMMC which is mmc0 (while mmc1 is the SD card):
Begin: Running /scripts/local-premount ... done.
[ 3.003233] mmc_host mmc0: Bus speed (slot 0) = 200000000Hz (slot req 200000000Hz, actual 200000000HZ div = 0)
[ 3.004152] dwmmc_rockchip ff520000.dwmmc: Tuning clock (sample_clk) not defined.
[ 3.004816] mmc0: tuning execution failed: -5
[ 3.005208] mmc0: error -5 whilst initialising MMC card
In initramfs only the SD card is visible but not the eMMC module which I use mainly:
(initramfs) blkid
/dev/mmcblk1p1: UUID="f64c30f7-7269-4e80-bf0a-1a6a3ee14d5d" TYPE="ext4" PARTUUID="101b1335-dc89-42c5-82d1-2856ed148e6e"
/dev/mmcblk1: PTUUID="a0fedc3d-260c-4382-aa5c-9af5d95cc746" PTTYPE="gpt"
I'm still getting exactly this mmc error in my build of latest kernel from ayufan/linux-mainline-kernel 59389fa34d4f (above 4.15.0-rc3). Would updating u-boot help? If so, which instructions to follow, these?:
http://opensource.rock-chips.com/wiki_U-Boot
It was fixed. Maybe you have some other problem?
(01-14-2018, 05:00 AM)ayufan Wrote: [ -> ]It was fixed. Maybe you have some other problem?
The above is exactly the output from serial console that I am getting now. Then I am being dropped into a maintanance shell (because my rootfs is on emmc). Do you recall the commit that fixed this problem (even approximately, I can search for it)? I posted the commit hash i'm using: does that hash include the fix?
(01-13-2018, 10:19 PM)redfish Wrote: [ -> ] (09-24-2017, 05:26 AM)scat70 Wrote: [ -> ]Hi !
Seems that there is an issue in kernel 4.13 in handling the eMMC which is mmc0 (while mmc1 is the SD card):
Begin: Running /scripts/local-premount ... done.
[ 3.003233] mmc_host mmc0: Bus speed (slot 0) = 200000000Hz (slot req 200000000Hz, actual 200000000HZ div = 0)
[ 3.004152] dwmmc_rockchip ff520000.dwmmc: Tuning clock (sample_clk) not defined.
[ 3.004816] mmc0: tuning execution failed: -5
[ 3.005208] mmc0: error -5 whilst initialising MMC card
In initramfs only the SD card is visible but not the eMMC module which I use mainly:
(initramfs) blkid
/dev/mmcblk1p1: UUID="f64c30f7-7269-4e80-bf0a-1a6a3ee14d5d" TYPE="ext4" PARTUUID="101b1335-dc89-42c5-82d1-2856ed148e6e"
/dev/mmcblk1: PTUUID="a0fedc3d-260c-4382-aa5c-9af5d95cc746" PTTYPE="gpt"
I'm still getting exactly this mmc error in my build of latest kernel from ayufan/linux-mainline-kernel 59389fa34d4f (above 4.15.0-rc3). Would updating u-boot help? If so, which instructions to follow, these?: http://opensource.rock-chips.com/wiki_U-Boot
Fixed by merging a patch from ayufan's linux-kernel into ayufan's linux-mailine kernel:
95368b4b832d932f75a1813a056805b84af9cff6
ayufan: bring back required clocks for emmc to make it working
Submitted pull request:
https://github.com/ayufan-rock64/linux-m...nel/pull/1
Two LEDs (white: Power, red: Stanby) on rock64-board are not displayed correctly.
Do you recognize that?
Concrete state is:
In kernel-4.4.103 both of them are always off, and
in kernel-4.15.0 both are always on.
When confirming Commits, the LED display has been changed several times.
And the contents of the last Commits are as follows.
Looking at this, I think that the above state is different from the expected behavior.
Finally,
The kernel-4.15.0 @ 0.6.13 setting is "heartbeat" & "mmc 0".
And this version will work correctly, I add this and report it.
---
ayufan: rock64: use disk-activity as trigger
Change-Id: I1467219088d94df1f874319afd8bf286c64ed6a7 standby-led {
...
standby-led {
- linux,default-trigger = "heartbeat";
- gpios = <&rk805 1 GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "disk-activity";
+ gpios = <&rk805 0 GPIO_ACTIVE_LOW>;
default-state = "on";
};
power-led {
- linux,default-trigger = "mmc0";
- gpios = <&rk805 0 GPIO_ACTIVE_LOW>;
+ gpios = <&rk805 1 GPIO_ACTIVE_LOW>;
default-state = "on";
};
...