| Welcome, Guest |
You have to register before you can post on our site.
|
| Latest Threads |
Rock64 v2.0 u-boot SPI is...
Forum: General Discussion on ROCK64
Last Post: ju0n
3 hours ago
» Replies: 0
» Views: 25
|
Libby - ebook reader that...
Forum: PineNote Software
Last Post: kiwigoldfish
Yesterday, 04:41 PM
» Replies: 6
» Views: 4,005
|
Pinephone software
Forum: General Discussion on PinePhone
Last Post: Csanderson0313
Yesterday, 08:23 AM
» Replies: 0
» Views: 69
|
PineNote v1.2 - Charges N...
Forum: General Discussion on Pinebook Pro
Last Post: ttsp
07-02-2026, 02:52 AM
» Replies: 0
» Views: 173
|
How to change the PineNot...
Forum: General Discussion on PineNote
Last Post: cameronharring
07-01-2026, 12:22 PM
» Replies: 0
» Views: 84
|
PinePhone Pro disable Vol...
Forum: PinePhone Pro Hardware
Last Post: FR_IV
07-01-2026, 10:53 AM
» Replies: 1
» Views: 1,557
|
Star64/Starpro64 kernel b...
Forum: General
Last Post: tgbgreen
06-30-2026, 12:17 PM
» Replies: 1
» Views: 2,179
|
Manjaro affected by Arch ...
Forum: General
Last Post: tantamount
06-28-2026, 10:45 AM
» Replies: 0
» Views: 240
|
Fix Bricked SPI Flash, Pi...
Forum: PinePhone Pro Hardware
Last Post: FR_IV
06-27-2026, 05:00 PM
» Replies: 0
» Views: 167
|
irradium (based on crux l...
Forum: Linux on RockPro64
Last Post: mara
06-27-2026, 04:09 PM
» Replies: 12
» Views: 19,653
|
|
|
| USB Storage |
|
Posted by: ipollox - 11-14-2018, 01:10 PM - Forum: General Discussion on ROCKPRO64
- Replies (1)
|
 |
Hi,
I just got my ROCKPro64 in the mail yesterday, and now I just noticed I accidentally removed the eMMc module from the purchase, is there a way I can use an USB Flash drive to boot it up, or a place to buy the modules and get it quick? My purchase topic 3 weeks to get to my door, is there anything else I can do?
|
|
|
|
| Pinebook 11.6" 1080P Performance |
|
Posted by: jschall - 11-14-2018, 10:19 AM - Forum: General Discussion on Pinebook
- Replies (3)
|
 |
I am very disappointed in the performance of my brand-new Pinebook.
I am only talking about the Web browser (Chromium), which takes a full second to display each character I'm typing here!
Typing in the terminal and in Kate is acceptably snappy.
Does anybody else notice this sluggishness?
Oh, and videos on Youtube are sluggish too, but of course I'm viewing Youtube in a Chromium window.
|
|
|
|
| 1080p mainline kernel issues |
|
Posted by: e-minguez - 11-14-2018, 08:37 AM - Forum: General Discussion on Pinebook
- Replies (2)
|
 |
Hi folks,
It seems some of us are having issues with mainline kernel images.
I personally have tried anarsoul's arch xfce, AOSC and Manjaro and none of them boots. The screen is completely blank (I'd say it is powered on but nothing on the screen). I don't have the headphones serial adapter but I've tried to connect an USB ethernet adapter and after ~30 minutes since booted, no activity.
I've tested with etcher and dd just in case but same result. Same microsd boots fine with BSP images (such as Q4OS or ayufan's bionic mate).
Thanks.
|
|
|
|
| French keyboard |
|
Posted by: jschall - 11-14-2018, 08:32 AM - Forum: General Discussion on Pinebook
- Replies (1)
|
 |
I can't get all the French accent characters from the keyboard.
I'm on the Pinebook 11.6" 1080P, running Q4OS.
I have added the French (Canada) keyboard selector, and I can get these keys:
éêçäâôöÉ
But that's all. I can't get e or accent grâve, for example.
Is there any way to edit the keyboard layout to add the missing accent keys?
|
|
|
|
| HOW TO - compile a kernel. HOW TO - overclock |
|
Posted by: dukla2000 - 11-14-2018, 04:20 AM - Forum: RockPro64 Projects, Ideas and Tutorials
- No Replies
|
 |
