Arch Linux on RockPro64

[mmatyas]

Yeah, that's what I was looking for! I did also quickly adapt the PKGBUILD, so that works. Even better if that stuff finds it's way into mainline, so that I can just use the arch linux kernel.

I'm still having some problems with compiling U-Boot under Arch Linux as it throws useless warnings about syntax errors, may it be the case that the GCC toolchain in Arch is just a bit too new for the U-Boot version used? I'm just a little bit annoyed, that these errors are consistent amongst all my arch machines but do not appear under Ubuntu.

Hey, I did the same and installed Arch by modifying one of the Ubuntu images. It doesn't seem too far off to have a straight up Arch port, I think the only bit that's actually left over from the Ubuntu image now is u-boot.

It runs nicely with the default 4.4 ayufan kernel that came with Ubuntu. Surprisingly the 4.18.5 arch mainline kernel came up and even had ethernet, but a bunch of other hardware didn't work, I guess partially due to the missing dtb, partially due to patches not yet in mainline.

Right now I'm running the ayufan 4.18.0-rc8, compiled via https://github.com/ah-/PKGBUILDs (https://github.com/ah-/PKGBUILDs/commit/...bb9839edd0), see core/linux-rockpro64 and just run makepkg in there. After installing the packages you'll need to add the kernel to extlinux.conf:

