Mainline support for RockPi 4?

Any progress?

I’m working on a project that would result in my employer buying quite a few devices – stalled because we need decent mass storage and mainline kernel features.

Manjaro Arm are working with the RockPi4 I just booted with Kernel 5.1 but 5.2 is hopefully the destination with a panfrost/weston/wayland solution.

I can not forward as the work is theirs but you can pretty much take it that arch/manjaro mainline is pretty much imminent.
Jack tested a Marvel 9235 4 port recently and works perfect and is prob the best card available.

Or you can add another 4 ports of usb3.0 via much cheaper cards.

1 Like

Hey, I just noticed that there’s a development Wiki page that states that 5.1. works.

Nice. Now if that page was not somewhat empty …

Its very informative if you don’t see the info read the top line again.

The Manjaro guys only really started today and they are currently using 5.1
So far Wifi/BT & PCIe don’t seem to be mainline.

I don’t think it will be long before they release something for testing, but just left them to it.

Its looking like for complete mainline without overlays it could be 5.3

1 Like

Nice progress :smile:

In kernel 5.1 we have:

In kernel 5.2 we have:

In kernel 5.3 we’ll have:

So, from 5.3 on these should work:

  • HDMI Display
  • Console
  • USB 2.0, USB-3.0
  • Ethernet
  • Mali GPU Node
  • Wifi and Bluetooth
  • Audio over HDMI

Also, uboot has first support:
[U-Boot] rockchip: rk3399: Add Rock PI 4 support
and LPDDR4 support is sent to the mailing list.


Yeah the KDE version with 5.1 seems to be wifi/bt, pcie and audio over HDMI.
I haven’t tried but the Mali module hasn’t been configured and prob needs a recompile to allow the addition of the rockchip midgard driver, until panfrost 5.2.
Prob being a first inclusion it may not be a smooth ride with panfrost but you never know :slight_smile:

Also there is the Armbian version but haven’t tried that yet. I might head there next as they have some great build scripts.

5.2 which is early July I am sure some clever tinkerer can backport those few patches as it would seem time to start gearing up for mainline and long live 4.4, but … :slight_smile:
I still perplexed why the DTS still has PCIe set to gen1 as didn’t notice that anywhere. Maybe its me being usually dumb but PCIe is backward compatible or is it fixed to specific gens on the rk3399?
Also Radxa and overlay support?

Nice. I’m trying to get 5.2 RC up and running in my setup (I don’t need the 5.3 features yet) but the serial console overlay from 4.4 does not work. So either I missed a kernel config option, or things have changed too much.

reading /overlays/console-on-ttyS2.dtbo
774 bytes read in 16 ms (46.9 KiB/s)
overlay dtb(0x0000000001e00000) is valid
fdt_overlay_apply 0000000001f00000 0000000001e00000
fdt_overlay_apply(): FDT_ERR_NOTFOUND
Can't load dts overlay

While it does boot without console :slight_smile: debugging is a whole lot easier when you have one …

As not sure what uharts are in use between the 2, but overlays are not enabled in mainline…

Majority of the overlay commands just enable specific hardware and hat details and are a good inclusion but for just raw kernel try without.

I have used the serial console on the manjaro images but they keep totally mainline and zero radxa packages.
You only need the overlay if you are going to have the console on another than default uhart

5.2 RC4 was freezing for a while but haven’t tested but fingers crossed looking at the patches may be fixed in RC5

Connect the USB to TTL serial cable as below. Don’t connect the red wire.

ROCK Pi 4 <—> USB to TTL cable
RX(pin 10) <—> Green wire
TX(pin 8) <—> White wire
GND(pin 6) <—> Black wire

You may have to swap round TX/RX as I can never tell which side they are supposed to relate to and you should be set to 3.3v, also ignore the colors as it varies wildly but should be marked but which end they refer to seems to be pot luck.

baudrate: 1500000
   data bit: 8
   stop bit: 1
   parity  : none
   flow control: none

I like coolterm if you are using windows

It would be really beneficial for radxa to start supporting mainline as the specific radxa patches now needed are actually very few.

