Mainline support for RockPi 4?

I can boot current 5.2-rc.

One caveat: If you halt the system with “shutdown -h” you need to quickly unplug the power, otherwise the system will become hot. Very hot. :scream: Any ideas where to report bugs like that?

The same thing happens when you run into a kernel panic, so be sure to add the “panic=1” kernel option.

2 Likes

Probably best to ask this in the IRC freenode #linux-rockchip. (The linux-rockchip maintainers name would be mmind00)

@smurf Its prob like boot as I am pretty sure until the kernel kicks in and governor we are booting @ 2.0ghz from what the console said from memory.
I presume it might be free wheeling that way on shutdown.

PS with RC-7 and the very latest pull of mesa panfrost seems to be working without error

  PROCESSOR:          ARMv8 Cortex-A72 @ 1.42GHz
    Core Count:       6
    Scaling Driver:   cpufreq-dt ondemand

  GRAPHICS:           panfrost 2GB
    Display Driver:   modesetting 1.20.5
    Monitor:          S22C570
    Screen:           1920x1080

  MOTHERBOARD:        Radxa ROCK Pi 4

  MEMORY:             2048MB

  DISK:               31GB SD32G
    File-System:      ext4
    Mount Options:    relatime rw

  OPERATING SYSTEM:   Manjaro-ARM 19.06
    Kernel:           5.2.0-rc7-4-MANJARO-ARM (aarch64) 20190701
    Desktop:          KDE Plasma 5.16.2
    Display Server:   X Server 1.20.5
    Compiler:         GCC 8.3.0
    Security:         l1tf: Not affected
                      + mds: Not affected
                      + meltdown: Not affected
                      + spec_store_bypass: Vulnerable
                      + spectre_v1: Mitigation of __user pointer sanitization
                      + spectre_v2: Vulnerable

Thanks, will test.

Next problem: the upper USB3 port seems to be fixed to OTG mode in arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4.dts, regardless of what the switch is set to. Owch.

1 Like

That must be config as unless the kernel module is loaded or kernel included.

Not exactly sure about that smurf but all the switch does is short rsense and gnd, if its running in otg mode depends on kernel modules loaded and not dts.
DTS just sets the parameters when in use?

Well, I checked the DTS in the kernel: USB3-0 is set to “otg” and USB3-1 says “host”. When I edit that and set USB3-0 to “host”, lo and behold, the upper port works.

Thus I suspect that the DTS stanza to change that changes the port mode depending on rsense is missing.

Another problem: systemd-networkd is unable to bring up eth0.

Feb 14 11:11:59 TODO systemd-networkd[247]: lo: Configured
Feb 14 11:11:59 TODO systemd-networkd[247]: eth0: Could not bring up interface: Invalid argument
Feb 14 11:11:59 TODO systemd-udevd[241]: Using default interface naming scheme 'v240'.
Feb 14 11:11:59 TODO systemd-udevd[241]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable.
Feb 14 11:11:59 TODO systemd-udevd[241]: link_config: could not get ethtool features for eth0
Feb 14 11:11:59 TODO systemd-udevd[241]: Could not set offload features of eth0: Device or resource busy
Feb 14 11:11:59 TODO systemd[1]: Reached target Network.

I added /etc/systemd/system/systemd-networkd.service.d/eth0.conf

[Service]
ExecStartPre=/sbin/ip link set dev eth0 up

which fixes this but obviously is not a good long term solution.

2 Likes

I am using the Manjaro preview as a base then upgrading kernel via 'pacman -S linux-aarch64-rc` as they have been lightening fast with updates.

With what I have didn’t notice an Eth0 problem as was working.

Last lines of my console, wish they would do the early printk stuff though.

[  170.425652] rk_gmac-dwmac fe300000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off
[  170.426415] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

@stuartiannaylor early printk should work (on the serial console) if you configure it in the kernel args:

earlycon=uart8250,mmio32,0xff1a0000 earlyprintk console=ttyS2,1500000n8

Are they using systemd-networkd for setting up the network? It does work with other tools. Maybe systemd is just too finicky. I’ll check.

Yeah I wish it was default that is all as playing with images I am getting lazy and bored of the mod.
It does work just wish it was default :slight_smile:

Hadn’t noticed an eth0 prob but haven’t checked but ssh has always worked and eth0 always there but prob the way manjaro are doing it.
Haven’t looked as its just been Panfrost testing which is still a bit flakey but massively improved.

