Linux Mainline

[maal]

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.

[valdiks]

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

[matteobp]

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. 

[maal]

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

[matteobp]

Ok. Clear. Thanks.

[redfish]

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

[ayufan]

It was fixed. Maybe you have some other problem?

[redfish]

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?

[redfish]

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

[t4_4t]

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";
};
...