label arch
   kernel /boot/Image
   initrd /boot/initramfs-linux.img
   devicetreedir /boot/dtbs
   append rw panic=10 init=/sbin/init coherent_pool=1M ethaddr=${ethaddr} eth1addr=${eth1addr} serial=${serial#} cgroup_enable=cpuset cgroup_memory=1 cgroup_enable=memory swapaccount=1 root=LABEL=linux-root rootwait rootfstype=ext4

With that it runs really nicely as a server, it's fast and all the hardware I'm using works, including pcie sata.

The HDMI port works somewhat, I get an image but the UI is really slow, I don't get full resolution and the image is quite noisy. I suspect this might be due to me not having any userland installed for the GPU, does anyone know what the Mali GPU needs and how t get it onto Arch?

[ali]

Code:

libmali-rk-midgard-t86x-r14p0-gbm

?

Just gave that a go, via https://github.com/apokalypzx/gru-libgl but getting

Code:

[11:55:33.702] Failed to load module: /usr/lib/libweston-5/drm-backend.so: undefined symbol: gbm_bo_get_offset

when trying to start Weston. Searching hasn't really yielded anything yet, but haven't looked for long.

Does anyone know where to get up to date userspace binaries? r14 is about half a year old, and the kernel pieces at https://developer.arm.com/products/softw...ard-kernel are now at r26. However, I can't find r26 binaries anywhere.

Me too. I can't start weston complaining about gbm.

[mmatyas]

Hey,

I used the PKGBUILD for the Rock64 from the ArchLinuxARM github Repo and created a PKGBUILD to compile Ayufan's Mainline kernel for Arch Linux ARM:

https://github.com/matyas1995/linux-aarch64-rockpro64

Don't forget to adjust your /boot/extlinux/extlinux.conf after installation, as the image names and the location of the dtbs will have changed:

Code:

label arch
   kernel /boot/Image
   initrd /boot/initramfs-linux.img
   devicetreedir /boot/dtbs
   append rw panic=10 init=/sbin/init coherent_pool=1M ethaddr=${ethaddr} eth1addr=${eth1addr} serial=${serial#} cgroup_enable=cpuset cgroup_memory=1 cgroup_enable=memory swapaccount=1 root=LABEL=linux-root rootwait rootfstype=ext4

[p1x3l3d]

Hey matyas and ah-,

Thanks for all the efforts and for sharing your findings! Despite having almost no knowledge about fiddling with kernels and such, your success stories encouraged me to try to get Arch running on my RockPro64 as well, and it worked!

In case others want to try, here is what I did:
- download latest stretch-minimal image from ayufan's release page and extract it
- dd the extracted image file to my SD-card. This resulted in 2 partitions on the SD-card, 'boot' and 'linux-root'.
- download latest alarm image (http://os.archlinuxarm.org/os/ArchLinuxA...est.tar.gz) and extract it
- overwrite everything on the 'linux-root' partition except the boot/ directory with the contents of the extracted alarm image (except the boot/ directory in there, as well). I went wrong a couple of times here, mistaking the 'boot' partition for the boot/ directory, and overwriting the entire 'linux-root' partition anyway.

Again, thanks matyas for your description of 'dirty' installing Arch ARM this way

Right now I'm running the ayufan 4.18.0-rc8, compiled via https://github.com/ah-/PKGBUILDs (https://github.com/ah-/PKGBUILDs/commit/...bb9839edd0), see core/linux-rockpro64 and just run makepkg in there.

ah-, could you share where you got 4.18.0-rc8 from? I can't seem to find it neither in ayufan's linux-kernel repo, nor in his linux-mainline-kernel repo. Also, could you briefly describe how I would go about building it into a usable/install-able kernel if it's not too much to ask?

Thanks!

Cheers,
Thomas

[mmatyas]

ah-, could you share where you got 4.18.0-rc8 from? I can't seem to find it neither in ayufan's linux-kernel repo, nor in his linux-mainline-kernel repo. Also, could you briefly describe how I would go about building it into a usable/install-able kernel if it's not too much to ask?

When you look into his PKGBUILD in his sources, you can find the link to the linux kernel resources he used to get the kernel sources from. Otherwise, you can also look into the linux-mainline-kernel repo of ayufan, under the tab 'Releases' you can also find his releases. ah- as well as myself use these resources to compile our kernels (even though I already upgraded to the 4.19 release).

You can look into the PKGBUILD file ah- created, you can also look into my repo (you'll find the link in the post above yours). Basically, you need to check out the git repository, install the base-devel package on your rockpro and then type 'makepkg' in the root of the downloaded sources. This will create a linux-aarch64.....tar.xz package that you can then install with 'pacman -U linux-aarch64.....tar.xz'

Alternatively, you can read the PKGBUILD file to see what is being done to compile the kernel (mine and ah- are identical in that aspect as we both used the same resources to create our packages). I also recommend you to read the article about creating packages in the arch wiki to better understand what is being done.

Hope that helps,
Matyas

PS: before you compile the kernel, make sure you edit the file /etc/makepkg.conf and uncomment the line

Code:

#MAKEFLAGS="-j5"

. You should also change the flag -j5 to -j7. This will tell your compiler to use all cores on your rockpro instead of just one, which will reduce the kernel compiling time from about 6 hours to about 1.

PPS: If I can give you a tip, do not compile a kernel on your SD card, use an external HDD or SSD instead. Most SD cards are not made to endure the write load that linux generates while compiling a kernel or using swap and will kill the card after a couple of weeks of heavy use.

[p1x3l3d]

Thanks for the extensive answer mmatyas

The tip about not building the kernel on the SD card directly is especially useful since I was about to do just this Coincidentally I ordered a eMMC storage chip earlier so I'll wait for that to arrive before I start experimenting any further with the building. When I've done so I'll give feedback here. Until then good luck with all the advancements yourself!

[ali]

Hey,

I used the PKGBUILD for the Rock64 from the ArchLinuxARM github Repo and created a PKGBUILD to compile Ayufan's Mainline kernel for Arch Linux ARM:

https://github.com/matyas1995/linux-aarch64-rockpro64

Don't forget to adjust your /boot/extlinux/extlinux.conf after installation, as the image names and the location of the dtbs will have changed:

Code:

label arch
   kernel /boot/Image
   initrd /boot/initramfs-linux.img
   devicetreedir /boot/dtbs
   append rw panic=10 init=/sbin/init coherent_pool=1M ethaddr=${ethaddr} eth1addr=${eth1addr} serial=${serial#} cgroup_enable=cpuset cgroup_memory=1 cgroup_enable=memory swapaccount=1 root=LABEL=linux-root rootwait rootfstype=ext4

Does the graphics (X or wayland) use hardware acceleration?

[mmatyas]

I use my RockPro as a headless server. HDMI works, but I have not tried any graphics. It should be possible to do that, other guys did plenty of work on that already.

[ali]

I use my RockPro as a headless server. HDMI works, but I have not tried any graphics. It should be possible to do that, other guys did plenty of work on that already.

Last time I tried, there was no hardware acceleration. It was really slow just to click any button on the desktop environment.

[fosf0r]

No available images are properly set up for acceleration from the jump, but that can be fixed.


If you install libmali-rk-midgard-t86x-r14p0-gbm and then build and install fbturbo, you can have accelerated X11.
https://github.com/ssvb/xf86-video-fbturbo

Reminder: rockpro64 cannot do hardware GL, but GLES2 will be accelerated.
Software GL and hardware acceleration conflict, so you can't have MESA GL (software) plus accelerated GLES (libmali-rk) at the same time (that I know of. I've been trying, so if I'm wrong, please correct!)

xscreensavers will be unaccelerated, for example, but you can run Kodi if build for GBM+GLES.
But Kodi is better without X11 at all, when run from framebuffer in GBM mode.
It suffers performance a lot if you launch from within X11.


If you use fbturbo, and your window manager supports compositing and/or some form of acceleration, TURN IT ALL OFF.
For example, XFCE has software compositing, but that is unaccelerated by fbturbo, so things actually go faster once you disable it.
Counter-intuitively, if any programs (example: SMplayer) ask you what surface to render to, choose "x11 slow", NOT any of the options that would seem like they have acceleration.
(Also, "drm" and "GBM" can be appropriate choices as well depending on the context of the question and the program that is asking.)
If you go this route you may also want to disable all hardware acceleration inside of your web browser (Chromium, Firefox, etc) as well, since those are counter-intuitive as well. When I disabled as much hardware accel as I could in Chromium, it started functioning even more responsively.




If you want Wayland and Weston, you must install libmali-rk-midgard-t86x-r14p0-wayland
Weston on Wayland with this driver is 100% accelerated and composited.
I'm not 100% sure if having the libmali-rk-*-wayland package is allowed at the same time as the GBM one, I have not tried using both systems at the same time before (X11 and Wayland).