Umm, I do have a serial console which works for u-boot. And 4.4. But 5.2 is silent. Probably just wrong kernel arguments?

NB, I have a µArt TTL-serial interface. That is an isolating converter. So yes, I do need to connect its version of the red wire. :wink:

I’m sure you’ve checked this already, but something that catches me out from time to time when I build board kernels is differing default baud rates between u-boot and kernel, typically u-boot set for 1.5Mbps, and then kernel compiled with something else like 115.2k or 38.4k.

Well, that’s what the kernel command line is for. If somebody could document and/or tell me which kernel config and command line is responsible for the serial console on 5.1+ I’d be grateful.

label kernel-4.4.154-59-rockchip-g5e70f14
    kernel /vmlinuz-4.4.154-59-rockchip-g5e70f14
    devicetreedir /dtbs/4.4.154-59-rockchip-g5e70f14
    append earlyprintk console=ttyFIQ0,1500000n8  video=HDMI-A-1:1920x1080@60 init=/sbin/init root=PARTUUID=b921b045-1d rootwait rootfstype=ext4

As an example extlinux.conf
So uboot is showing but then goes quiet as prob console=ttyFIQ0,1500000n8 is missing
But it should be in journalctl

Yes, of course. That’s kernel 4.4 – this command line works for me. But with my 5.2 RC the kernel is quiet. In fact, I have no /dev/ttyFIC0 (or any other serial device) once it’s up.

# After modifying, run ./mkscr

# MAC address (use spaces instead of colons)
setenv macaddr da 19 c8 7a 6d f4

part uuid ${devtype} ${devnum}:${bootpart} uuid
setenv bootargs console=ttyS2,1500000 root=PARTUUID=${uuid} rw rootwait
setenv fdtfile rockchip/rk3399-rock-pi-4.dtb

if load ${devtype} ${devnum}:${bootpart} ${kernel_addr_r} /boot/Image; then
  if load ${devtype} ${devnum}:${bootpart} ${fdt_addr_r} /boot/dtbs/${fdtfile}; then
    fdt addr ${fdt_addr_r}
    fdt resize
    fdt set /ethernet@fe300000 local-mac-address "[${macaddr}]"
    if load ${devtype} ${devnum}:${bootpart} ${ramdisk_addr_r} /boot/initramfs-linux.img; then
      # This upstream Uboot doesn't support compresses cpio initrd, use kernel option to
      # load initramfs
      setenv bootargs ${bootargs} initrd=${ramdisk_addr_r},20M ramdisk_size=10M
    booti ${kernel_addr_r} - ${fdt_addr_r};

The Manjaro guys compiled mainline and have a serial console, so guess its your compile

Thanks. That creates ttyS0 through S3, but there’s no support for earlyprintk. (Adding that option has no effect.)

Dunno maybe it also has to be in this format earlyprintk=ttyS2,1500000

also is CONFIG_DEBUG_LL and CONFIG_EARLY_PRINTK enabled in the kernel

You might be able to root something out via the elinux site.

Well … no. There is no DEBUG_LL or EARLY_PRINTK in my .config at all, because they’re in arch/arm/Kconfig.debug, not arch/arm64/Kconfig.debug.

Kernel 4.4 did this differently, by replacing the uart2 driver with the fiq_debugger in the uartX-as-console devicetree overlay. Apparently that hasn’t yet been ported to 5.2.

You don’t need to load the console-on-ttyS2.dtbo overlay to get serial console on ttyS2 for mainline kernel. Just put your mainline kernel and mainline dtb to /boot and add the following to extlinux.conf:

label kernel-mainline
kernel /Image
fdt /rk3399-rock-pi-4.dtb
append earlycon=uart8250,mmio32,0xff1a0000 swiotlb=1 coherent_pool=1m earlyprintk console=ttyS2,1500000n8 rw root=PARTUUID=b921b045-1d rootfstype=ext4 init=/sbin/init rootwait

Aaah. That’s the ticket. Thank you! that woks and is very helpful.