01-11-2019, 02:21 AM
(This post was last modified: 01-11-2019, 02:22 AM by ali.)
(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.
(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?
PinePhone (BH 2GB + CE 3GB) // RockPro64 4GB (rev. 2.1) - OMV NAS // PineH64 3GB (model B) - off-prem OMV NAS // Pine64-LTS 2GB (rev. 1.2 + Playbox) - Domotics server
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 
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...
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?
02-26-2019, 11:31 AM
(This post was last modified: 02-26-2019, 12:09 PM by mmatyas.)
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 
Greetings,
Matyas
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
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.
(09-10-2019, 01:58 PM)mmatyas Wrote: 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.
My status update:
I compiled kernel from mainline source and it works fine without initrd. Up to v5.1.x boot time is less than 30sec. My rootfs is btrfs with compression.
From v5.2 there is a 60sec stall in booting process but no errors. Alarm "stable" kernel now v5.3.1 hangs with soft lookup:
Code: [ 66.702492] clocksource: Switched to clocksource arch_sys_counter
[ 92.192292] watchdog: BUG: soft lockup - CPU#4 stuck for 22s! [swapper/0:1]
[ 92.193145] Modules linked in:
[ 92.193964] CPU: 4 PID: 1 Comm: swapper/0 Not tainted 5.3.1-1-ARCH #1
[ 92.194612] Hardware name: Pine64 RockPro64 (DT)
[ 92.195311] pstate: 60000005 (nZCv daif -PAN -UAO)
[ 92.196168] pc : trace_event_eval_update+0x2fc/0x330
[ 92.196833] lr : trace_event_eval_update+0x138/0x330
[ 92.197373] sp : ffff00001004bce0
[ 92.197874] x29: ffff00001004bce0 x28: 0000000000000000
[ 92.198677] x27: ffff000011761610 x26: ffff000011836268
[ 92.199395] x25: ffff00001112ba38 x24: 00000000000000e8
[ 92.200089] x23: 0000000000000018 x22: ffff0000116a3310
[ 92.200771] x21: 0000000000000224 x20: 000000000000014d
[ 92.201443] x19: ffff000011822161 x18: 0000000000000001
[ 92.202114] x17: 000000006898f49a x16: 00000000ea2169b9
[ 92.202787] x15: 2d20377b1910031c x14: ff00000000000000
[ 92.203456] x13: 0000000000000001 x12: 0000000000000007
[ 92.204125] x11: 0101010101010101 x10: 0000000000000018
[ 92.204788] x9 : 0000000000000003 x8 : 0000000000000008
[ 92.205459] x7 : 1c0310197b37202d x6 : 2d20377b1910031c
[ 92.206114] x5 : 0000000000000000 x4 : 0000000000000052
[ 92.206760] x3 : 0000000000000002 x2 : ffff00001182214b
[ 92.207410] x1 : 0000000000000010 x0 : 0000000000000000
[ 92.208060] Call trace:
[ 92.208709] trace_event_eval_update+0x2fc/0x330
[ 92.209539] tracer_init_tracefs+0x178/0x214
[ 92.210224] do_one_initcall+0x54/0x220
[ 92.210833] kernel_init_freeable+0x28c/0x334
[ 92.211557] kernel_init+0x18/0x104
[ 92.212185] ret_from_fork+0x10/0x1c
[ 108.631342] VFS: Disk quotas dquot_6.6.0
The final boot time is around 300sec. It is terrible.
I also tried mainline uboot with rkbin git, but rkbin goes crazy and prints unbelivable frequencies (854MHz) under dram init so I falled back to ayufans uboot as latest rkbin made my board unstable and it continously rebooting after some load.
When you say "rkbin" are you referring to Boot Flow 1 (per rockchip terminology)? I've gotten a successful compile with mainline uboot and bl31.elf, which rockchip designates as Boot Flow 2. Booting is under 30sec. There's no instability that I can tell, and I've compiled the kernel on the SBC, as well as run multiple stress tests.
Let me know if that procedure works, I'll try to help if I can.
(09-26-2019, 03:09 PM)oreggin Wrote: (09-10-2019, 01:58 PM)mmatyas Wrote: 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.
My status update:
I compiled kernel from mainline source and it works fine without initrd. Up to v5.1.x boot time is less than 30sec. My rootfs is btrfs with compression.
From v5.2 there is a 60sec stall in booting process but no errors. Alarm "stable" kernel now v5.3.1 hangs with soft lookup:
Code: [ 66.702492] clocksource: Switched to clocksource arch_sys_counter
[ 92.192292] watchdog: BUG: soft lockup - CPU#4 stuck for 22s! [swapper/0:1]
[ 92.193145] Modules linked in:
[ 92.193964] CPU: 4 PID: 1 Comm: swapper/0 Not tainted 5.3.1-1-ARCH #1
[ 92.194612] Hardware name: Pine64 RockPro64 (DT)
[ 92.195311] pstate: 60000005 (nZCv daif -PAN -UAO)
[ 92.196168] pc : trace_event_eval_update+0x2fc/0x330
[ 92.196833] lr : trace_event_eval_update+0x138/0x330
[ 92.197373] sp : ffff00001004bce0
[ 92.197874] x29: ffff00001004bce0 x28: 0000000000000000
[ 92.198677] x27: ffff000011761610 x26: ffff000011836268
[ 92.199395] x25: ffff00001112ba38 x24: 00000000000000e8
[ 92.200089] x23: 0000000000000018 x22: ffff0000116a3310
[ 92.200771] x21: 0000000000000224 x20: 000000000000014d
[ 92.201443] x19: ffff000011822161 x18: 0000000000000001
[ 92.202114] x17: 000000006898f49a x16: 00000000ea2169b9
[ 92.202787] x15: 2d20377b1910031c x14: ff00000000000000
[ 92.203456] x13: 0000000000000001 x12: 0000000000000007
[ 92.204125] x11: 0101010101010101 x10: 0000000000000018
[ 92.204788] x9 : 0000000000000003 x8 : 0000000000000008
[ 92.205459] x7 : 1c0310197b37202d x6 : 2d20377b1910031c
[ 92.206114] x5 : 0000000000000000 x4 : 0000000000000052
[ 92.206760] x3 : 0000000000000002 x2 : ffff00001182214b
[ 92.207410] x1 : 0000000000000010 x0 : 0000000000000000
[ 92.208060] Call trace:
[ 92.208709] trace_event_eval_update+0x2fc/0x330
[ 92.209539] tracer_init_tracefs+0x178/0x214
[ 92.210224] do_one_initcall+0x54/0x220
[ 92.210833] kernel_init_freeable+0x28c/0x334
[ 92.211557] kernel_init+0x18/0x104
[ 92.212185] ret_from_fork+0x10/0x1c
[ 108.631342] VFS: Disk quotas dquot_6.6.0
The final boot time is around 300sec. It is terrible.
I also tried mainline uboot with rkbin git, but rkbin goes crazy and prints unbelivable frequencies (854MHz) under dram init so I falled back to ayufans uboot as latest rkbin made my board unstable and it continously rebooting after some load.
This is a workaround: https://github.com/heiher/linux/commit/0...ce24d03dba
Hi guys, sorry for interrupting the flow of this thread but I have a few questions.
I am looking into getting a RockPro64 and would like to put ArchLinuxArm on it. Is this easy to do in the current state of development?
Also, I have never heard of a Mali GPU before but I would like to know whether it would work with SwayWM and whether or not HW acceleration works.
How much of the hardware is supported? From the look of things it seems to be getting better with every kernel release?
Also, a more general question, but would I be able to boot off of an SSD in the PCI slot?
|