Figure worth trying to make a single collection of the bits to compile a new kernel for your RockPro64. On your RockPro64.
And what could be better motivation than to overclock your RockPro64?
As always the warranty for these instructions is - if you break it you own both parts.
And, as always on Linux, there are a million ways to do this. My steps below are just 1 way that works for me, I don't claim any particular benefit over any other way.
To cause an argument let me assume the starting point is an Ayufan 0.7.9 image on an SDcard in your RockPro64. And that you want to get the current 4.19 kernel running with a 2.1GHz max speed for your A72 cores.
First observation: the way Ayufan has set things up you will be able to toggle between the 4.4.x kernel in his 0.7.9 image and your 4.19 image as long as you can edit a text file on your SDcard on another Linux PC so you should not "brick" anything.
Second observation - everything below you can search www and find other pages/advice/embellishments if you want.
1) Create a working directory: if you start a terminal session (Open a terminal using your menu system - probably under system tools) you are most likely to be the user rock64 in your home directory (which is /home/rock64/). If you type
you will create a new subdirectory called bin.
2) Download some Linux source code. As per the assumptions the simplest way to do this is to go to Ayufan mainline github page and click the big green "clone or download" button and select the "download zip" option at the bottom. Save the file to the bin directory you created in step 1.
3) We need to install some software - p7zip to unzip the file you just downloaded as well as some prerequisites to get the compile and build environment to work. I hope the following is complete - if you get any errors in later steps it will be most likely because of something missing here! First we are going to update/upgrade all the software you already have, then we will install the new stuff. type (or copy/paste) the following 4 lines 1 at a time - enter your password (possibly still rock64?) when asked after the first line:
Code: sudo apt-get update
sudo apt-get upgrade
sudo apt-get install p7zip
sudo apt-get install build-essential libncurses-dev bison flex libssl-dev fakeroot pkg-config
4) OK - assuming you still have your terminal window open type
The ls command lists the files in the current directory - you should see linux-mainline-kernel-master.zip from step 2. Type
Code: unzip linux-mainline-kernel-master.zip
and you should have a couple of minutes of excitement while all the source files are unzipped.
5) Still at your terminal type
Code: cd linux-mainline-kernel-master
cp arch/arm64/configs/rockchip_linux_defconfig .config
The second command copied a skeleton Rockchip config file to your config file (that happens to be a hidden file which is why it has a . in front of the filename!) This is where there is a huge amount of room for alchemy: the contents of your config file determine the capabilities of your new kernel. Quite frankly for your first compile that is all pretty irrelevant - I just wanted to compile a kernel and get it to load and so that is all these instructions try to do. You can always come back later and "improve" your config file: beware there are numerous parameters, most of which can cause your kernel to be useless if you get them wrong. So take playing options in your config file slowly. If you come back later to this step make menuconfig is the way I play with mine! As we copied a skeleton config file you will need to beef it up with default values - the easy way to do this is
and just do a Save (to .config) then exit.
6) To fix things for the overclock there are a couple of device tree files we need to edit.
To setup any overclock edit ~/bin/4.19/linux-mainline-kernel-master/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dts
about line 20 change the include to be
#include "rk3399-op1-opp.dtsi" {it was "rk3399-opp.dtsi"}
Code: nano ~/bin/4.19/linux-mainline-kernel-master/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dts
then edit ~/bin/4.19/linux-mainline-kernel-master/arch/arm64/boot/dts/rockchip/rk3399-op1-opp.dtsi
you will see at the top the cluster0 clock definitions for the A53 (up to 1512 - the rk3399-opp.dtsi file has max 1400) followed by the cluster1 definitions for the A72s. I just amend the 2016/last entry to be 2108, leave the voltage at 1.25V (1250000) works fine for me
Code: nano ~/bin/4.19/linux-mainline-kernel-master/arch/arm64/boot/dts/rockchip/rk3399-op1-opp.dtsi
7) To kick off your kernel compile type
And go for lunch. First time I typed this on my RockPro64 it took about 55 minutes (and I have decent cooling so no thermal throttling, and a rather fast NVMe drive - if you really are on an SDcard it will be much worse!) Now it takes me just under 25 minutes - it is some help I am running at 2.1/1.5GHz, also the first change I would recommend to your config file is to disable debug_info which disables the building of all the debug options and saves a huge amount of compile time.
8) When your compile has finished, type
Code: cd ..
sudo dpkg -i inux-image-4.19.0_4.19.0-2_arm64.deb
reboot
And if by a miracle all went well you will install your new kernel, your machine will reboot and load the new kernel!
Not only that but the overclock should be there:
Code: $ cat /sys/devices/system/cpu/cpu4/cpufreq/scaling_available_frequencies
408000 600000 816000 1008000 1200000 1416000 1608000 1800000 2108000
Now, if something goes wrong or you want to revert to your 4.4 kernel for whatever reason simply edit your /boot/extconfig/extconfig.conf file and set a default - my current file is below, the default line is what you have to add. The names of the labels can be freely abbreviated from what you find - just make sure whatever you put on line 1 matches a later label in the file. Otherwise the first label becomes the actual default!
Code: timeout 10
menu title select kernel
default kernel-4.19.0
label kernel-4.19.0-1073-ayufan-ga6e013135a6e
kernel /boot/vmlinuz-4.19.0-1073-ayufan-ga6e013135a6e
initrd /boot/initrd.img-4.19.0-1073-ayufan-ga6e013135a6e
devicetreedir /boot/dtbs/4.19.0-1073-ayufan-ga6e013135a6e
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=MySM961 rootwait rootfstype=ext4
label kernel-4.19.0
kernel /boot/vmlinuz-4.19.0
initrd /boot/initrd.img-4.19.0
devicetreedir /boot/dtbs/4.19.0
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=MySM961 rootwait rootfstype=ext4
label kernel-4.4.138-1100-rockchip-ayufan-g95cecee47f40
kernel /boot/vmlinuz-4.4.138-1100-rockchip-ayufan-g95cecee47f40
initrd /boot/initrd.img-4.4.138-1100-rockchip-ayufan-g95cecee47f40
devicetreedir /boot/dtbs/4.4.138-1100-rockchip-ayufan-g95cecee47f40
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=MySM961 rootwait rootfstype=ext4
Have fun.
|
|
|
|
| HW image transitions in Python |
|
Posted by: gaggleoxfoggy - 11-14-2018, 12:36 AM - Forum: General Discussion on ROCK64
- Replies (7)
|
 |
