Is there a problem with the emmc chips mine on image writes dips and crests but is extremely slow.
Its sometime dips to 3MB/s averages about 7.5MB/s sometimes manages 12MB/s.

Even cheap SD cards manage a faster write than this thing?!
I notice this especially when writing the image and it gets quite warm as it is when removed.

https://github.com/ayufan-rock64/linux-m...118-ayufan

Has Panfrost compiled!! HDMI audio & PCIe!! Ayufan at his industrious usual.

Seems to sit well with https://github.com/ayufan-rock64/linux-b.../tag/0.9.4 

As a test I install the tasksel version of kde-plasma and its rather great with the above 2.
You need to set the network renderer to NatworkManager in the netplan yaml

Also just a slight one but the symlink in /etc/alternatives sets the sddm greeter to moai whilst all the rest is breeze so you might want to change that.
sudo apt-get install sddm-theme-breeze


I have tried gnome and its ok vanila but soon as you theme it, then it starts to get a bit clunky.
Its all opinion though, but think I waiver to criticism than optimism so suggest giving kde-plasma a go.

Burn the image, boot and sudo tasksel and select kde-plasma.
Presuming LXQT will be even more snappy.

I used dd to copy to my integral 120gb £20 nvme and apart from a slow boot in operation its extremely good.

The dts is 

What is the official status of a Manjaro i3 distribution for the Pinebook Pro? Thanks.

So I run The Retro Arena and we are working on the Debian build from mrfixit. I am attempting to add more robust support for more of the modern chipsets that are out there to include N and AC. Even when using N on an AC adapter they seem to produce faster speeds than the older N series adapters. I have tried to installed several adapters, but when it comes to compiling for example many times I run into the following:

Hello,

I just purchased a 4gb Rock64 Rev3 model and i'm struggling in getting any image to boot properly, i tried latest Armbian, mrfixit and ayufan's image. Whenever i plug my power supply (5v 4A) the white, red and ethernet led starts blinking very fast while the green blink slowly. If i plug in and out my power supply it will eventualy boot, but never from the first time. Maybe my board is defective? Anyone else has this issue?

i run a modified KDE Neon Image on EMMC and want to compile some kernel modules
but i`m not sure what files i should get, is the pine64 kernel the same ?

Ayufan`s Repository is listen some versions.

But i`m not sure what i`m running i have 3.10.105-bsp-1.2 from 27 Oct.

I only need to the Source Code Tarball to compile 3G Modem Drivers.

can anyone point me in the right direction ?

Thanks

Matthias

Hello,

I just recently discovered that Lakka is available in the nightlies for the pine allwinner boards.  I tested it on my A64+ and what I tested (NES, SNES, GBA, PSX, DOOM, Quake) worked.  N64 and NDS didn't work. (I didn't have other roms to try).

What also didn't work was HDMI sound, I couldn't test analog out as I broke my headphones.

Here is the link: http://nightly.builds.lakka.tv/Lakka-LE9.2/latest/

Probably most thanks to Jernej as he made this boards available in the libreelec 9.2 build system.

I don't have a pine H64 to test the lakka builds.  And I'm sill wondering wich board would be better, the rock64 or the pineH64 to run emulation on.

Hi everyone,

I have recently registered an account to join the forums and I received no confirmation email at first, I later found it in the spam folder of my gmail account.
The header says:

Quote:Why is this message in spam? It is in violation of Google's recommended email sender guidelines.

Hi Everyone,

I will update this post, which effectively serves as a log, when improvements are made to the default Debian with Mate build by @Mrfixit2001  for the Pinebook Pro. Perhaps this is obvious, but the development for this build is ongoing and continues despite the device not being shipped out yet (at the time of writing).

Please provide all feedback regarding this OS build, and ONLY this OS build, in this thread.

N.B. Once you get your unit make sure to use the update script on first boot [icon next to time/date] to download the new kernel, device tree and various other improvements.
N.B. ii. Perform the initial update on full battery charge. If the battery is partly drained, the update will temporarily cause a faulty battery calibration / software power read. This however is not a permanent issue, and does not cause damage to any components, but it may at take one charge/discharge cycle to correctly re-calibrate.  
[edit 25/11/2019]

Changing Username and Home Directory
Log into root (root/root) and open the termial. To change the username and home directory name type the following, replacing  NewUser with your desired username:

On thing I have been doing on my Linux computers at home for more than 8 years, is use ABEs, (aka Alternate Boot Environments).

Let's say you have a perfectly functional OS load. A few weeks later you want to update. Do you over-write the working OS load? (Even if you have backups...) Or would you prefer to keep your cake, (aka OS load), and eat it too, (update to an alternate location)?

Here is a description of the ABEs possible with Linux. I've actualy used 1, 3 & 4, and tested that 2 works.

 - Separate root partitions. Copy the existing one to the off-line one before update. Boot off the new copy to make sure it's botable, then update. Keep your home partition, (and anything else un-related to the OS), separate from root partition to reduce the amount of duplicated storage. Dis-advantage is that you have to have 2 full root partitions, (like 20GB per root).

 - Use Linux LVM with 2 root partitions. Same as above, but you can also perform R/O snapshots if you leave free space in the volume group.

 - Use BTRFS. Have a separate tree for root. Make R/W snapshots when updating. Still keep non-root / OS data out of the root / OS tree. Each extra BE takes up only as much as had been changed, (it's copy on write).

 - Use ZFS. Have separate tree for root. Make snapshot & clones when updating. Still keep non-root / OS data out of the root / OS tree. Each extra BE takes up only as much as had been changed, (it's copy on write).

This methodology is also good for a new kernel. You may have to update drivers and support software, which if it goes badly, that BE, (aka Boot environment), may become un-bootable. Having an ABE with the old funtional kernel can save you from headaches.

My Grub entries become a bit more complex. Basically at least 1 per BE, and 1 per kernel update. Plus, I have little incentive to delete too many. I generally keep perhaps 5 or 6 BEs. They also act as on-line backup.

If there is interest, I can describe them in more detail. I am most familar with 1 & 4. But have used 3, just not recently.