PINE64
Linux Mainline - Printable Version

+- PINE64 (https://forum.pine64.org)
+-- Forum: ROCK64 (https://forum.pine64.org/forumdisplay.php?fid=85)
+--- Forum: Linux on Rock64 (https://forum.pine64.org/forumdisplay.php?fid=88)
+--- Thread: Linux Mainline (/showthread.php?tid=5043)

Pages: 1 2 3 4 5 6 7

RE: Linux Mainline - maal - 01-07-2018

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.

RE: Linux Mainline - valdiks - 01-08-2018

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


RE: Linux Mainline - matteobp - 01-10-2018

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

RE: Linux Mainline - maal - 01-10-2018

I don't think it's a problem.

From datasheet (http://opensource.rock-chips.com/images/d/d7/Rockchip_RK3328_Datasheet_V1.1-20170309.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).

RE: Linux Mainline - matteobp - 01-10-2018

Ok. Clear. Thanks.

RE: Linux Mainline - redfish - 01-13-2018

(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

RE: Linux Mainline - ayufan - 01-14-2018

It was fixed. Maybe you have some other problem?

RE: Linux Mainline - redfish - 01-14-2018

(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?

RE: Linux Mainline - redfish - 01-15-2018

(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-mainline-kernel/pull/1

RE: Linux Mainline - t4_4t - 01-19-2018

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