Working on Rock64/Debian Stretch and trying to crossfade two images. I've tried Pygame, Kivy, and just basic SDL, but it seems like none of these are able to do anything other than SW mode. Is there a way of making them use HW or some other method of displaying images through Python where I'd be able to get a smooth realtime transition?
|
|
|
|
| RockPro64 as PVR/DVR |
|
Posted by: bm_00 - 11-13-2018, 06:33 PM - Forum: RockPro64 Projects, Ideas and Tutorials
- Replies (1)
|
 |
I was looking at building a dvr to record tv useing a tv tuner. I came across the rockpro 64 and am impressed. I am wondering if it is a good idea to use the rockpro for this task. I would preforably be useing the Hauppauge 1265 PCIE tuner but am afraid the rockpro might not support it. If not what about the usb Hauppauge 955Q tuner? Has anyone done a similar project to this?
|
|
|
|
| KDE Neon problems persisting (1080) |
|
Posted by: ImmortanJoe - 11-13-2018, 04:18 PM - Forum: Linux on Pinebook
- Replies (8)
|
 |
I'm having some problems with the install of KDE Neon which I probably shouldn't be.
Although I followed the day zero fixes thread, and linked other thread, it still likes to go into the black screen death sleep. Sometimes it actually needs a hard reboot to get the display back. Sleep and resume doesn't always do it.
Graphics acceleration of any type seems to be broken. SMPlayer with it's configured video type of "gpu" doesn't render properly. It renders some of the top of the video frames then it kind of explodes into the framebuffer filling the whole width of the screen with what I assume to be the video frame with the lines end to end. After that is the rest of the screen, further down and offset.
I tried building an SDL program that I use. When running one of it's executables it told me something interesting.
Code: MESA-LOADER: failed to retrieve device information
libGL error: unable to load driver: sunxi_dri.so
libGL error: driver pointer missing
libGL error: failed to load driver: sunxi
That's not great. why is sunxi_dri not working?
Should I just cut my losses and re-image, or is it an easy fix?
|
|
|
|
|