Arch Linux on RockPro64
#21
(12-03-2018, 09:59 AM)fosf0r Wrote: 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).

Thank you! I'll try it.
  Reply
#22
(11-24-2018, 04:09 AM)mmatyas Wrote: 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.

...

Finally got around to trying my hand at compiling a kernel and installing it. This worked, but (after an afternoon of trying) I never got the kernel to work.

What I did was the following:
- clone your repo (https://github.com/matyas1995/linux-aarch64-rockpro64),
- update the 'PKGBUILD' and 'linux-rockpro64.install' files to fetch and build the latest release (4.20.0-1083, commit),
- run 'makepkg', answer 'y' and 'n' to the inclusion of some modules (following the suggested answers mostly) and wait for approx 1h for the compiling to finish (also applied your tip of setting MAKEFLAGS to "-j7"),
- install the newly made package ('pacman -U linux-rockpro64-4.20.0-1083-aarch64.pkg.tar.xz'),
- and finally, change '/boot/extlinux/extlinux.conf' to:
Code:
cat /boot/extlinux/extlinux.conf.new
timeout 10
default arch
menu title select kernel

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

After that I rebooted the system. Sadly it did not come up anymore. To see what was happening I attached the rockpro directly to my laptop through GPIO>USB with a serial console and watched the startup messages scroll by. I think the following bit is interesting:
Code:
...
...
[    2.973624] RAMDISK: Couldn't find valid RAM disk image starting at 0.
[    2.974239] Waiting for root device LABEL=linux-root...
... end then it basically stops.

It complains that it can't find the RAMDISK. This is odd, because in the beginning of the startup progress, before attempting to start the kernel, it states this:
Code:
switch to partitions #0, OK
mmc0(part 0) is current device
Scanning mmc 0:7...
Found /boot/extlinux/extlinux.conf
Retrieving file: /boot/extlinux/extlinux.conf
379 bytes read in 112 ms (2.9 KiB/s)
select kernel
1:      arch
Enter choice: 1:        arch
Retrieving file: /boot/initramfs-linux.img
5685385 bytes read in 303 ms (17.9 MiB/s)
Retrieving file: /boot/Image
32614912 bytes read in 1484 ms (21 MiB/s)
append: rw panic=10 init=/sbin/init coherent_pool=1M ethaddr=xxx eth1addr= serial=xxx cgroup_enable=cpuset cgroup_memory=1 cgroup_enable=memory swapaccount=1 root=LABEL=linux-root rootwait rootfstype=ext4
Retrieving file: /boot/dtbs/rockchip/rk3399-rockpro64.dtb
55324 bytes read in 269 ms (200.2 KiB/s)
## Flattened Device Tree blob at 01f00000
   Booting using the fdt blob at 0x1f00000
   Loading Ramdisk to f5997000, end f5f03089 ... OK
   Loading Device Tree to 00000000f5986000, end 00000000f599681b ... OK

Also, the message right after, Waiting for root device LABEL=linux-root..., is odd because this is still partition 6, which still has the right label (I double checked by running 'blkid').

So it seems as if it correctly finds and reads the extlinux config, finds the images, and loads them into memory; and then seems to forget about it later during the actual booting of the kernel.

Does anyone have any idea what I'm doing wrong?
[RockPro64 4GB (rev. 2.1) - Server + NAS]     [PineH64 3GB (model B)]     [Pine64-LTS 2GB (rev. 1.2)]
  Reply
#23
Hello,

It would be helpful if you could post the entire boot log and not just the parts that you think might be interesting. The devil is in the details Wink

I am currently on holiday and thus did not play with linux 4.20 yet, I'll give it a try when I get back home.

Here is my wild guess just by reading your post: Am I right that you are running arch linux from an MMC instead of an SD card? Maybe your boot loader is looking at the wrong place for you files. Also, did you really rename /boot/extlinux/extlinux.conf to /boot/extlinux/extlinux.conf.new ? Your bootloader then might still be looking at the wrong extlinux file to get boot parameters from.

Greetings,
Matyas

(01-13-2019, 12:41 PM)p1x3l3d Wrote:
(11-24-2018, 04:09 AM)mmatyas Wrote: 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.

...

Finally got around to trying my hand at compiling a kernel and installing it. This worked, but (after an afternoon of trying) I never got the kernel to work.

What I did was the following:
- clone your repo (https://github.com/matyas1995/linux-aarch64-rockpro64),
- update the 'PKGBUILD' and 'linux-rockpro64.install' files to fetch and build the latest release (4.20.0-1083, commit),
- run 'makepkg', answer 'y' and 'n' to the inclusion of some modules (following the suggested answers mostly) and wait for approx 1h for the compiling to finish (also applied your tip of setting MAKEFLAGS to "-j7"),
- install the newly made package ('pacman -U linux-rockpro64-4.20.0-1083-aarch64.pkg.tar.xz'),
- and finally, change '/boot/extlinux/extlinux.conf' to:
Code:
cat /boot/extlinux/extlinux.conf.new
timeout 10
default arch
menu title select kernel

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

After that I rebooted the system. Sadly it did not come up anymore. To see what was happening I attached the rockpro directly to my laptop through GPIO>USB with a serial console and watched the startup messages scroll by. I think the following bit is interesting:
Code:
...
...
[    2.973624] RAMDISK: Couldn't find valid RAM disk image starting at 0.
[    2.974239] Waiting for root device LABEL=linux-root...
... end then it basically stops.

It complains that it can't find the RAMDISK. This is odd, because in the beginning of the startup progress, before attempting to start the kernel, it states this:
Code:
switch to partitions #0, OK
mmc0(part 0) is current device
Scanning mmc 0:7...
Found /boot/extlinux/extlinux.conf
Retrieving file: /boot/extlinux/extlinux.conf
379 bytes read in 112 ms (2.9 KiB/s)
select kernel
1:      arch
Enter choice: 1:        arch
Retrieving file: /boot/initramfs-linux.img
5685385 bytes read in 303 ms (17.9 MiB/s)
Retrieving file: /boot/Image
32614912 bytes read in 1484 ms (21 MiB/s)
append: rw panic=10 init=/sbin/init coherent_pool=1M ethaddr=xxx eth1addr= serial=xxx cgroup_enable=cpuset cgroup_memory=1 cgroup_enable=memory swapaccount=1 root=LABEL=linux-root rootwait rootfstype=ext4
Retrieving file: /boot/dtbs/rockchip/rk3399-rockpro64.dtb
55324 bytes read in 269 ms (200.2 KiB/s)
## Flattened Device Tree blob at 01f00000
  Booting using the fdt blob at 0x1f00000
  Loading Ramdisk to f5997000, end f5f03089 ... OK
  Loading Device Tree to 00000000f5986000, end 00000000f599681b ... OK

Also, the message right after, Waiting for root device LABEL=linux-root..., is odd because this is still partition 6, which still has the right label (I double checked by running 'blkid').

So it seems as if it correctly finds and reads the extlinux config, finds the images, and loads them into memory; and then seems to forget about it later during the actual booting of the kernel.

Does anyone have any idea what I'm doing wrong?
  Reply
#24
Soo, I finally got time to dive into this again...

I also tried compiling not just Ayufan's kernel, but failed. I also tried to compile mainline Linux 4.20 kernel from Torvalds, same result. By the way, The RockPro64 device tree got into mainline in September 2018... So theoretically we would be able to compile Linux Images from Mainline Linux, or even just take the official ArchLinuxARM kernel.

When I extract the ramdisk + kernel + dtb from Ayufan's .deb packages and Place them into /boot (like I described in the start of the thread), the board suddenly boots.

That the board hangs on 'Waiting for root device LABEL=linux-root' is normal, because the file system drivers are all in the initramfs. So, broken initramfs means no file system drivers means no bootpartition and thus no boot.

Interestingly, in my frustration I tried to just not define any initramfs in extlinux.conf, and still got to 'Waiting for root device LABEL=linux-root'. So, this just gave me an idea: Before I start digging through tons of code and the mkinitpio procedure, why not just statically tell linux to compile filesystem, pcie, raid etc. drivers into the Image and just boot without an initramfs altogether? Any thoughts on where that might go wrong?
First Problem: I have my rootfs on an LVM partition, which needs userspace tools... great Sad

Greetings,
Matyas
  Reply
#25
Problem solved!

@p1x3l3d it looks like that something has changed in the kernel sources that made some Platforms mess up code for the RockPro64. After all the frustration, deactivating all platforms except for Rockchip in the kernel config was all (that I can remember) it took to make the packages work again. Check out my Github, I already uploaded everything I did.

Also, if anybody is playing with their boards like me, it is not a bad idea to make a copy of your last working kernel image, initramfs and the dtb folder before you try a new kernel version. This way, in case of a failure, you can just edit the extlinux config on your computer to point to the saved copies to boot up a running system to try again.

Greetings,
Matyas
  Reply
#26
Well,

development in the mainline Linux kernel has advanced quite far, so there is a device tree supporting the RockPro64 in mainline Linux. With 5.3-rc7, the PCIe is also working, so I just installed the linux-aarch64-rc package from archlinuxarm and my rockpro runs flawlessly since then. Booting still takes couple of minutes longer than with Ayufans images.
  Reply


Possibly Related Threads...
Thread Author Replies Views Last Post
  Linux distro that will work with Kodi? SBCraok 9 159 5 hours ago
Last Post: mtrcycllvr
  RockPro64 - Armbian no sound from jack Pineapple 0 33 09-16-2019, 08:27 AM
Last Post: Pineapple
  PCIe ath10k on RockPro64 dasfranky 5 147 08-31-2019, 11:36 AM
Last Post: tuxd3v
  RockPro64 Official Kernel Support ASIC 23 3,382 08-29-2019, 05:39 PM
Last Post: tuxd3v
  DietPi for the RockPro64 Luke 12 3,792 08-29-2019, 04:07 AM
Last Post: hexxx
  rockpro64 and wayland - missing files Mentaluproar 1 104 08-14-2019, 07:51 PM
Last Post: hmuller
Big Grin RETRO GAMING: UPDATED RECALBOX FOR THE RK3399 ROCKPRO64 Mrfixit2001 27 3,125 08-13-2019, 12:08 PM
Last Post: pimseb
  Chromium OS for the RockPro64 is now available! Luke 6 663 08-12-2019, 12:12 PM
Last Post: stuartiannaylor
  How to configure optee_os to build for rockpro64 yakman2020 2 301 07-29-2019, 04:31 AM
Last Post: skumar
  u-boot for Arch Linux Arm prw 3 167 07-20-2019, 12:38 PM
Last Post: stuartiannaylor

Forum Jump:


Users browsing this thread: 1 Guest(s)