Linux Mainline - Printable Version

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