Next, trying to get NVMe M.2 card working … I am using the 5.3-next patches but no luck yet.
Maybe just a missing kernel module?

Yeah PCIe is a bugbear been pleading with the Manjaro guys to go full hog and try and patch it as so many of the community seem to utilise.
No luck as of yet but they had to source nvme as they received m.2 extender but just had sata m.2 ssds.

To be honest why m.2 sata cards work and m.2 sata ssds don’t is a confusion to me.

If you look at 4.4 there is a whole load of stuff going on in uboot also

1 Like

Well, u-boot is something I’ll tackle some other time, I’m happy to get the mainline kernel up and running. USB-3 works well enough, so I’ll use two disks on that until NVMe gets fixed.

Gotta save some power here, keeping a fat server running 24/7 is no fun these days.

Next up: testing whether a LiFePo4wered hat is able to keep a Rock Pi 4 running long enough to safely shut everything down.

1 Like

Having a look at pcie with a guesstimate or what I see elsewhere we need

@97 replace

	vcc3v3_pcie: vcc3v3-pcie-regulator {
		compatible = "regulator-fixed";
		enable-active-high;
		gpio = <&gpio1 RK_PD0 GPIO_ACTIVE_HIGH>;
		pinctrl-names = "default";
		pinctrl-0 = <&pcie_pwr_en>;
		regulator-name = "vcc3v3_pcie";
		regulator-always-on;
		regulator-boot-on;
		vin-supply = <&vcc12v_dcin>;

Currently

	vcc3v3_pcie: vcc3v3-pcie-regulator {
		compatible = "regulator-fixed";
		enable-active-high;
		gpio = <&gpio1 RK_PD0 GPIO_ACTIVE_HIGH>;
		pinctrl-names = "default";
		pinctrl-0 = <&pcie_pwr_en>;
		regulator-name = "vcc3v3_pcie";
		regulator-always-on;
		regulator-boot-on;
		regulator-min-microvolt = <3300000>;
		regulator-max-microvolt = <3300000>;
		vin-supply = <&vcc12v_dcin>;

@ 515 add

&pcie_phy {
	status = "okay";
};

&pcie0 {
	ep-gpios = <&gpio2 RK_PD4 GPIO_ACTIVE_HIGH>;
	num-lanes = <4>;
	max-link-speed = <2>;
	pinctrl-names = "default";
	pinctrl-0 = <&pcie_clkreqn_cpm>;
	vpcie3v3-supply = <&vcc3v3_pcie>;
	status = "okay";
};

That compiled, but there are no entries in /sys/bus/pci*/devices.
I think I enabled all necessary drivers …

Dunno mate I was looking at this

https://github.com/torvalds/linux/compare/master...ayufan-rock64:master and doing a compare to the master.

I wasn’t really sure about this @145

	vcc_phy: vcc-phy-regulator {
		compatible = "regulator-fixed";
		regulator-name = "vcc_phy";
		regulator-always-on;
		regulator-boot-on;
	};

I will let you compare as not even sure if ayufan has pcie implemented mainline maybe not its was just a hunch he might of.
He is the guy to get in touch with his knowledge is like awesome and I am not worthy.

PS with your compiling if you have a m.2 sata ssd drive and you ever fancy enabling CONFIG_SATA_AHCI in the working 4.4 kernel
Then seeing if you have a sata ssd drive recognised would at least rule that one out.
It will never be recognised without that in the config but even when enabled we may only find out why it was removed or omission .

The LiFePo4wered hat works, or at least it would work if I’d see it on i2c, which I don’t.
Probably a speed issue – the LiFePo4 requires 100kbit, not 400. Worse, it doesn’t do clock stretching because the Pi doesn’t support that anyway. Changing the obious value in the DTS didn’t affect the result. Sigh.

CONFIG_SATA_AHCI is on in my kernel, didn’t change anything unfortunately.

I wrote to ayufan, no reply yet, will keep everybody posted. Let’s hope we’ll get a functional board in 5.3 …

Yeah must of done a typo when I did a find or some mistake.

The whole sata ssd on pice not working is confusing me. But actually my bugbear was cost and seemed to of found one https://www.mymemory.co.uk/integral-120gb-m-2-2280-pcie-nvme-ssd-drive.html so its even less of a pressing need than I thought.

5.2 is released and there is a whole slew of patches in 5.3-rc1 and mesa-19.1.2 is released tomoz that should have much better panfrost support.

Now that kernel 5.2 is released (to the manjaro arm repos at least). Any idea on how to get gpu acceleration working in x11?

I have just been trying and dunno as since Mesa 19.1.1 I had to compile the Master 19.1.2
Which worked but Manjaro have released 5.2 & 19.1.2 as it came out yesterday and it seems like a reversion or what I was compiling missed the deadline.

I am just going to compile mesa & drm one more time and the Master (latest) again.


https://panfrost.freedesktop.org/building-panfrost-mesa.html

PS you have to remove fbturbo driver to force panfrost

If you sudo pacman -Ss fbturbo
That will search for the package as I can never remember its full name

sudo pacman -R fbturbo whatever

reboot and the KMS driver should be loaded

pacman -S bc python-pip flex bison base-devel ncurses cmake xorg-util-macros
pip install scikit-build mako meson ninja
1 Like

Yeah master works but also did drm.

Quick run down as the above is for a debian/ubuntu or something

sudo pacman -S bc python-pip flex bison base-devel ncurses cmake xorg-util-macros
sudo pip install scikit-build mako meson ninja
git clone https://gitlab.freedesktop.org/mesa/drm.git --depth=1
cd drm
./autogen.sh
./configure --prefix=/usr
make -j6
sudo make install
cd ..
git clone https://gitlab.freedesktop.org/mesa/mesa.git --depth=1
cd mesa
mkdir build
meson -Ddri-drivers= -Dvulkan-drivers= -Dgallium-drivers=panfrost,kmsro -Dlibunwind=false -Dplatforms=x11,drm,surfaceless -Dprefix=/usr build/
ninja -C build/
sudo ninja -C build/ install

As long as you removed the fbturbo package reboot and there you go

[rock@rockpi4 ~]$ glmark2
=======================================================
    glmark2 2014.03
=======================================================
    OpenGL Information
    GL_VENDOR:     panfrost
    GL_RENDERER:   panfrost
    GL_VERSION:    2.1 Mesa 19.1.2 (git-fe1f7b538b)
=======================================================
[build] use-vbo=false: FPS: 164 FrameTime: 6.098 ms
[build] use-vbo=true: FPS: 382 FrameTime: 2.618 ms
[texture] texture-filter=nearest: FPS: 394 FrameTime: 2.538 ms
[texture] texture-filter=linear: FPS: 394 FrameTime: 2.538 ms
[texture] texture-filter=mipmap: FPS: 391 FrameTime: 2.558 ms
[shading] shading=gouraud: FPS: 328 FrameTime: 3.049 ms
[shading] shading=blinn-phong-inf: FPS: 328 FrameTime: 3.049 ms
[shading] shading=phong: FPS: 296 FrameTime: 3.378 ms
[shading] shading=cel: FPS: 239 FrameTime: 4.184 ms
[bump] bump-render=high-poly: FPS: 196 FrameTime: 5.102 ms
[bump] bump-render=normals: FPS: 414 FrameTime: 2.415 ms
[bump] bump-render=height: FPS: 402 FrameTime: 2.488 ms
libpng warning: iCCP: known incorrect sRGB profile
[effect2d] kernel=0,1,0;1,-4,1;0,1,0;: FPS: 381 FrameTime: 2.625 ms
libpng warning: iCCP: known incorrect sRGB profile
[effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: 186 FrameTime: 5.376 ms
[pulsar] light=false:quads=5:texture=false: FPS: 415 FrameTime: 2.410 ms
libpng warning: iCCP: known incorrect sRGB profile
[desktop] blur-radius=5:effect=blur:passes=1:separable=true:windows=4:glmark2: ../src/util/ralloc.c:91: get_header: Assertion `info->canary == CANARY' failed.
Aborted (core dumped)

Dunno if that is me compiling glmark2 from aur wrong or panfrost.

rock@rockpi4 glmark2]$ vblank_mode=0 glxgears
ATTENTION: default value of option vblank_mode overridden by environment.
5384 frames in 5.0 seconds = 1076.761 FPS
5361 frames in 5.0 seconds = 1072.048 FPS
5554 frames in 5.0 seconds = 1110.738 FPS
5602 frames in 5.0 seconds = 1120.345 FPS
5608 frames in 5.0 seconds = 1121.375 FPS
5634 frames in 5.0 seconds = 1126.753 FPS
5653 frames in 5.0 seconds = 1130.372 FPS
5640 frames in 5.0 seconds = 1127.873 FPS
5700 frames in 5.0 seconds = 1139.857 FPS
5600 frames in 5.0 seconds = 1119.792 FPS

2 Likes