Mainline support for RockPi 4?

Hi!! I could’t even boot on kernel 5.0 from panfrost and 5.2 from torvalds. Ive use the radxa defconf and on mainline kernel ive use the dts from torvalds repo. Dont know whats happening. Ive tried on armbian and on debian. The worst thing its than it wont display any console output even if Ive set that. Could you give me any tip of how to make this happen?. I dont care if its not really functional, I need to test panfrost.

You are probably not even getting to the kernel and likely uboot.
If you are creating your own from scratch without a serial console to check uboot then you are prob better to wait or use some elses.

Starts on 5.1 has 5.2 testing in the repo new mesa and panfrost has problems

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?