i have used now for some year armbian for this board,

very many thanks for that;

lately have updated to newer version Debian Trxiie

and found that "htop" report a higher CPU usage after freshboot (around 50%) whereas previously it sat a 10% probably;

now when evoking htop it gives (CPU offline for core 2-3-4)

also nproc report "1" instead of "4"=?

not sure if this an error ; 

noticed a similar report of nproc also with a build of volumio;

thank you very much;

$ dmesg | grep mipi
[   10.113223] sun6i-mipi-dsi 1ca0000.dsi: Attached device fy07024di26a30d

$ lsmod | grep fy0702*
panel_feiyang_fy07024di26a30d    12288  0

Please can anyone say where should I continue checking?

BR

I can see wifi card but bt is not working

Please help me to make this bt module working

$ sudo rfkill list
0: phy0: Wireless LAN
        Soft blocked: no
        Hard blocked: no
$

Uploading backup, this can take a while. Please wait... Restoring from backup... Unpacking backup to /tmp/tmpf_d22xwu...Removing temporary unpacked folderError while running restoreTraceback (most recent call last):  File "/home/ageoffri/OctoPrint/lib/python3.12/site-packages/octoprint/plugins/backup/__init__.py", line 1243, in _restore_backup
    zip.extract(member, temp)  File "/usr/lib/python3.12/zipfile/__init__.py", line 1726, in extract
    return self._extract_member(member, path, pwd)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^  File "/usr/lib/python3.12/zipfile/__init__.py", line 1802, in _extract_member
    shutil.copyfileobj(source, target)  File "/usr/lib/python3.12/shutil.py", line 204, in copyfileobj
    fdst_write(buf)OSError: [Errno 28] No space left on device Restore failed! Chec

And here's the df -m :
 

Filesystem 1M-blocks Used Available Use% Mounted on
tmpfs 198 4 195 2% /run
/dev/mmcblk0p1 59861 3078 56137 6% /
tmpfs 988 1 988 1% /dev/shm
tmpfs 5 0 5 0% /run/lock
tmpfs 988 0 988 0% /tmp
/dev/zram1 47 3 41 6% /var/log
tmpfs 198 1 198 1% /run/user/1000

sudo MinOZW /dev/ttyS2

ERROR: Failed to set serial port parameters
ERROR: Failed to open serial port /dev/ttyS2

sudo stty -F /dev/ttyS2 115200

Input/output error

can you help me ?

static const struct drm_display_mode feiyang_default_mode = {
    .clock        = 55000,

    .hdisplay    = 1024,
    .hsync_start    = 1024 + 310,
    .hsync_end    = 1024 + 310 + 20,
    .htotal        = 1024 + 310 + 20 + 90,

    .vdisplay    = 600,
    .vsync_start    = 600 + 12,
    .vsync_end    = 600 + 12 + 2,
    .vtotal        = 600 + 12 + 2 + 21,

    .type = DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED,
};

It looks simple enough to modify these values to work with my 1024x600 display, but I'm unsure what would be the best way to accomplish this. Which of the following could I do?

a) Just rebuild the modified driver alone and drop the new .ko file into the filesystem.

    or

b) Do a full Armbian image build using modified feiyang driver source.

Building the driver alone seems simpler, but I have zero experience with doing this sort of thing. I've installed the Linux headers package for the Allwinner A64 and piddled with building a trivial hello-world driver as outlined in the "Linux Kernel Module Programming Guide" doc that's floating around on the web.  That was easy enough to get working, but have no idea what magic incantations would be needed in the makefile for a real driver.

Building the Armbian image is appealing to me because the compile.sh script from the Armbian git repo does all the magic driver building for you. If I can somehow insert a modified version of the feiyang driver source into the OS image build process, that would do what I need.

So do either of these approaches make any sense at all and if so, can anyone suggest how to do plan A or plan B?  Thanks in advance.
 

I've opened with tag orangepiprime because there was no a64 tag eventhough in the Armbian site is flagged as standard support, tell me if i have to reopen it elsewhere.

Anyhow I'm constantly getting kernel panics during boot, I've tested images minimal/cli images starting from 23.5.1 down to 24.5.0 (just downloaded the image and flashed with balena etcher), attached there are all the serial logs of the boot processes, all of them are the same more or less.

I've tried:

• powering from GPIO
• changing powersupply
• changing usb cable
• 4 different uSD cards
• changing the board
• hooking it up to a display

and none of them worked.

What else can I try?

Armbian_24.5.0-trunk.223_Pine64_trixie_current_6.6.22_minimal.img.xz.log Armbian_24.2.1_Pine64_bookworm_current_6.6.16_minimal.img.xz.log Armbian_23.11.1_Pine64_bookworm_current_6.1.63.img.xz.log Armbian_23.8.1_Pine64_bookworm_current_6.1.47.img.xz.log Armbian_23.5.1_Pine64_bookworm_current_6.1.30.img.xz.log

on latest Armbian 23.11.1 Bookworm with PINE64 board I noticed those warnings in journal:

Feb 12 10:00:45 pine64 systemd[1]: /lib/systemd/system/systemd-journal-upload.service:33: Unknown key name 'RestartSteps' in s>
Feb 12 10:00:45 pine64 systemd[1]: /lib/systemd/system/systemd-journal-upload.service:34: Unknown key name 'RestartMaxDelaySec>

I suspect the `systemd-journal-upload.service` is not in tact with systemd daemon version installed.

I could, however, get Manjaro to boot on them, and when I created an SD card with U-Boot from the Manjaro SD card, and the partition from the Armbian (Bullseye CLI) image, it booted into Armbian.

I noticed, though, that Manjaro distinguishes between the Pine A64(+) and the Pine A64-LTS.  Tow-boot also makes the same distinction.  So I wondered if maybe Armbian wasn't booting on my A64-LTS boards because it wasn't making that distinction, but it should be.

(I also noticed that the headphone jack and ethernet port aren't working properly on Armbian, though they do work on Manjaro, but perhaps it's best to focus first on getting an official Armbian image to boot on the A64-LTS.)

Here's the output of `armbianmonitor -U`: http://paste.debian.net/1266079

Can anyone tell me how can i remove the wifi and ethernet services completely from the armbian.

root@pine64:~# dmesg|grep -i sound
[    2.686397]   No soundcards found.
[    6.323086] input: sun50i-a64-audio Headset Jack as /devices/platform/sound/sound/card0/input5

root@pine64:~# aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: sun50ia64audio [sun50i-a64-audio], device 0: 1c22c00.dai-sun8i-codec-aif1 sun8i-codec-aif1-0 [1c22c00.dai-sun8i-codec-aif1 sun8i-codec-aif1-0]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: sun50ia64hdmi [sun50i-a64-hdmi], device 0: 1c22800.i2s-i2s-hifi i2s-hifi-0 [1c22800.i2s-i2s-hifi i2s-hifi-0]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
 

Alsamixer Settings;

I downloaded the latest 20.04 image for Pine64+ and I am not getting any audio from youtube for example. I can see in the Volume Control window in the Output panel an audio level meter moving and the application Chromium. But still get no audio from the TV.

Has anybody gotten this to work?

I'm using a Pine 64 LTS with the SoPine image Armbian 21.02.3 Bionic with Linux 5.4.88-sunxi64

I have made various changes and installations to this image, so I want/need to continue using this image.

Unfortunately, with the new hardware of the Pine 64 LTS (Pine64 LTS-V2) network connection is no longer possible.
(Note: With the current SoPine image there is a network connection).

Is there any way to reinstall the current network drivers in my image?

I would be very grateful for any help.

i'm new with linux and SBC.

My final goal is to use the board as a voice command recognition system (without display) and to be honest i do not know how to start.

I downloaded Armbian desktop on microSD using balenaEtcher and I inserted it in the board e powered it!

i do not have a display unfortunatly and i do not know if desktop version is the best choice or i have to install an embedded version if exists.

Could help please?

thanks

- mpv, best result, probably ~10 fps

- mplayer -vo sdl/fbdev2, probably ~5 fps

- cvlc, probably 2~3 fps

- kodi, probably 1~2 fps

- gst123, could not get it running because issue with ALSA
 

The fps are sort of guessed. Any other software and tips for testing are welcome. None of the movies playing played sound. speaker-test also did not play sound even though alsamixer showed all is well. Tips for this please too.

What are the steps to take to install the (closed source) Mali driver and/or the (open source) Lima driver?

I just installed the Armbian on a Pine A64+ (Armbian Focal, mainline based kernel 5.9.y).

I'm having trouble getting audio from the 3.5mm stereo output. I've tried several things, including a speaker test:

speaker-test -c 2 -Dsysdefault:sun50ia64audio

I tried editing /etc/asound.conf but it doesn't seem to affect anything. Do changes to that file apply instantly?

What can I do to test/diagnose the issue?

I tried latest Armbian image for PineH64-b. (Armbian_20.11_Pineh64-b_focal_current_5.8.16_desktop)

And I surprisingly found there is no audio device when I looked around.( by #aplay -l )

Is this expected for now? My older 5.6 kernel has HDMI device at least.

I tried search audio problem around but had no discover so far. Please allow me to confirm with you.

I'm looking for a good 5.8 multimedia-capable kernel to merge with my gentoo rootfs. 

Thank you.

           Armbian_21.08.1_Pine64so_buster_current_5.10.60.img and

           Armbian_21.08.1_Pine64so_focal_current_5.10.60.img

Both images boot normally (including network connection), but after the update (apt update, apt upgrade) no IP4 network connection is established for eth0.

For help I am very grateful for any help.

update-initramfs: Generating /boot/initrd.img-5.15.48-sunxi64
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8156b-2.fw for module r8152

after apt upgrade.

            mount: mounting "/dev/mapper/vg-root on /root failed: No such file or directory␍␊

            Failed to mount "/dev/mapper/vg-root as root file system.␍␊

The flollowing step i made  (short version)

- create the lvm partition

- mount lvm partition and and copy file system auf lvm partition, bind /dev, sys, proc

- chroot in the lvm root partition (vg-root)

- change /etc/fstab :  insert

               /dev/mapper/vg-root / ext4 errors=remount-ro 0 1

                UUID=<UUID-Partiion> /mnt/mnt ext4 defaults,noatime,nodiratime,commit=600,errors=remount-ro 0 2

               #UUID=<UUID-Partiion> / ext4 defaults,noatime,nodiratime,commit=600,errors=remount-ro 0 1

- create the initramfs:

               update-initramfs -u -k $(uname -r)

- change armbian.txt:

             rootdev="/dev/mapper/vg-root cryptdevice=/dev/mmcblk0p2:lvm"

During boot, the device ask the PW:

             Begin: Mounting root file system ... Begin: Running /scripts/local-top ... Please unlock disk lvm: ␍␊

After inserting the password, lvm seems alright ("cryptsetup: lvm: set up successfully␍␊done.␍␊")

But the boot file system is not fount

               Begin: Running /scripts/local-premount ... Scanning for Btrfs filesystems␍␊

              done.␍␊

               Begin: Will now check root file system ... fsck from util-linux 2.33.1␍␊

               Checking all file systems.␍␊

               done.␍␊

              mount: mounting "/dev/mapper/vg-root on /root failed: No such file or directory␍␊

              Failed to mount "/dev/mapper/vg-root as root file system.␍␊

i am very grateful for any comments and tips.
I have already done such LVM boot encryption 2 years ago on Pine 64 and Pine LTS.
BUT NOW I HAVE NO IDEA HOW TO LOOK FURTHER.

So I got this Pine a64+ during their Kickstarter campaign. Initially I used it as a little play desktop. I never really found a use for it until very recently.

I decided to use it as a little software Squeezebox client. I installed Armbian 22.04 server. I then setup alsa to use the HDMI audio as default output. I installed squeezelite and it immediately found and connected to my LMS (Logitech Media Server) running on my server. At this point I figured all was good. The sound was working great through my receiver.

The next morning (Sunday) the kids could not get the TV sound to work. So of course they woke me up on the only day I can sleep in a bit.

I assumed the Onkyo TX-SR393 receiver was on the wrong Input. After checking it out, it was on the correct input. Speaker output was correct. It made no sense. I rebooted both the receiver and the TV yet the problem persisted. Still no sound from the TV. Finally I decided to unplug the HDMI to the Pine64. Right away the sound came back for the TV.

I chalked it up to a fluke. It was not, as on Monday morning the same thing happened. Again, only fix was to unplug the HDMI from the Pine64.

Setup Info;

• The TV is using HDMI to connect to the Onkyo on the CEC/ARC channel.
• Video seems unaffected on both the TV and Pine64
• I did not test if sound was borked on the Pine64 during these issues (I was just trying to get the TV up for the kids  )
• `dmesg` on the Pine64 does not show anything pertinent that I can discern
• The TV/Receiver were off overnight and the Pine64 was on.

If anyone could suggest some possible causes/solutions/tests I could do to get closer to a fix I would really appreciate it.

Thanks!

and is the bug fixed in kernel version 4.14?

Could I install this kernel version 4.14 via armbian-config (next-kernel)?

Thanks a lot for help.

I have a Pine64 board and recently added an audio POT with the pcm5102a chipset.

It is rather difficult to get the board working/recognized. I found info on the forum saying one has to do stuff with the overlay system but only for other boards than the Pine64 and I can't get it right.

aplay -l:

root@pine64:~# aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: sun50ia64audio [sun50i-a64-audio], device 0: 1c22c00.dai-sun8i-codec-aif1 sun8i-codec-aif1-0 [1c22c00.dai-sun8i-codec-aif1 sun8i-codec-aif1-0]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: sun50ia64hdmi [sun50i-a64-hdmi], device 0: 1c22800.i2s-i2s-hifi i2s-hifi-0 [1c22800.i2s-i2s-hifi i2s-hifi-0]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

I have edited the dtc tree and activated i2s@1c22000:

                i2s@1c22000 {
                        #sound-dai-cells = <0x00>;
                        compatible = "allwinner,sun50i-a64-i2s\0allwinner,sun8i-h3-i2s";
                        reg = <0x1c22000 0x400>;
                        interrupts = <0x00 0x0d 0x04>;
                        clocks = <0x02 0x3c 0x02 0x52>;
                        clock-names = "apb\0mod";
                        resets = <0x02 0x27>;
                        dma-names = "rx\0tx";
                        dmas = <0x2f 0x03 0x2f 0x03>;
                        status = "okay";
                        phandle = <0x7c>;
                };

And the module shows up with lsmod:

snd_soc_simple_card    24576  0
snd_soc_simple_card_utils    24576  1 snd_soc_simple_card
cpufreq_dt             20480  0
sch_fq_codel           24576  2
snd_soc_pcm5102a       16384  0

But now I am stuck. What do I have to do to get this board working?

Thanks in advance for any help.

Cheers,

Joost

I am using Allwinner A64 processor for my use case. In that, I want to flash my custom os into emmc memory which is alredy worked in SD card. Currenlty we go thorugh below link:

https://wiki.pine64.org/index.php/NOOB#Instructions_to_Flashing_eMMC_Modules

we follow "xzcat imagename.img.xz | sudo dd of=/dev/mmcblk1 bs=1M status=progress conv=fsync" this command but we got input/out error while reading memory.

Please check below screenshot.

Quote

me@aldo:~$ uname -a
Linux aldo.xxxxx.com 5.10.21-sunxi64 #21.02.3 SMP Mon Mar 8 00:45:13 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux

The system rebooted just fine, though took longer then before. I didn't realize why until today, when I tried to access /media/mmcboot and discovered that it wasn't there. In fact, there is no /dev/mmcblk0p1 device at all. It's bizarre: it boots from the MicroSD, switches to my SSD, but then the MicroSD card device is simply gone when the system is up.

I do not see this on two other Pine A64 (not LTS) systems.

Quote

 20048  [   96.545683] systemd[1]: dev-disk-by-uuid-9de746a4-d0de-404f-9403-4645fb268a33.device: Job dev-disk-by-uuid-9de746a4-df0de-404f-9403-4645b268a33.device/start timed out.
 20049  [   96.545731] systemd[1]: Timed out waiting for device /dev/disk/by-uuid/9de746a4-d0de-404f-9403-4645fb268a33.
 20050  [   96.560122] systemd[1]: Dependency failed for File System Check on /dev/disk/by-uuid/9de746a4-d0de-404f-9403-4645fb268a33.
 20051  [   96.564171] systemd[1]: Dependency failed for /media/mmcboot.
 20052  [   96.568077] systemd[1]: Dependency failed for /boot.

I was able to mount the microSD card on one of the other systems, and fsck reported everything was fine. I could also see all of the files just fine. The files in /boot had been updated for 5.10.21.

But booting up the LTS again resulted in the same thing: it boots, but /dev/mmcblk0p1 does not exist.

Any ideas?

Thanks!

So I have Pine64 A64 512MB cards (not the plus model), running Armbian 20.05.0-trunk.038 nightly, (uname -r:  5.4.18-sunxi64).
I needed to freeze upgrades for two reasons:

1. Boot hangs up: The armbian thinks that I have the plus model: on every upgrade I need to replace the "sun50i-a64-pine64-plus.dtb" file with "sun50i-a64-pine64.dtb" at /boot/dtb/allwinner because the non-plus model (512MB) has different ethernet hardware.
2. Missing gpio-ir-recv kernel module from stock Armbian: For transmitting IR signals via GPIO we are using gpio-ir-tx kernel module already located in stock armbian, but for receiving IR signals via GPIO we need the gpio-ir-recv kernel module. So I have downloaded this file from the official armbian source at github and recompiled all kernel modules to get only this gpio-ir-recv.ko kernel module file.... (it took a while)

So to activate those kernel modules I needed to create a Custom Device Tree Overlay (here is how to activate it).

Here is the content of my custom dt overlay, but if you want to modify GPIO pin numbers, you need to experiment which pin is interrupt enabled and not used for other stuff...
+1 good advice ---> If you want to send and receive custom IR protocol, it's better to use the ir-ctl program than lirc.

/dts-v1/;
/plugin/;

/ {
        compatible = "allwinner,sun50i-a64";

        fragment@0 {
                target = <&pio>;
                __overlay__ {
                        ir_rx1_pins: ir-rx1-pins {
							pins = "PH6";
							function = "gpio_in";
                        };
                        ir_rx2_pins: ir-rx2-pins {
							pins = "PH7";
							function = "gpio_in";
                        };
                        ir_rx3_pins: ir-rx3-pins {
							pins = "PH8";
							function = "gpio_in";
                        };
                        ir_rx4_pins: ir-rx4-pins {
							pins = "PH9";
							function = "gpio_in";
                        };
                        ir_tx1_pins: ir-tx1-pins {
							pins = "PH5";
							function = "gpio_out";
                        };
                        ir_tx2_pins: ir-tx2-pins {
							pins = "PD0";
							function = "gpio_out";
                        };
                };
        };

        fragment@1 {
                target-path = "/";
                __overlay__ {
                        gpio_ir_rx1: gpio-ir-receiver-1 {
                                compatible = "gpio-ir-receiver";
                                pinctrl-names = "default";
                                pinctrl-0 = <&ir_rx1_pins>;
								gpios = <&pio 7 6 1>; /* PH6 */
								status = "okay";
                        };
                        gpio_ir_rx2: gpio-ir-receiver-2 {
                                compatible = "gpio-ir-receiver";
                                pinctrl-names = "default";
                                pinctrl-0 = <&ir_rx2_pins>;
								gpios = <&pio 7 7 1>; /* PH7 */
								status = "okay";
                        };
                        gpio_ir_rx3: gpio-ir-receiver-3 {
                                compatible = "gpio-ir-receiver";
                                pinctrl-names = "default";
								pinctrl-0 = <&ir_rx3_pins>;
								gpios = <&pio 7 8 1>; /* PH8 */
								status = "okay";
                        };
                        gpio_ir_rx4: gpio-ir-receiver-4 {
                                compatible = "gpio-ir-receiver";
                                pinctrl-names = "default";
								pinctrl-0 = <&ir_rx4_pins>;
								gpios = <&pio 7 9 1>; /* PH9 */
								status = "okay";
                        };
                        gpio_ir_tx1: gpio-ir-transmitter-1 {
                                compatible = "gpio-ir-tx";
                                pinctrl-names = "default";
                                pinctrl-0 = <&ir_tx1_pins>;
								gpios = <&pio 7 5 0>; /* PH5 */
								status = "okay";
                        };
                        gpio_ir_tx2: gpio-ir-transmitter-2 {
                                compatible = "gpio-ir-tx";
                                pinctrl-names = "default";
                                pinctrl-0 = <&ir_tx2_pins>;
								gpios = <&pio 3 0 0>; /* PD0 */
								status = "okay";
                        };
                };
        };
};

I brought new pine64 board and installing OS in SD card. This OS considering kernel 5.10.34 and now I want to modify some of the kernel features. For that, please guide me how to download kernel source and rebuild it for pine64.

Hardware related issues:

Please don't blame Armbian for the few design flaws Pine64 and Pine64+ show:

• These boards use Micro USB for DC-IN which is the worst possible decision. Most USB cables have a resistance way too high and are responsible for severe voltage drops when consumption increases, then the tiny Micro USB contacts have also a pretty high contact resistance and also maximum amperage for this connector is limited to 1.8A by USB specs. So in case you want to do heavy stuff immediately look into linux-sunxi wiki page for Pine64 to get the idea how to use the pins on the so called Euler connector to power the board more reliably. If you think about buying a Pine now consider ordering their PSU  too since there cable resistance shouldn't be a problem (should also apply to the Micro USB cables they sell)
• The only led on this board is a power led that immediately lights when power is provided. Pre-production samples had a green led, on the normal batches this has been replaced with a red led. So there's no way for an OS image to provide user feedback (activate an led when u-boot or kernel boots) and the red light has often been interpreted as 'something is wrong'
• USB: you find 2 USB type A receptacles on the board but only one is a true USB host port, the other/upper is A64's USB OTG port exposed not as Mini/Micro USB (with ID pin to be able to switch roles) but as a normal type A port. Expect performance to be lower on this port. I've also never been able to do disk benchmarking on the upper port but that might have changed in the meantime (I only have a pre-production developer sample here). Please note also that the maximum amperage available on the USB port is 650mA so connecting bus-powered USB disks might already exceed this so be prepared to use a powered USB hub in between
• A64 is prone to overheating but unfortunately the Pine64 folks do not sell the board with an effective heatsink by default (compare with ODROID-C1+ or ODROID-C2 for example how it looks like if the vendor cares about heat dissipation). They promised to provide a good heatsink as option but at least I'm not able to find one in their online store. But a heatsink is mandatory if you plan to run this device constantly with high loads, otherwise throttling will occur (when we tested an unrealistic heavy workload without a heatsink -- cpuburn-a53 -- A64 had to throttle down to as less as 600 MHz (for some numbers see IRC log from a while ago)
• Not a real hardware issue but a problem anyway: the HDMI driver in Allwinner's BSP does not negotiate any display output with a lot of displays that are connected with a HDMI <--> DVI converter or use non-common resolutions. Better do not expect any display output if your display is neither connected directly using HDMI nor capable of 1080p (we can't do anything here since Allwinner's driver uses closed source blobs and no documentation or code with useable license exists)
• On a couple of Gbit equipped Pine64+ users report that they're not able to negotiate Gbit Ethernet reliably and have to force the connection to Fast Ethernet (since we know that the RTL8211E PHY used on the boards needs an additional ~350 mW when negotiating a Gbit Ethernet connection this might be related to power problems or maybe different PHY batches or something else). Confirmed in the meantime to be a hardware issue.

Now combine Micro USB encouraging users to combine this SBC with crappy phone chargers, 'smart' hubs/chargers that do only provide 500mA since Pine64 isn't able to ask for more and crappy USB cables leading to voltage drops (all sorts of power related issues 'by design' due to crappy Micro USB connector) with a missing custom led able to be used to provide user feedback while booting and the inability to use a lot of displays then you might already get what a support nightmare this device is.

The only reliable DOA detection method without a serial console is to ensure you have a working SD card (test it before using either F3 or H2testw as outlined in our docs), then check download integrity of the Armbian image (again see the documentation), then ensure you burn the image correctly to SD card (see docs), insert SD card, power on the board and wait 20 seconds. If then the leds on the Ethernet jack start to flash randomly at least the kernel boots and after waiting an additional 2 minutes you'll be able to login with SSH or serial console (for the latter better choose the EXP header over the Euler connector -- reason here)

Anyway: In case you run in booting or stability problems with Armbian on Pine64/Pine64+ be assured that it's not an Armbian issue. You run into any of the problems above therefore please try to resolve them on your own and send your complaints to Pine64 forum and not ours: http://forum.pine64.org/forumdisplay.php?fid=21  (really, we don't do hardware and these issues are all related to hardware design decisions)

Expectations:

The Pine64 folks did a great job raising expectations to the maximum. They advertised this board as 'first $15 64-Bit Single Board Super Computer', promised an average consumption of just 2.5W, the SoC remaining at 32°C and a few other weird things while they already knew that reality differs a lot (the journey started here last Dec).

Pine64 is not a 'Super Computer' but most probably the slowest 64-bit ARM board around due to A64 being limited regarding maximum cpufreq and overheating issues (40nm process being responsible for) and lack of fast IO interconnections (only one real USB 2.0 host port present, no eMMC option possible, no SD card implementation using the faster modes). If you then combine the high expectations with a rather clueless kickstarter crowd (many of them not even getting that they did not buy products but backed a project) and the hardware flaws it's pretty obvious why their forums are full of complaints and why they receive so much boards as being DOA that work flawlessly in reality.

So why bringing Armbian to Pine64? Since for some (headless) use cases these boards are really nice and also cheap, A64 support is progressing nicely thanks to our awesome linux-sunxi community and also a few more A64 devices will be available soon.

What do you get with Armbian on Pine64?

User experience will not be much different compared to longsleep's minimal Ubuntu image. If you prefer Debian then at least you can be assured that our images do not contain bad settings and silly bugs like the one's from official Pine64 downloads section (since they fiddle around manually with their OS images for example all Pine boards running these have the same MAC address by default which will cause network troubles if you've more than one board in the same collision domain).

We use the same thermal/throttling settings like OS images based on longsleep's kernel (since we helped developing them back in March), we use the same BSP kernel (patched by Zador up to the most recent version back in May) and share a few more similarities since our modifications were sent back to longsleep so all OS images for Pine64 might be able to benefit from.

Differences: You don't need to execute longsleep's various platform scripts since kernel and u-boot updates are done using the usual apt-get upgrade mechanism in Armbian. You also don't need (and should not use) scripts like pine64_tune_network.sh since they decrease network performance with Armbian (stay with our defaults unless you're an expert). And a few more tweaks might result in better performance and at least by using Armbian you have the usual Armbian experience with some additional tools at the usual location, automatic fs resize on first boot and so on.

We already provide a vanilla image currently based on kernel 4.7 but that's stuff for developers only, see below.

Performance with legacy Armbian image:

'Out of the box' CPU performance with A64 is not that great unless you are able to benefit from the new CPU features: A64 uses Cortex-A53 CPU cores that feature 64-bit capabilities (which are not that interesting since A64 devices are limited to 2 GB DRAM anyway at the moment) but more interestingly ARMv8 instruction set can be used which might increase performance a lot when software will be compiled for this platform. Best example: the commonly mis-used sysbench cpu test: When running an ARMv6 'optimized' sysbench binary on an ARMv8 CPU then performance will be 15 times slower than necessary (applies to the RPi 3 or the upcoming Banana Pi M64 when used with their OS images)

But as soon as ARMv8 optimized code is used A64 can really shine in some areas. I used the default sysbench contained in Ubuntu Xenial's arm64 version, tried it with 20000 settings and got less than 8 seconds execution time (an RPi 3 running Raspbian has the faster CPU cores but here it will take 120 seconds -- just due to different compiler switches!). Then I tried whether I can optimize performance building sysbench from source using

export AM_CFLAGS="-march=armv8-a -mtune=cortex-a53"

and got 11 seconds execution time, so optimized code led to a huge performance loss? Not really, I checked out sysbench version 0.5 by accident and there for whatever reasons execution with ARMv8 optimization or in general takes longer (great! benchmark version influences execution time, so one more reason to never trust in sysbench numbers found on the net!). Using the '0.4' branch at version 0.4.12 I got an execution time of less than 7.5 seconds which is a 10 percent increase in performance for free just by using appropriate compiler flags:

root@pine64:/# /usr/bin/sysbench --test=cpu --cpu-max-prime=20000 run --num-threads=4
sysbench 0.4.12:  multi-threaded system evaluation benchmark

Running the test with following options:
Number of threads: 4

Doing CPU performance benchmark

Threads started!
Done.

Maximum prime number checked in CPU test: 20000


Test execution summary:
    total time:                          7.9788s
    total number of events:              10000
    total time taken by event execution: 31.8939
    per-request statistics:
         min:                                  3.17ms
         avg:                                  3.19ms
         max:                                  8.74ms
         approx.  95 percentile:               3.19ms

Threads fairness:
    events (avg/stddev):           2500.0000/3.54
    execution time (avg/stddev):   7.9735/0.00

root@pine64:/# /usr/local/src/sysbench-0.4.12/sysbench/sysbench --test=cpu --cpu-max-prime=20000 run --num-threads=4
sysbench 0.4.12:  multi-threaded system evaluation benchmark

Running the test with following options:
Number of threads: 4
Random number generator seed is 0 and will be ignored


Doing CPU performance benchmark

Primer numbers limit: 20000

Threads started!
Done.


General statistics:
    total time:                          7.4608s
    total number of events:              10000
    total time taken by event execution: 29.8223
    response time:
         min:                                  2.96ms
         avg:                                  2.98ms
         max:                                  8.51ms
         approx.  95 percentile:               2.99ms

Threads fairness:
    events (avg/stddev):           2500.0000/3.67
    execution time (avg/stddev):   7.4556/0.00

root@pine64:/# /usr/local/src/sysbench/sysbench/sysbench --test=cpu --cpu-max-prime=20000 run --num-threads=4
sysbench 0.5:  multi-threaded system evaluation benchmark

Running the test with following options:
Number of threads: 4
Random number generator seed is 0 and will be ignored


Prime numbers limit: 20000

Initializing worker threads...

Threads started!


General statistics:
    total time:                          11.0451s
    total number of events:              10000
    total time taken by event execution: 44.1223s
    response time:
         min:                                  4.38ms
         avg:                                  4.41ms
         max:                                 27.34ms
         approx.  95 percentile:               4.41ms

Threads fairness:
    events (avg/stddev):           2500.0000/6.36
    execution time (avg/stddev):   11.0306/0.01

Another great example how using CPU features or not (NEON in this case) influences performance and 'benchmarking gone wrong' numbers are Linpack's MFLOPS scores. By choosing the package your distro provides instead of using one that makes use of your CPU's features you loose at lot of performance, ruin every performance per watt ratios and behave somewhat strange

Someone sent me Linpack MFLOPS numbers generated with Debian Jessie which is known for horribly conserative compiler settings when building packages -- if you switch your distro from Jessie to Ubuntu Xenial for example you get a 30 percent improvement in sysbench numbers, yeah that's the 'benchmark' we already laughed at above.

With Jessie's/Raspbian's hpcc package, Pine64+ gets a score of 1625 MFLOPS and RPi 3 just 1035. So is Pine64 1.6 times faster than RPi 3? Nope, that's just 'benchmarking gone wrong' since these numbers are the result of a joke: Using tools for 'High performance computing' with standard settings (no one interested in HPC would ever do that). By using the correct Linpack version that makes use of NEON optimizations on both CPUs we end up with 3400 MFLOPS (Pine64 at 1.3 GHz) vs 3600 MFLOPS (RPi 3 at 1.2 GHz).

So if we're talking about this use case (HPC -- high performance computing) RPi 3 easily outperforms A64 (please keep in mind that the 3400 MFLOPS I got are the result of overclocking/overvolting at 1296 MHz, Pine64 is limited to 1152 MHz by default so we're talking about 3000 MFLOPS for A64 vs. 3600 MFLOPS for RPi 3's SoC. So it's not Pine64 being 1.6 times faster but RPi 3 being more suited for Linpack numbers and this type of benchmarks only shows how wrong it is to use distro packages that are built using conservative settings (which is a must if the distro wants to support a wide range of different SoCs!)

Anyway: I's obvious that in case you want to use Pine64 for number crunching or performance stuff in general evaluating whether compiling packages from source might improve performance is a great idea (at least it's obvious that from a performance point of view using an ARMv6 distro with ARMv8 SoCs is stupid -- reality with Raspbian running on RPi 3 and BPi M64). ARMv8 also provides crypto extensions that might be used with OpenSSL for example. Didn't look into it yet but maybe huge performance gains when using a Pine64 as HTTPS enabled web server or VPN endpoint are possible just like we've already seen with sysbench.

Network performance: Pine64+ combines the SoC internal GbE MAC implementation (the same as in H3 and A83T SoCs from Allwinner) with an external RTL8211E PHY as used on most GbE capable SBC. Default iperf performance with Armbian/Xenial: +900 MBits/sec in both directions (920/940 MHz) so no need for further tuning (please read through this explanation here why blindly trusting in iperf numbers is always stupid and why it's neither necessary nor useful to further tune network settings to get better iperf numbers).

root@armbian:/var/git/Armbian# iperf3 -c 192.168.83.64
Connecting to host 192.168.83.64, port 5201
[  4] local 192.168.83.115 port 60392 connected to 192.168.83.64 port 5201
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.00   sec   112 MBytes   938 Mbits/sec    0    356 KBytes       
[  4]   1.00-2.00   sec   112 MBytes   941 Mbits/sec    0    376 KBytes       
[  4]   2.00-3.00   sec   112 MBytes   943 Mbits/sec    0    376 KBytes       
[  4]   3.00-4.00   sec   112 MBytes   941 Mbits/sec    0    376 KBytes       
[  4]   4.00-5.00   sec   112 MBytes   938 Mbits/sec    0    376 KBytes       
[  4]   5.00-6.00   sec   113 MBytes   947 Mbits/sec    0    376 KBytes       
[  4]   6.00-7.00   sec   112 MBytes   940 Mbits/sec    0    395 KBytes       
[  4]   7.00-8.00   sec   112 MBytes   942 Mbits/sec    0    395 KBytes       
[  4]   8.00-9.00   sec   112 MBytes   942 Mbits/sec    0    395 KBytes       
[  4]   9.00-10.00  sec   112 MBytes   942 Mbits/sec    0    395 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec  1.10 GBytes   941 Mbits/sec    0             sender
[  4]   0.00-10.00  sec  1.09 GBytes   940 Mbits/sec                  receiver

root@pine64:~# iperf3 -c 192.168.83.115
Connecting to host 192.168.83.115, port 5201
[  4] local 192.168.83.64 port 39363 connected to 192.168.83.115 port 5201
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.00   sec   114 MBytes   954 Mbits/sec    0   1.05 MBytes       
[  4]   1.00-2.00   sec   110 MBytes   922 Mbits/sec    0   1.24 MBytes       
[  4]   2.00-3.01   sec   110 MBytes   918 Mbits/sec    0   1.24 MBytes       
[  4]   3.01-4.00   sec   109 MBytes   917 Mbits/sec    0   1.24 MBytes       
[  4]   4.00-5.01   sec   110 MBytes   918 Mbits/sec    0   1.24 MBytes       
[  4]   5.01-6.01   sec   110 MBytes   923 Mbits/sec    0   1.24 MBytes       
[  4]   6.01-7.00   sec   109 MBytes   918 Mbits/sec    0   1.24 MBytes       
[  4]   7.00-8.00   sec   110 MBytes   923 Mbits/sec    0   1.24 MBytes       
[  4]   8.00-9.00   sec   109 MBytes   912 Mbits/sec    0   1.24 MBytes       
[  4]   9.00-10.00  sec   110 MBytes   923 Mbits/sec    0   1.24 MBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec  1.07 GBytes   923 Mbits/sec    0             sender
[  4]   0.00-10.00  sec  1.07 GBytes   920 Mbits/sec                  receiver

root@pine64:~# iperf3 -c 192.168.83.115
Connecting to host 192.168.83.115, port 5201
[  4] local 192.168.83.64 port 39365 connected to 192.168.83.115 port 5201
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.02   sec  47.9 MBytes   395 Mbits/sec    1   99.0 KBytes       
[  4]   1.02-2.02   sec  55.0 MBytes   459 Mbits/sec    0    132 KBytes       
[  4]   2.02-3.01   sec  60.3 MBytes   511 Mbits/sec    0    151 KBytes       
[  4]   3.01-4.01   sec  91.2 MBytes   769 Mbits/sec    0    170 KBytes       
[  4]   4.01-5.01   sec  96.2 MBytes   804 Mbits/sec    0    182 KBytes       
[  4]   5.01-6.01   sec  96.2 MBytes   806 Mbits/sec    0    191 KBytes       
[  4]   6.01-7.01   sec  96.2 MBytes   808 Mbits/sec    0    195 KBytes       
[  4]   7.01-8.01   sec  96.2 MBytes   808 Mbits/sec    0    197 KBytes       
[  4]   8.01-9.00   sec  95.0 MBytes   805 Mbits/sec    0    198 KBytes       
[  4]   9.00-10.00  sec  97.5 MBytes   815 Mbits/sec    0    199 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec   832 MBytes   698 Mbits/sec    1             sender
[  4]   0.00-10.00  sec   832 MBytes   698 Mbits/sec                  receiver

The other stuff normally 'benchmarked' is not worth mentioning/testing it so just as quick notes:

• A64 is showing the same SDIO limitation as most other SoCs limiting sequential transer speeds to/from SD card to ~23MB/s (do the math yourself: SDIO with 4 bit @ 50 MHz minus some overhead is 23 MB/s) -- fortunately that's rather uninteresting since random IO matters on SBCs and there it's your choice to choose between crappy cards that horribly suck or follow our recommendations and choose a really fast card. But Pine64 can not use the faster eMMC interface so if you really need high IO bandwidth and high IOPS better choose a different device
• USB is USB 2.0 so expect ~35MB/s with BSP kernel and ~40MB/s with mainline kernel and UASP capable disk enclosures for individual USB connections (UASP + mainline kernel might show high random IO numbers if used together with an SSD!)
• HW accelerated video decoding is already possible (see here for the codec matrix) and situation with HW accelerated video encoding looks promising too: http://forum.armbian.com/index.php/topic/1855-ffmpeg-with-cedrus-h264-hw-encoder-a64-cmos-camera/

In case one is interested in performance testing on SBCs monitoring what's happening is mandatory. Currently our armbianmonitor tool does not install the necessary templates on A64 so still my script to install this stuff on A64 should be used: http://kaiser-edv.de/tmp/4U4tkD/install-rpi-monitor-for-a64.sh (read the script's header how to install)

Performance with vanilla Armbian image:

Not interesting at all at the time of this writing since while Pine64 happily boots mainline u-boot/kernel it's way too early to do tests in this area. Currently there's no access to the AXP803 PMIC from mainline kernel so not even VDD_CPUX voltage regulation works and as a result cpufreq scaling is also not working and the SoC is clocked pretty conservative. Since most performance relevant stuff running on cheap ARM SoCs depends on (switching as fast as possible to) high CPU clockspeeds benchmarking is absolutely useless now.

You should also keep in mind that many core features still not work with mainline kernel so this is really stuff for developers (who normally prefer their own way to boot their freshly compiled kernels). So please don't expect that much from vanilla images for A64 boards now, better choose the legacy variant.

The future?

A few more A64 boards are announced or already available as dev samples, for example the aforementioned BPi M64 (possible advantages over Pine64: sane DC-IN, real USB OTG, more USB host ports behind an internal USB hub, eMMC available and custom leds being able to provide user feedback, everything else is more or less the same as the 2 GB Pine64+) or Olimex working on both an SBC and an A64 based Laptop.

And then Xunlong announced 2 new SBC based on Allwinner's H5. H5 (product brief) seems to be A64's bigger sibling providing video/GPU enhancements, 3 true USB host ports in addition to one USB OTG (just like H3 where we can use all 4 USB ports that do not have to share bandwidth), integrating a Fast Ethernet PHY (just like H3) but lacks PMIC support (again just like H3, so no mobile useage, no battery support out of the box and it gets interesting how VDD_CPUX voltage regulation will work there -- maybe 'just like H3' again).

Since A64 shares many/most IP blocks with H3 and A83T from Allwinner I still hope that H5 will be just a mixture of A64 and H3 and we will get full support based on what we now have for these 2 other SoCs pretty fast. But that's 100 percent speculation at this moment

Update regarding longsleep's pine64_tune_network.sh script. Benchmark results don't get automatically worse when applying the tweaks from his script but the result variation gets huge (730 - 950 Mbits/sec, exceeding 940 Mbits/sec is already an indication that buffers are invoked):

root@pine64:/home/tk# iperf3 -s
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------
Accepted connection from 192.168.83.115, port 50002
[  5] local 192.168.83.76 port 5201 connected to 192.168.83.115 port 50004
[ ID] Interval           Transfer     Bandwidth
[  5]   0.00-1.00   sec  90.7 MBytes   759 Mbits/sec                  
[  5]   1.00-2.00   sec  92.2 MBytes   774 Mbits/sec                  
[  5]   2.00-3.00   sec  92.5 MBytes   776 Mbits/sec                  
[  5]   3.00-4.00   sec  92.5 MBytes   776 Mbits/sec                  
[  5]   4.00-5.00   sec  92.6 MBytes   777 Mbits/sec                  
[  5]   5.00-6.00   sec   106 MBytes   889 Mbits/sec                  
[  5]   6.00-7.00   sec   112 MBytes   942 Mbits/sec                  
[  5]   7.00-8.00   sec   111 MBytes   927 Mbits/sec                  
[  5]   8.00-9.00   sec   101 MBytes   847 Mbits/sec                  
[  5]   9.00-10.00  sec   112 MBytes   942 Mbits/sec                  
[  5]  10.00-10.02  sec  1.66 MBytes   931 Mbits/sec                  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  5]   0.00-10.02  sec  1007 MBytes   843 Mbits/sec    9             sender
[  5]   0.00-10.02  sec  1004 MBytes   841 Mbits/sec                  receiver
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------
Accepted connection from 192.168.83.115, port 50006
[  5] local 192.168.83.76 port 5201 connected to 192.168.83.115 port 50008
[ ID] Interval           Transfer     Bandwidth
[  5]   0.00-1.00   sec  88.4 MBytes   740 Mbits/sec                  
[  5]   1.00-2.00   sec  91.9 MBytes   771 Mbits/sec                  
[  5]   2.00-3.00   sec   109 MBytes   918 Mbits/sec                  
[  5]   3.00-4.00   sec   112 MBytes   941 Mbits/sec                  
[  5]   4.00-5.00   sec   112 MBytes   941 Mbits/sec                  
[  5]   5.00-6.00   sec   112 MBytes   942 Mbits/sec                  
[  5]   6.00-7.00   sec   112 MBytes   942 Mbits/sec                  
[  5]   7.00-8.00   sec   112 MBytes   942 Mbits/sec                  
[  5]   8.00-9.00   sec   112 MBytes   941 Mbits/sec                  
[  5]   9.00-10.00  sec   112 MBytes   941 Mbits/sec                  
[  5]  10.00-10.02  sec  1.89 MBytes   928 Mbits/sec                  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  5]   0.00-10.02  sec  1.05 GBytes   904 Mbits/sec    0             sender
[  5]   0.00-10.02  sec  1.05 GBytes   902 Mbits/sec                  receiver
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------
Accepted connection from 192.168.83.115, port 50010
[  5] local 192.168.83.76 port 5201 connected to 192.168.83.115 port 50012
[ ID] Interval           Transfer     Bandwidth
[  5]   0.00-1.00   sec  87.7 MBytes   734 Mbits/sec                  
[  5]   1.00-2.00   sec  92.1 MBytes   773 Mbits/sec                  
[  5]   2.00-3.00   sec  92.2 MBytes   773 Mbits/sec                  
[  5]   3.00-4.00   sec  92.1 MBytes   773 Mbits/sec                  
[  5]   4.00-5.00   sec  92.1 MBytes   773 Mbits/sec                  
[  5]   5.00-6.00   sec   102 MBytes   859 Mbits/sec                  
[  5]   6.00-7.00   sec  93.1 MBytes   781 Mbits/sec                  
[  5]   7.00-8.00   sec  92.1 MBytes   773 Mbits/sec                  
[  5]   8.00-9.00   sec  92.1 MBytes   773 Mbits/sec                  
[  5]   9.00-10.00  sec  94.9 MBytes   796 Mbits/sec                  
[  5]  10.00-10.02  sec  1.62 MBytes   740 Mbits/sec                  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  5]   0.00-10.02  sec   936 MBytes   783 Mbits/sec    0             sender
[  5]   0.00-10.02  sec   933 MBytes   781 Mbits/sec                  receiver
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------
Accepted connection from 192.168.83.115, port 50014
[  5] local 192.168.83.76 port 5201 connected to 192.168.83.115 port 50016
[ ID] Interval           Transfer     Bandwidth
[  5]   0.00-1.00   sec  87.1 MBytes   729 Mbits/sec                  
[  5]   1.00-2.00   sec  92.1 MBytes   774 Mbits/sec                  
[  5]   2.00-3.00   sec  91.8 MBytes   769 Mbits/sec                  
[  5]   3.00-4.00   sec  90.4 MBytes   759 Mbits/sec                  
[  5]   4.00-5.00   sec  96.4 MBytes   808 Mbits/sec                  
[  5]   5.00-6.00   sec  90.2 MBytes   758 Mbits/sec                  
[  5]   6.00-7.00   sec   113 MBytes   951 Mbits/sec                  
[  5]   7.00-8.00   sec   112 MBytes   941 Mbits/sec                  
[  5]   8.00-9.00   sec   112 MBytes   942 Mbits/sec                  
[  5]   9.00-10.00  sec   112 MBytes   942 Mbits/sec                  
[  5]  10.00-10.02  sec  1.83 MBytes   932 Mbits/sec                  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  5]   0.00-10.02  sec  1003 MBytes   840 Mbits/sec    0             sender
[  5]   0.00-10.02  sec  1000 MBytes   837 Mbits/sec                  receiver

So better enjoy defaults unless you really know what you do since network performance tuning works in different directions. Stuff that might increase throughput might negatively affect latency and vice versa. So if you start to tune, tune for your specific use case!

  Just want to check what the recommended approach is with today's dist-upgrade.

I noticed that armbian-bsp-cli-pine64 was held back, so tried a manual install to see what the problem was.

Seems like apt wants to remove linux-focal-root-current-pine64 to upgrade armbian-bsp-cli-pine64.

  Is this a temporary dependency issue?

Obviously not performing the upgrade unless informed of the correct approach.

BR.

   I have a couple of these boards which I have been using with Armbian and the old, 3.10 kernel. Ideally I would really like to go mainline as later kernels have some functionality that would be useful for my use of the board. The only remaining reason (apart from cpu freq.) for sticking to the 3.10 kernel has been the lack of MIPI DSI support in mainline, but now I see that, despite the Matrix at http://linux-sunxi.org/Linux_mainlining_effort still being red for A64 mipi, some work is being/has been done by Maxime Ripard.

I'm just wondering if anyone here knows if a working mainline kernel with DSI for the Pine 64 is starting to look like a possibility and if it might be possible to include in an armbian build.  I might be able to do some testing of anyone can guide me in making a build with the necessary patches.

'apt-get update' followed by 'apt-get upgrade'

The update went fine (no error messages) and i rebooted the unit.

The unit was unable to mount the root filesystem it complaint about UUID probably

incorrect, but this was not the case. After doing some research i found out that the DTB

file was changed on the mmc0 part. The option 'non-removable' was removed wich let to

the kernel using the PUSH-PUSH routine? cd pins to see if a SD card is present.

It looks like it that not all versions of the Pine A64-LTS have this pin or maybe in the past

had a faulty batch? Anyway to fix the problem i had to add 'non-removable' again to the

DTB which probably switches the way the detection works and probably uses the

standard CD-detect routine to see if a card is present.

I also noticed other people seeing this problem in u-boot and other places. See one of

those reference here:

https://www.spinics.net/lists/devicetree/msg418000.html

Maybe this get fixed automatically upstream? But maybe in the meantime Armbian

maintainers can set a special fix in the dtb and/or overlay for the Pine A64-LTS.

The specific steps i took now to fix the problem where:

1. Make a back-up off the DTB file

    cp /boot/dtb/allwinner/sun50i-a64-pine64-lts.dtb /boot/dtb/allwinner/sun50i-a64-pine64-lts.dtb-orig

2. Convert the DTB file that is used to dts (IGNORING the warnings from dtc conversion)

    dtc -I dtb -O dts -o sun50i-a64-pine64-lts.dts sun50i-a64-pine64-lts.dtb

3. Edit the file 'sun50i-a64-pine64-lts.dts' at the position starting somewhere along line number  12230

Change:

             mmc@1c0f000 {
                        compatible = "allwinner,sun50i-a64-mmc";
                        reg = < 0x1c0f000 0x1000 >;
                        clocks = < 0x02 0x1f 0x02 0x4b >;
                        clock-names = "ahb\0mmc";
                        resets = < 0x02 0x08 >;
                        reset-names = "ahb";
                        interrupts = < 0x00 0x3c 0x04 >;
                        max-frequency = < 0x8f0d180 >;
                        status = "okay";
                        bus-width = < 0x04 >;
                        #address-cells = < 0x01 >;
                        #size-cells = < 0x00 >;
                        pinctrl-names = "default";
                        pinctrl-0 = < 0x25 >;
                        vmmc-supply = < 0x26 >;
                        disable-wp;
                        cd-gpios = < 0x27 0x05 0x06 0x01 >;
                        phandle = < 0x69 >;
                };

Into:

              mmc@1c0f000 {
                        compatible = "allwinner,sun50i-a64-mmc";
                        reg = < 0x1c0f000 0x1000 >;
                        clocks = < 0x02 0x1f 0x02 0x4b >;
                        clock-names = "ahb\0mmc";
                        resets = < 0x02 0x08 >;
                        reset-names = "ahb";
                        interrupts = < 0x00 0x3c 0x04 >;
                        max-frequency = < 0x8f0d180 >;
                        status = "okay";
                        bus-width = < 0x04 >;
                        #address-cells = < 0x01 >;
                        #size-cells = < 0x00 >;
                        pinctrl-names = "default";
                        pinctrl-0 = < 0x25 >;
                        vmmc-supply = < 0x26 >;
                        disable-wp;
                        non-removable;
                        cd-gpios = < 0x27 0x05 0x06 0x01 >;
                        phandle = < 0x69 >;
                };

Notice how i added 'non-removable;' between the 'disable-wp;' and 'cd-gpios = < 0x27 0x05 0x06 0x01 >;' lines.

4. Convert the DTS file that we have just editted to the DTB format (IGNORING the warnings from dtc conversion)

    dtc -I dts -O dtb -o sun50i-a64-pine64-lts.dtb sun50i-a64-pine64-lts.dts

5. Boot the unit with the new changes. it should now boot fine.

I hope someone can help me with an annoying but not pressing eMMC boot problem.

Recently I bought myself a Pin64 H64 3GB SBC  and an 32GB eMMC module (actually ordered a 16GB but got a 32GB :-) )  I have a Waveshare 7" TFT touchscreen attached.  SBC and Screen are powered either a 5V/3A PSU or a batterypack.

Now the board boots fine and fast! from a Samsung EVO sd card .. no problems there, but I cannot get the board to boot from the eMMC module.

What I have done so far:

1) Flash an Armbian Buster image to the eMMC (using a USB_eMMC converter) with Etcher on Linux Mint...  Boot the board from eMMC WITHOUT sd card installed.  The system hangs when the kernel is started.. see attached picture and u-boot output.

2) Wipe the whole eMMC clean, format as ext4.  Install it on the board, insert sd card .. boot the board.. OK..  try 'nand-sata-install' from cli  or armbian-config->system->install ...   both methods just hang instantly.

Apart from these boot attempts I tried to access the (ext4 formatted) eMMC module after bootup from sd.  But I do not see the device in the 'mount'  output or /dev/disk/by-uuid  listing.

Is there anything else I can verify/try ?   The eMMC module 'seems' to be functioning fine in the USB_eMMC converter ? 

Best regards and a big thank you to the dev team for Armbian.. it's running very swiftly !  Well worth my (first) donation :-)

Dirk,

Netherlands

Armbian_boot_eMMC.txt

The file /boot/config-5.9.8-sunxi64 shows that only camera sensors OV2640 and MT9V011 are available and CONFIG_VIDEO_S5K4ECGX is not set. Is this an issue with the build?

and since having problems with high kworker load and strange warning in dmesg output:

[    7.734729] ------------[ cut here ]------------
[    7.737084] WARNING: CPU: 1 PID: 30 at drivers/clocksource/arm_arch_timer.c:360 sun50i_a64_read_cntpct_el0+0x24/0x30
[    7.738928] Modules linked in: cpufreq_dt realtek axp20x_usb_power industrialio pinctrl_axp209 dw_hdmi_cec lima dw_hdmi_i2s_audio gpu_sched dwmac_sun8i mdio_mux
[    7.741485] CPU: 1 PID: 30 Comm: kworker/1:1 Not tainted 5.4.20-sunxi64 #20.02.1
[    7.743435] Hardware name: Pine64 LTS (DT)
[    7.745514] Workqueue: events dbs_work_handler
[    7.747504] pstate: 80000005 (Nzcv daif -PAN -UAO)
[    7.749508] pc : sun50i_a64_read_cntpct_el0+0x24/0x30
[    7.751489] lr : arch_counter_get_cntpct_stable+0x38/0x78
[    7.753420] sp : ffff8000110739c0
[    7.755295] x29: ffff8000110739c0 x28: ffff0000721e6200 
[    7.757379] x27: ffff00007246a200 x26: ffff000077b77098 
[    7.759351] x25: 0000000000000000 x24: 00000000ffffffff 
[    7.761348] x23: 0000000000000001 x22: ffff800011073b10 
[    7.763352] hrtimer: interrupt took 26239875 ns
[    7.765224] x21: 0000000000000000 x20: 0000000000000018 
[    7.767278] x19: ffff800010f4f000 x18: 0000000000000001 
[    7.769323] x17: 0000000000000018 x16: 0000000000000002 
[    7.771285] x15: 0000000000000001 x14: 0000000000000001 
[    7.773271] x13: 0000000000000005 x12: 0000000000000021 
[    7.775229] x11: 0000000000000005 x10: 00000000bcd3d800 
[    7.777217] x9 : 0000000000000004 x8 : 0000000000000004 
[    7.779167] x7 : ffff800010f1b5a0 x6 : 00000000112a8800 
[    7.781121] x5 : 0000000000000010 x4 : 000000000000ffff 
[    7.783220] x3 : 0000000000000050 x2 : 000000001ad70336 
[    7.785255] x1 : 0000000000000000 x0 : 000000001ad7033c 
[    7.787272] Call trace:
[    7.789327]  sun50i_a64_read_cntpct_el0+0x24/0x30
[    7.791318]  __delay+0x20/0xa0
[    7.793261]  __udelay+0x28/0x30
[    7.795273]  ccu_mux_notifier_cb+0x5c/0x90
[    7.797319]  notifier_call_chain+0x54/0x90
[    7.799359]  __srcu_notifier_call_chain+0x54/0x90
[    7.801372]  srcu_notifier_call_chain+0x14/0x20
[    7.803396]  __clk_notify+0x88/0xc8
[    7.805373]  clk_propagate_rate_change+0xb8/0xd0
[    7.807431]  clk_core_set_rate_nolock+0x114/0x1b8
[    7.809441]  clk_set_rate+0x34/0xa0
[    7.811426]  dev_pm_opp_set_rate+0x260/0x498
[    7.813493]  set_target+0x3c/0x80 [cpufreq_dt]
[    7.815441]  __cpufreq_driver_target+0x18c/0x580
[    7.817405]  od_dbs_update+0x138/0x190
[    7.819404]  dbs_work_handler+0x3c/0x70
[    7.821455]  process_one_work+0x1ec/0x370
[    7.823545]  worker_thread+0x4c/0x4f8
[    7.825518]  kthread+0x120/0x128
[    7.827490]  ret_from_fork+0x10/0x18
[    7.829444] ---[ end trace 869ed0a5cc6097b4 ]---

I have traced the high kworker load back to the cpufreq-dt module. When unloading this

module the high kworker load stops and system is usable again. As a workaround turning off

ondemand governor and selecting performance governor looked like it did the job.

But on other units with an X graphics desktop i get a much higher kworker load and the system

becomes unusable (slow). The only thing that works all the time is unloading the cpufreq-dt

module.

The LCD output is working fine across reboots after enabling the dt overlay using armbian-config.

For the touchscreen, I have added "goodix" to /etc/modules and the digitizer works fine from all cold boots:

~$ dmesg | grep -i goodix
[    5.836601] Goodix-TS 1-005d: supply VDDIO not found, using dummy regulator
[    5.843605] Goodix-TS 1-005d: ID k}\xfa, version: 7b6f
[    5.866815] input: Goodix Capacitive TouchScreen as /devices/platform/soc/1c2ac00.i2c/i2c-1/1-005d/input/input5

but a reboot leads to either:

[    5.856172] Goodix-TS 1-005d: supply VDDIO not found, using dummy regulator
[    5.856668] Goodix-TS 1-005d: i2c test failed attempt 1: -6
[    5.886780] Goodix-TS 1-005d: ID k}\xfa, version: 7b6f
[    5.909817] input: Goodix Capacitive TouchScreen as /devices/platform/soc/1c2ac00.i2c/i2c-1/1-005d/input/input5

and the screen works

or:

$ dmesg | grep -i goodix
[    5.862909] Goodix-TS 1-005d: supply VDDIO not found, using dummy regulator
[    5.864033] Goodix-TS 1-005d: i2c test failed attempt 1: -6
[    5.889397] Goodix-TS 1-005d: i2c test failed attempt 2: -6
[    5.925072] Goodix-TS 1-005d: I2C communication failure: -6

a double reboot works.

It looks like the i2c bus is not being completely reset in time, but that multiple connection attempts  sometimes succeed.

Can anyone suggest a workaround, to force a reset, add more i2c test iterations or provide more time to load from reboot?

BR.

Thanks to the hard work of your team, the Pine64-plus touchscreen now works great with the mainline kernel and legacy images are no longer listed in the download options, but it looks like some of the instructions at https://www.armbian.com/pine64/

are still referring to the "old way" of doing things:

ie:

Pine64’s own LCD with touchscreen support can simply be activated in /boot/armbianEnv.txt by setting pine64_lcd=on and adding gt9xxf_ts to /etc/modules followed by a reboot.

The LCD screen is now activated by manipulating the DT overlays, which can even be done from armbian-config - hardware, and the touchscreen module is now called "goodix".

 Please can someone find the time to update the instructions on the page?

BR.

Error while loading shared libraries: lib system-shares-241.so: cannot open shared object file: No such file or directory
Kernel panic - not syncing: Attempted to kill init! exitcode=0x00007f00
CPU: 1 PID: 1 Comm: init Not tainted 5.4.43-sunxi64 #20.05.2
Hardware name: Pine64+ (DT)
Call trace:
dump_backtrace+0x0/0x180
show_stack+0x14/0x20
dump_stack+0xb0/0xd8
panic+0x144/0x310
do_exit+0x974/0x9a8
do_group_exit+0x40/0xa8
_arm64_sys_exit_group+0x14/0x18
el0_svc_common.constprop.2+0x88/0x150
el0_svc_handler+0x20/0x80
el0_svc+0x8/0xc
SMP: stopping secondary CPUs
Kernel Offset: disabled
CPU features: 0x0002,24002004
Memory Limit: none

I took the card over to my laptop and ran fsck which found no problems. I would rather fix the issue if is possible, but I have no idea how to do it. Is is possible? Or should I just create a new card?

Best, 

  Thank you all for so much work to fully implement the mainline kernel for the Pine64!

So much is now working out-of-the-box with armbian, that there is no need to use the legacy version based on kernel 3.10.

The pine64 does have CIR capabilities and the sunxi-cir kernel module is available, but we are still missing DT bindings for the device, although I see that an overlay file is present for the h5:

/dts-v1/;

/ {
        compatible = "allwinner,sun50i-h5";

        fragment@0 {
                target = <0xffffffff>;

                __overlay__ {
                        pinctrl-names = "default";
                        pinctrl-0 = <0xffffffff>;
                        status = "okay";
                };
        };

        __fixups__ {
                ir = "/fragment@0:target:0";
                r_ir_rx_pin = "/fragment@0/__overlay__:pinctrl-0:0";
        };
};
/tmp/sun50i-h5-cir.dtbs (END) 

I would be very happy to try to implement and test this, if anyone can suggest changes to the overlay code, to shoehorn it into the pine64-plus DT. 

Update:

I did try the obvious, simple approach of changing the compatible line to compatible = "allwinner,sun50i-a64"

, recompiling and changing the filename to

/boot/overlay-user/sun50i-a64-pine64-cir.dtbo

but this looks like it messes up the official 7 inch lcd overlay (blank screen) that otherwise loads fine. So looks like it needs more changes.

Many thanks in advance for any suggestions!

BR.

My understanding is that this has been an issue for a while with A64 boards, specifically the Pine64, but that it was working at one time.

Here's what I've tried so far:

-Followed instructions at https://docs.armbian.com/Hardware_Allwinner/  and added "setenv video-mode sunxi:480x272-24@60,monitor=lcd,hpd=1,edid=1" to boot.cmd and put "saveenv" at the end, re-compiled boot.scr

-Did a modprobe of panel-olimex-lcd-olinuxino

-Rebooted several times

-Ensured that LCD jumper was closed and verified LCD was working with Olimex builds.

Screen flickers at startup then stays white.

Any thoughts?

I'm using the Sopine A64 Armbian Buster image version 5.91 in combination with my PineA64-LTS SBC. First off I'd like to say that it runs great, thank you guys very much for providing this fully featured image and thereby keeping this SBC up to date!

For the last few weeks I've been trying to get the Pine 64 7" LCD screen to work with it, but so far unfortunately I haven't been able to.

What I've tried:

• Follow instructions to get LCD working as stated on the older brother's PineA64 page: add 'pine64_lcd=on' to /boot/armbianEnv.txt, and add 'gt9xxf_ts' to /etc/modules, then reboot. No luck.
• Read about the Allwinner Overlays and try to understand how they work. Decompile both 'sun50i-a64-pine64.dtb' and 'sun50i-a64-pine64-lts.dtb' (found in /boot/dtb/allwinner/), search for 'lcd' in both .dts files and compare. I noticed some differences in addresses but wouldn't know which of those are correct or incorrect.
• Add the decompiled 'sun50i-a64-pine64.dts' as user-overlay through 'sudo armbian-add-overlay sun50i-a64-pine64.dts', then reboot. System still booted, but no working LCD screen.

and that's about how far my knowledge goes, without really just going into the realm of trying random things

Is there anyone that managed to got the aforementioned combination of hardware to work? Or anyone that could give me any pointers on what to try next? I'm very much willing to put time and effort into this, I just don't know where to start/what to try next.

Thanks a lot in advance for any assistance.

Current Version:  ARMBIAN 5.83 stable Debian GNU/Linux 9 (stretch) 4.19.38-sunxi64

- I have tried 2 boards in case its a hardware issue, no go.

- Ethernet works with Armbian Xenial (3.10 legacy kernel)

- The network port shows activity when initially powering up, but when it begins boot lights go out.

- I have tried many older and newer kernels, including the new 5.1.0 dev kernel, with no luck.

- Eth0 show up with command "ip address" but not with "ifconfig"

- When I try running "sudo ethtool eth0" I get errors with "Device or resource busy"

I would like to drop back to the previous kernel if possible.

Does this seem like a reasonable search term for a suitable kernel?

Any ideas on searching and installing a previous kernel appreciated.

sudo apt-cache search kernel 5.8* | grep sunxi64
linux-dtb-current-sunxi64 - Linux DTB, version 5.8.13-sunxi64
linux-dtb-dev-sunxi64 - Linux DTB, version 5.9.0-rc7-sunxi64
linux-dtb-legacy-sunxi64 - Linux DTB, version 5.4.62-sunxi64
linux-headers-current-sunxi64 - Linux kernel headers for 5.8.13-sunxi64 on arm64
linux-headers-dev-sunxi64 - Linux kernel headers for 5.9.0-rc7-sunxi64 on arm64
linux-headers-legacy-sunxi64 - Linux kernel headers for 5.4.62-sunxi64 on arm64
linux-image-current-sunxi64 - Linux kernel, version 5.8.13-sunxi64
linux-image-dev-sunxi64 - Linux kernel, version 5.9.0-rc7-sunxi64
linux-image-legacy-sunxi64 - Linux kernel, version 5.4.62-sunxi64
linux-source-5.4.58-legacy-sunxi64 - This package provides the source code for the Linux kernel 5.4.58
linux-source-5.4.61-legacy-sunxi64 - This package provides the source code for the Linux kernel 5.4.61

[   23.475944] ------------[ cut here ]------------

[   23.478571] WARNING: CPU: 3 PID: 171 at drivers/clocksource/arm_arch_timer.c:364 sun50i_a64_read_cntpct_el0+0x30/0x38
[   23.480502] Modules linked in: cpufreq_dt realtek dwmac_sun8i pinctrl_axp209 mdio_mux i2c_mv64xxx
[   23.483003] CPU: 3 PID: 171 Comm: kworker/3:3 Not tainted 5.8.13-sunxi64 #20.08.7
[   23.484968] Hardware name: Pine64+ (DT)
[   23.487226] Workqueue: events dbs_work_handler
[   23.489416] pstate: 80000005 (Nzcv daif -PAN -UAO BTYPE=--)
[   23.491571] pc : sun50i_a64_read_cntpct_el0+0x30/0x38
[   23.493700] lr : arch_counter_get_cntpct_stable+0x3c/0x80
[   23.495784] sp : ffff800011afb9c0
[   23.497758] x29: ffff800011afb9c0 x28: ffff0000743a9a00
[   23.499861] x27: ffff0000713ed600 x26: ffff0000743a9c68
[   23.501992] x25: ffff000072e38228 x24: 0000000000000000
[   23.504054] x23: 0000000000000001 x22: ffff800011afbb10
[   23.506137] x21: 0000000000000000 x20: 0000000000000018
[   23.508260] x19: ffff8000113dd000
[   23.510328] hrtimer: interrupt took 27046125 ns
[   23.512242] x18: ffff800011afb9b8
[   23.514290] x17: 0000000000000004 x16: 0000000000000001
[   23.516399] x15: 0000000000000018 x14: 0000000000000002
[   23.518455] x13: 0000000000000001 x12: 0000000000000001
[   23.520483] x11: 0000000000000005 x10: 0000000000000021
[   23.522575] x9 : 0000000044aa2000 x8 : ffff8000113aaf98
[   23.524628] x7 : 0000000000000000 x6 : 00000000112a8800
[   23.526731] x5 : 0000000000000010 x4 : 0000000000000012
[   23.528810] x3 : 0000000000000050 x2 : 000000002ec5d477
[   23.530879] x1 : 0000000000000000 x0 : 000000002ec5d47d
[   23.532925] Call trace:
[   23.535068]  sun50i_a64_read_cntpct_el0+0x30/0x38
[   23.537130]  __delay+0x24/0xa8
[   23.539201]  __udelay+0x2c/0x38
[   23.541332]  ccu_mux_notifier_cb+0x64/0xa0
[   23.543415]  notifier_call_chain+0x54/0x98
[   23.545482]  __srcu_notifier_call_chain+0x58/0x98
[   23.547538]  srcu_notifier_call_chain+0x18/0x28
[   23.549615]  __clk_notify+0x88/0xd0
[   23.551707]  clk_propagate_rate_change+0xc4/0xd8
[   23.553808]  clk_core_set_rate_nolock+0x114/0x1f8
[   23.555895]  clk_set_rate+0x38/0xa8
[   23.558113]  dev_pm_opp_set_rate+0x264/0x618
[   23.560250]  set_target+0x40/0x88 [cpufreq_dt]
[   23.562349]  __cpufreq_driver_target+0x2c4/0x668
[   23.564464]  od_dbs_update+0x140/0x1a0
[   23.566542]  dbs_work_handler+0x40/0x80
[   23.568628]  process_one_work+0x1c8/0x378
[   23.570711]  worker_thread+0x14c/0x4c8
[   23.572806]  kthread+0xf8/0x128
[   23.574887]  ret_from_fork+0x10/0x30
[   23.576963] ---[ end trace 32a37354cad394e6 ]---
[   23.735669] sun8i-ce 1c15000.crypto: Set mod clock to 300000000 (300 Mhz) from 24000000 (24 Mhz)
[   23.735961] sun8i-ce 1c15000.crypto: will run requests pump with realtime priority

I'm a bit confused, i have a PINE64 board ("PINE A64+", 2GB mem.) (this one : https://www.pine64.org/?product=sopine-a64-baseboard-combo)

I installed some years ago ARMBIAN on it - everything is running fine.

But i'm still on kernel 3.X something : 

```

uname -a
Linux pine64 3.10.107-pine64 #2 SMP PREEMPT Fri Feb 8 10:23:10 CET 2019 aarch64 GNU/Linux
 

cat /etc/armbian.txt

-------------------------------------------------------------------------------
Title:                  Armbian 5.73 Pine64 Debian jessie default
Kernel:                 Linux 3.10.107
Build date:             28.01.2019
...

```

Of course my whole system is up-to-date and has been switched from `jessie` to `stretch` and recently to `buster` (= apt-get update, upgrade, dist-upgrade done).

What am i supposed to do to have a newer kernel (i would need 4.x in order to be able to use `overlay2` docker storage engine) ?

Thanks in advance for any help.

https://dl.armbian.com/pine64so/Focal_current

If the LCD is connected via the DSI port, the boot freezes during UBoot. If I disconnect the LCD from the DSI connector, we get past the first part of UBoot immediately and it eventually brings me to the login prompt.

I do observe that the green power LED appears to light then turn off about when it freezes on boot with the DSI connector attached. I have the official 5 V 2 A SOPINE supply from the store (https://store.pine64.org/product/sopine-baseboard-us-power-supply/).

Has anyone seen anything like this before?

Cheers

U-Boot 2019.01-armbian (Apr 08 2019 - 01:44:37 +0200) Allwinner Technology

CPU:   Allwinner H6 (SUN50I)
Model: Pine H64
DRAM:  3 GiB
MMC:   SUNXI SD/MMC: 0, SUNXI SD/MMC: 1
Loading Environment from FAT... Unable to use mmc 1:1... In:    serial@5000000
Out:   serial@5000000
Err:   serial@5000000
Net:   No ethernet found.
starting USB...
No controllers found
Hit any key to stop autoboot:  0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found U-Boot script /boot/boot.scr
3042 bytes read in 27 ms (109.4 KiB/s)
## Executing script at 4fc00000
U-boot loaded from SD
Boot script loaded from mmc
165 bytes read in 23 ms (6.8 KiB/s)
26173 bytes read in 91 ms (280.3 KiB/s)
4161 bytes read in 104 ms (39.1 KiB/s)
Applying kernel provided DT fixup script (sun50i-h6-fixup.scr)
## Executing script at 44000000
8711420 bytes read in 911 ms (9.1 MiB/s)
14436360 bytes read in 1492 ms (9.2 MiB/s)
## Loading init Ramdisk from Legacy Image at 4fe00000 ...
   Image Name:   uInitrd
   Image Type:   AArch64 Linux RAMDisk Image (gzip compressed)
   Data Size:    8711356 Bytes = 8.3 MiB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 4fa00000
   Booting using the fdt blob at 0x4fa00000
   Loading Ramdisk to 497b1000, end 49fffcbc ... OK
   reserving fdt memory region: addr=4fa00000 size=6c000
   Loading Device Tree to 0000000049742000, end 00000000497b0fff ... OK

Starting kernel ...

[    0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]
[    0.000000] Linux version 5.0.7-sunxi64 (root@nightly) (gcc version 7.4.1 20181213 [linaro-7.4-2019.02 revision 56ec6f6b99cc167ff0c2f8e1a2eed33b1edc85d4] (Linaro GCC 7.4-2019.02)) #5.78.190413 SMP Sat Apr 13 01:24:27 CEST 2019
[    0.000000] Machine model: Pine H64
[    0.000000] cma: Reserved 128 MiB at 0x00000000f8000000
[    0.000000] NUMA: No NUMA configuration found
[    0.000000] NUMA: Faking a node at [mem 0x0000000040000000-0x00000000ffffffff]
[    0.000000] NUMA: NODE_DATA [mem 0xf79d9840-0xf79dafff]
[    0.000000] Zone ranges:
[    0.000000]   DMA32    [mem 0x0000000040000000-0x00000000ffffffff]
[    0.000000]   Normal   empty
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x0000000040000000-0x00000000ffffffff]
[    0.000000] Initmem setup node 0 [mem 0x0000000040000000-0x00000000ffffffff]
[    0.000000] psci: probing for conduit method from DT.
[    0.000000] psci: PSCIv1.1 detected in firmware.
[    0.000000] psci: Using standard PSCI v0.2 function IDs
[    0.000000] psci: MIGRATE_INFO_TYPE not supported.
[    0.000000] psci: SMC Calling Convention v1.1
[    0.000000] random: get_random_bytes called from start_kernel+0xa8/0x3f0 with crng_init=0
[    0.000000] percpu: Embedded 22 pages/cpu @(____ptrval____) s52952 r8192 d28968 u90112
[    0.000000] Detected VIPT I-cache on CPU0
[    0.000000] CPU features: detected: ARM erratum 845719
[    0.000000] Speculative Store Bypass Disable mitigation not required
[    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 774144
[    0.000000] Policy zone: DMA32
[    0.000000] Kernel command line: root=UUID=ebfa02c2-3f5d-4b27-bb44-1efd898b9c6f rootwait rootfstype=ext4 console=ttyS0,115200 console=tty1 panic=10 consoleblank=0 loglevel=7 ubootpart=3ec23de2-01 usb-storage.quirks=0x2537:0x1066:u,0x2537:0x1068:u   cgroup_enable=memory swapaccount=1
[    0.000000] printk: log_buf_len individual max cpu contribution: 4096 bytes
[    0.000000] printk: log_buf_len total cpu_extra contributions: 12288 bytes
[    0.000000] printk: log_buf_len min size: 16384 bytes
[    0.000000] printk: log_buf_len: 32768 bytes
[    0.000000] printk: early log buf free: 13808(84%)
[    0.000000] Memory: 2935272K/3145728K available (10238K kernel code, 722K rwdata, 2504K rodata, 576K init, 288K bss, 79384K reserved, 131072K cma-reserved)
[    0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
[    0.000000] rcu: Hierarchical RCU implementation.
[    0.000000] rcu:     RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=4.
[    0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies.
[    0.000000] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=4
[    0.000000] NR_IRQS: 64, nr_irqs: 64, preallocated irqs: 0
[    0.000000] GIC: Using split EOI/Deactivate mode
[    0.000000] arch_timer: cp15 timer(s) running at 24.00MHz (phys).
[    0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x588fe9dc0, max_idle_ns: 440795202592 ns
[    0.000004] sched_clock: 56 bits at 24MHz, resolution 41ns, wraps every 4398046511097ns
[    0.000217] Console: colour dummy device 80x25
[    0.000553] printk: console [tty1] enabled
[    0.000625] Calibrating delay loop (skipped), value calculated using timer frequency.. 48.00 BogoMIPS (lpj=96000)
[    0.000646] pid_max: default: 32768 minimum: 301
[    0.000734] LSM: Security Framework initializing
[    0.000751] AppArmor: AppArmor disabled by boot time parameter
[    0.002318] Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes)
[    0.003113] Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes)
[    0.003170] Mount-cache hash table entries: 8192 (order: 4, 65536 bytes)
[    0.003222] Mountpoint-cache hash table entries: 8192 (order: 4, 65536 bytes)
[    0.004461] ASID allocator initialised with 32768 entries
[    0.004540] rcu: Hierarchical SRCU implementation.
[    0.005051] smp: Bringing up secondary CPUs ...
[    0.005739] Detected VIPT I-cache on CPU1
[    0.005788] CPU1: Booted secondary processor 0x0000000001 [0x410fd034]
[    0.006370] Detected VIPT I-cache on CPU2
[    0.006398] CPU2: Booted secondary processor 0x0000000002 [0x410fd034]
[    0.006960] Detected VIPT I-cache on CPU3
[    0.006987] CPU3: Booted secondary processor 0x0000000003 [0x410fd034]
[    0.007050] smp: Brought up 1 node, 4 CPUs
[    0.007102] SMP: Total of 4 processors activated.
[    0.007113] CPU features: detected: 32-bit EL0 Support
[    0.007124] CPU features: detected: CRC32 instructions
[    0.007371] CPU: All CPU(s) started at EL2
[    0.007393] alternatives: patching kernel code
[    0.008954] devtmpfs: initialized
[    0.013510] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
[    0.013560] futex hash table entries: 1024 (order: 4, 65536 bytes)
[    0.017717] xor: measuring software checksum speed
[    0.056091]    8regs     :  1750.000 MB/sec
[    0.096130]    32regs    :  2151.000 MB/sec
[    0.136174]    arm64_neon:  1907.000 MB/sec
[    0.136185] xor: using function: 32regs (2151.000 MB/sec)
[    0.136249] pinctrl core: initialized pinctrl subsystem
[    0.136976] NET: Registered protocol family 16
[    0.137437] audit: initializing netlink subsys (disabled)
[    0.137584] audit: type=2000 audit(0.136:1): state=initialized audit_enabled=0 res=1
[    0.138029] cpuidle: using governor menu
[    0.138264] vdso: 2 pages (1 code @ (____ptrval____), 1 data @ (____ptrval____))
[    0.138282] hw-breakpoint: found 6 breakpoint and 4 watchpoint registers.
[    0.139376] DMA: preallocated 256 KiB pool for atomic allocations
[    0.139468] Serial: AMBA PL011 UART driver
[    0.149330] HugeTLB registered 1.00 GiB page size, pre-allocated 0 pages
[    0.149356] HugeTLB registered 32.0 MiB page size, pre-allocated 0 pages
[    0.149369] HugeTLB registered 2.00 MiB page size, pre-allocated 0 pages
[    0.149381] HugeTLB registered 64.0 KiB page size, pre-allocated 0 pages
[    0.149822] cryptd: max_cpu_qlen set to 1000
[    0.216341] raid6: neonx8   gen()  1254 MB/s
[    0.284427] raid6: neonx8   xor()  1169 MB/s
[    0.352541] raid6: neonx4   gen()  1157 MB/s
[    0.420582] raid6: neonx4   xor()  1103 MB/s
[    0.488732] raid6: neonx2   gen()   887 MB/s
[    0.556760] raid6: neonx2   xor()   924 MB/s
[    0.624888] raid6: neonx1   gen()   553 MB/s
[    0.692966] raid6: neonx1   xor()   654 MB/s
[    0.761112] raid6: int64x8  gen()   749 MB/s
[    0.829153] raid6: int64x8  xor()   572 MB/s
[    0.897257] raid6: int64x4  gen()   792 MB/s
[    0.965358] raid6: int64x4  xor()   583 MB/s
[    1.033505] raid6: int64x2  gen()   517 MB/s
[    1.101545] raid6: int64x2  xor()   460 MB/s
[    1.169663] raid6: int64x1  gen()   337 MB/s
[    1.237700] raid6: int64x1  xor()   339 MB/s
[    1.237711] raid6: using algorithm neonx8 gen() 1254 MB/s
[    1.237720] raid6: .... xor() 1169 MB/s, rmw enabled
[    1.237730] raid6: using neon recovery algorithm
[    1.238696] SCSI subsystem initialized
[    1.238860] usbcore: registered new interface driver usbfs
[    1.238904] usbcore: registered new interface driver hub
[    1.238971] usbcore: registered new device driver usb
[    1.239201] pps_core: LinuxPPS API ver. 1 registered
[    1.239213] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
[    1.239240] PTP clock support registered
[    1.240232] clocksource: Switched to clocksource arch_sys_counter
[    1.240365] VFS: Disk quotas dquot_6.6.0
[    1.240427] VFS: Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[    1.245916] NET: Registered protocol family 2
[    1.246431] tcp_listen_portaddr_hash hash table entries: 2048 (order: 3, 32768 bytes)
[    1.246548] TCP established hash table entries: 32768 (order: 6, 262144 bytes)
[    1.246906] TCP bind hash table entries: 32768 (order: 7, 524288 bytes)
[    1.247417] TCP: Hash tables configured (established 32768 bind 32768)
[    1.247551] UDP hash table entries: 2048 (order: 4, 65536 bytes)
[    1.247666] UDP-Lite hash table entries: 2048 (order: 4, 65536 bytes)
[    1.247900] NET: Registered protocol family 1
[    1.248327] RPC: Registered named UNIX socket transport module.
[    1.248340] RPC: Registered udp transport module.
[    1.248350] RPC: Registered tcp transport module.
[    1.248359] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    1.248577] Unpacking initramfs...
[    1.685538] Freeing initrd memory: 8504K
[    1.836446] Initialise system trusted keyrings
[    1.836621] workingset: timestamp_bits=44 max_order=20 bucket_order=0
[    1.841274] zbud: loaded
[    1.842544] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[    1.843194] NFS: Registering the id_resolver key type
[    1.843223] Key type id_resolver registered
[    1.843232] Key type id_legacy registered
[    1.843248] nfs4filelayout_init: NFSv4 File Layout Driver Registering...
[    1.843260] Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
[    1.844039] 9p: Installing v9fs 9p2000 file system support
[    1.973624] NET: Registered protocol family 38
[    1.976426] Key type asymmetric registered
[    1.976448] Asymmetric key parser 'x509' registered
[    1.976512] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 248)
[    1.976697] io scheduler mq-deadline registered
[    1.976710] io scheduler kyber registered
[    1.976862] io scheduler bfq registered
[    1.977130] sun50i-de2-bus 1000000.display-engine: Error couldn't map SRAM to device
[    1.977707] sun4i-usb-phy 5100400.phy: Couldn't get regulator usb0_vbus... Deferring probe
[    1.978024] sun50i-usb3-phy 5210000.phy: failed to get phy clock
[    1.981505] sun50i-h6-r-pinctrl 7022000.pinctrl: initialized sunXi PIO driver
[    1.988477] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
[    1.991290] cacheinfo: Unable to detect cache hierarchy for CPU 0
[    1.995246] loop: module loaded
[    1.996215] libphy: Fixed MDIO Bus: probed
[    1.997736] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    1.997753] ehci-platform: EHCI generic platform driver
[    1.997902] ehci-platform 5101000.usb: EHCI Host Controller
[    1.997942] ehci-platform 5101000.usb: new USB bus registered, assigned bus number 1
[    1.998235] ehci-platform 5101000.usb: irq 18, io mem 0x05101000
[    2.012241] ehci-platform 5101000.usb: USB 2.0 started, EHCI 1.00
[    2.012438] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 5.00
[    2.012457] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    2.012472] usb usb1: Product: EHCI Host Controller
[    2.012484] usb usb1: Manufacturer: Linux 5.0.7-sunxi64 ehci_hcd
[    2.012497] usb usb1: SerialNumber: 5101000.usb
[    2.012939] hub 1-0:1.0: USB hub found
[    2.012977] hub 1-0:1.0: 1 port detected
[    2.013478] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[    2.013506] ohci-platform: OHCI generic platform driver
[    2.013640] ohci-platform 5101400.usb: Generic Platform OHCI controller
[    2.013665] ohci-platform 5101400.usb: new USB bus registered, assigned bus number 2
[    2.013900] ohci-platform 5101400.usb: irq 19, io mem 0x05101400
[    2.076546] usb usb2: New USB device found, idVendor=1d6b, idProduct=0001, bcdDevice= 5.00
[    2.076565] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    2.076580] usb usb2: Product: Generic Platform OHCI controller
[    2.076593] usb usb2: Manufacturer: Linux 5.0.7-sunxi64 ohci_hcd
[    2.076606] usb usb2: SerialNumber: 5101400.usb
[    2.076990] hub 2-0:1.0: USB hub found
[    2.077034] hub 2-0:1.0: 1 port detected
[    2.077777] usbcore: registered new interface driver usb-storage
[    2.078187] mousedev: PS/2 mouse device common for all mice
[    2.078613] sun6i-rtc 7000000.rtc: registered as rtc0
[    2.078627] sun6i-rtc 7000000.rtc: RTC enabled
[    2.078690] i2c /dev entries driver
[    2.078874] sun50i-h6-r-pinctrl 7022000.pinctrl: 7022000.pinctrl supply vcc-pl not found, using dummy regulator
[    2.078941] sun50i-h6-r-pinctrl 7022000.pinctrl: Linked as a consumer to regulator.0
[    2.079399] axp20x-i2c 0-0036: AXP20x variant AXP806 found
[    2.084709] input: axp20x-pek as /devices/platform/soc/7081400.i2c/i2c-0/0-0036/axp221-pek/input/input0
[    2.085832] dcdca: supplied by regulator-dummy
[    2.086864] dcdcc: supplied by regulator-dummy
[    2.087453] dcdcd: supplied by regulator-dummy
[    2.087925] vdd-sys: Bringing 900000uV into 960000-960000uV
[    2.088386] dcdce: supplied by regulator-dummy
[    2.088965] aldo1: supplied by regulator-dummy
[    2.089542] aldo2: supplied by regulator-dummy
[    2.090013] vcc-ac200: Bringing 700000uV into 3300000-3300000uV
[    2.090457] aldo3: supplied by regulator-dummy
[    2.090907] vcc-3v3-1: Bringing 700000uV into 3300000-3300000uV
[    2.091658] bldo1: supplied by regulator-dummy
[    2.092650] bldo2: supplied by regulator-dummy
[    2.093250] bldo3: supplied by regulator-dummy
[    2.093697] vcc-wifi-io: Bringing 700000uV into 1800000-1800000uV
[    2.094445] bldo4: supplied by regulator-dummy
[    2.095046] cldo1: supplied by regulator-dummy
[    2.095648] cldo2: supplied by regulator-dummy
[    2.096099] vcc-wifi-1: Bringing 700000uV into 3300000-3300000uV
[    2.096864] cldo3: supplied by regulator-dummy
[    2.097315] vcc-wifi-2: Bringing 700000uV into 3300000-3300000uV
[    2.098072] sw: supplied by regulator-dummy
[    2.098237] axp20x-i2c 0-0036: AXP20X driver loaded
[    2.098956] sun50i-h6-r-pinctrl 7022000.pinctrl: 7022000.pinctrl supply vcc-pm not found, using dummy regulator
[    2.099179] sdhci: Secure Digital Host Controller Interface driver
[    2.099190] sdhci: Copyright(c) Pierre Ossman
[    2.099221] Synopsys Designware Multimedia Card Interface Driver
[    2.099715] sdhci-pltfm: SDHCI platform and OF driver helper
[    2.100332] ledtrig-cpu: registered to indicate activity on CPUs
[    2.100612] hidraw: raw HID events driver (C) Jiri Kosina
[    2.100709] usbcore: registered new interface driver usbhid
[    2.100720] usbhid: USB HID core driver
[    2.101896] NET: Registered protocol family 10
[    2.122205] Segment Routing with IPv6
[    2.122311] NET: Registered protocol family 17
[    2.122485] 8021q: 802.1Q VLAN Support v1.8
[    2.122645] 9pnet: Installing 9P2000 support
[    2.122708] Key type dns_resolver registered
[    2.123319] registered taskstats version 1
[    2.123330] Loading compiled-in X.509 certificates
[    2.123414] zswap: loaded using pool lzo/zbud
[    2.124468] Btrfs loaded, crc32c=crc32c-generic
[    2.132812] Key type encrypted registered
[    2.141659] sun4i-usb-phy 5100400.phy: Linked as a consumer to regulator.18
[    2.142065] phy phy-5210000.phy.2: Linked as a consumer to regulator.18
[    2.146273] sun50i-h6-pinctrl 300b000.pinctrl: initialized sunXi PIO driver
[    2.146547] sun50i-h6-pinctrl 300b000.pinctrl: 300b000.pinctrl supply vcc-ph not found, using dummy regulator
[    2.146622] sun50i-h6-pinctrl 300b000.pinctrl: Linked as a consumer to regulator.0
[    2.146978] printk: console [ttyS0] disabled
[    2.167755] 5000000.serial: ttyS0 at MMIO 0x5000000 (irq = 15, base_baud = 1500000) is a 16550A
[    3.523441] printk: console [ttyS0] enabled
[    3.529347] sun4i-drm display-engine: bound 1100000.mixer (ops 0xffff000010b27968)
[    3.537053] sun4i-drm display-engine: bound 6510000.tcon-top (ops 0xffff000010b2bb50)
[    3.545126] sun4i-drm display-engine: bound 6515000.lcd-controller (ops 0xffff000010b24450)
[    3.553550] sun8i-dw-hdmi 6000000.hdmi: 6000000.hdmi supply hvcc not found, using dummy regulator
[    3.562468] sun8i-dw-hdmi 6000000.hdmi: Linked as a consumer to regulator.0
[    3.569623] sun8i-dw-hdmi 6000000.hdmi: Detected HDMI TX controller v2.12a with HDCP (DWC HDMI 2.0 TX PHY)
[    3.579698] sun8i-dw-hdmi 6000000.hdmi: registered DesignWare HDMI I2C bus driver
[    3.587432] sun4i-drm display-engine: bound 6000000.hdmi (ops 0xffff000010b26d20)
[    3.594923] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[    3.601539] [drm] No driver support for vblank timestamp query.
[    3.607712] [drm] Initialized sun4i-drm 1.0.0 20150629 for display-engine on minor 0
[    3.615499] [drm] Cannot find any crtc or sizes
[    3.620514] [drm] Cannot find any crtc or sizes
[    3.732493] xhci-hcd xhci-hcd.2.auto: xHCI Host Controller
[    3.738005] xhci-hcd xhci-hcd.2.auto: new USB bus registered, assigned bus number 3
[    3.746122] xhci-hcd xhci-hcd.2.auto: hcc params 0x0220f064 hci version 0x100 quirks 0x0000000002010010
[    3.755562] xhci-hcd xhci-hcd.2.auto: irq 20, io mem 0x05200000
[    3.761778] usb usb3: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 5.00
[    3.770052] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    3.777280] usb usb3: Product: xHCI Host Controller
[    3.782165] usb usb3: Manufacturer: Linux 5.0.7-sunxi64 xhci-hcd
[    3.788176] usb usb3: SerialNumber: xhci-hcd.2.auto
[    3.793456] hub 3-0:1.0: USB hub found
[    3.797243] hub 3-0:1.0: 1 port detected
[    3.801418] xhci-hcd xhci-hcd.2.auto: xHCI Host Controller
[    3.806921] xhci-hcd xhci-hcd.2.auto: new USB bus registered, assigned bus number 4
[    3.814591] xhci-hcd xhci-hcd.2.auto: Host supports USB 3.0  SuperSpeed
[    3.821269] usb usb4: We don't know the algorithms for LPM for this host, disabling LPM.
[    3.829481] usb usb4: New USB device found, idVendor=1d6b, idProduct=0003, bcdDevice= 5.00
[    3.837755] usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    3.844983] usb usb4: Product: xHCI Host Controller
[    3.849868] usb usb4: Manufacturer: Linux 5.0.7-sunxi64 xhci-hcd
[    3.855880] usb usb4: SerialNumber: xhci-hcd.2.auto
[    3.861084] hub 4-0:1.0: USB hub found
[    3.864866] hub 4-0:1.0: 1 port detected
[    3.869483] ehci-platform 5311000.usb: EHCI Host Controller
[    3.875081] ehci-platform 5311000.usb: new USB bus registered, assigned bus number 5
[    3.883152] ehci-platform 5311000.usb: irq 21, io mem 0x05311000
[    3.904247] ehci-platform 5311000.usb: USB 2.0 started, EHCI 1.00
[    3.910494] usb usb5: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 5.00
[    3.918769] usb usb5: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    3.925999] usb usb5: Product: EHCI Host Controller
[    3.930884] usb usb5: Manufacturer: Linux 5.0.7-sunxi64 ehci_hcd
[    3.936897] usb usb5: SerialNumber: 5311000.usb
[    3.941785] hub 5-0:1.0: USB hub found
[    3.945569] hub 5-0:1.0: 1 port detected
[    3.950068] ohci-platform 5311400.usb: Generic Platform OHCI controller
[    3.956707] ohci-platform 5311400.usb: new USB bus registered, assigned bus number 6
[    3.964662] ohci-platform 5311400.usb: irq 22, io mem 0x05311400
[    4.032502] usb usb6: New USB device found, idVendor=1d6b, idProduct=0001, bcdDevice= 5.00
[    4.040777] usb usb6: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    4.048006] usb usb6: Product: Generic Platform OHCI controller
[    4.053933] usb usb6: Manufacturer: Linux 5.0.7-sunxi64 ohci_hcd
[    4.059944] usb usb6: SerialNumber: 5311400.usb
[    4.064842] hub 6-0:1.0: USB hub found
[    4.068691] hub 6-0:1.0: 1 port detected
[    4.073372] usb_phy_generic usb_phy_generic.3.auto: usb_phy_generic.3.auto supply vcc not found, using dummy regulator
[    4.084148] usb_phy_generic usb_phy_generic.3.auto: Linked as a consumer to regulator.0
[    4.092422] musb-hdrc musb-hdrc.4.auto: MUSB HDRC host driver
[    4.098181] musb-hdrc musb-hdrc.4.auto: new USB bus registered, assigned bus number 7
[    4.106177] usb usb7: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 5.00
[    4.114455] usb usb7: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    4.121685] usb usb7: Product: MUSB HDRC host driver
[    4.126657] usb usb7: Manufacturer: Linux 5.0.7-sunxi64 musb-hcd
[    4.132669] usb usb7: SerialNumber: musb-hdrc.4.auto
[    4.138302] hub 7-0:1.0: USB hub found
[    4.142094] hub 7-0:1.0: 1 port detected
[    4.146906] sun50i-h6-pinctrl 300b000.pinctrl: 300b000.pinctrl supply vcc-pf not found, using dummy regulator
[    4.157036] sunxi-mmc 4020000.mmc: Linked as a consumer to regulator.14
[    4.164240] sunxi-mmc 4020000.mmc: Got CD GPIO
[    4.194041] sunxi-mmc 4020000.mmc: initialized, max. request size: 16384 KB, uses new timings mode
[    4.203554] sun50i-h6-pinctrl 300b000.pinctrl: 300b000.pinctrl supply vcc-pg not found, using dummy regulator
[    4.213654] sunxi-mmc 4021000.mmc: Linked as a consumer to regulator.15
[    4.220336] sunxi-mmc 4021000.mmc: Linked as a consumer to regulator.11
[    4.227513] sunxi-mmc 4021000.mmc: allocated mmc-pwrseq
[    4.266788] mmc0: host does not support reading read-only switch, assuming write-enable
[    4.276590] mmc0: Problem switching card into high-speed mode!
[    4.282516] mmc0: new SDHC card at address 0001
[    4.287236] usb 3-1: new high-speed USB device number 2 using xhci-hcd
[    4.294557] mmcblk0: mmc0:0001 SD 29.1 GiB
[    4.298922] usb 5-1: new high-speed USB device number 2 using ehci-platform
[    4.307381]  mmcblk0: p1
[    4.312427] random: fast init done
[    4.460245] sunxi-mmc 4021000.mmc: initialized, max. request size: 16384 KB, uses new timings mode
[    4.469819] sun50i-h6-pinctrl 300b000.pinctrl: 300b000.pinctrl supply vcc-pc not found, using dummy regulator
[    4.479943] sunxi-mmc 4022000.mmc: Linked as a consumer to regulator.14
[    4.486608] sunxi-mmc 4022000.mmc: Linked as a consumer to regulator.11
[    4.500271] usb 3-1: New USB device found, idVendor=148f, idProduct=3070, bcdDevice= 1.01
[    4.508471] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[    4.515615] usb 3-1: Product: 802.11 n WLAN
[    4.519810] usb 3-1: Manufacturer: Ralink
[    4.523828] usb 3-1: SerialNumber: 1.0
[    4.540270] sunxi-mmc 4022000.mmc: initialized, max. request size: 2048 KB, uses new timings mode
[    4.549450] sun6i-rtc 7000000.rtc: setting system clock to 1970-01-01T00:00:09 UTC (9)
[    4.557507] of_cfs_init
[    4.560034] of_cfs_init: OK
[    4.563017] vcc3v3: disabling
[    4.565996] vcc1v8: disabling
[    4.568978] vdd-gpu: disabling
[    4.572697] Freeing unused kernel memory: 576K
[    4.588281] Run /init as init process
[    4.664320] mmc2: new DDR MMC card at address 0001
[    4.670421] mmcblk2: mmc2:0001 NCard  14.5 GiB
[    4.675813] mmcblk2boot0: mmc2:0001 NCard  partition 1 4.00 MiB
[    4.682544] mmcblk2boot1: mmc2:0001 NCard  partition 2 4.00 MiB
[    4.689552]  mmcblk2: p1
[    4.720051] sunxi-mmc 4022000.mmc: data error, sending stop command
[    4.726460] sunxi-mmc 4022000.mmc: send stop command failed
[    4.732785] sunxi-mmc 4022000.mmc: data error, sending stop command
[    5.736234] sunxi-mmc 4022000.mmc: send stop command failed

Don´t know if anybody else did it... but I got Bluetooth running by modifying the device tree and adding support for communication between the RTL8723BS and UART1 and loading the needed RTL8723B firmware.

Distro: Armbian Buster

Kernel version: 5.4.30-sunxi64 

This is how I did it:

1) Create a patch (xx.patch) with the next content and place it in  ~/build/userpatches/kernel/sunxi-current/

--- a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts    2020-04-06 12:37:45.584912094 +0200
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts    2020-04-06 12:37:45.584912094 +0200
@@ -498,6 +498,21 @@
     status = "okay";
 };
 
+/* On Wifi/BT connector, with RTS/CTS */
+&uart1 {
+    pinctrl-names = "default";
+    pinctrl-0 = <&uart1_pins>, <&uart1_rts_cts_pins>;
+    status = "okay";
+
+    bluetooth {
+        compatible = "realtek,rtl8723bs-bt";
+        device-wake-gpios = <&r_pio 1 1 GPIO_ACTIVE_HIGH>; /* PM1 */
+        host-wake-gpios = <&r_pio 1 2 GPIO_ACTIVE_HIGH>; /* PM2 */
+        reset-gpios = <&r_pio 1 4 GPIO_ACTIVE_LOW>; /* PM4 */
+        post-power-on-delay-ms = <200>;
+    };
+};
+
 &usb2otg {
     dr_mode = "host";
     status = "okay";

2) Run sudo ./compile with your favorite  config (Desktop/server/blablabla)

3) Flash the image to an SD card or eMMC module.

4) Start your Pine64 H64 model-B

4) Connect to a network and run the firmware update/upgrades (armbian-config) and install the Bluetooth tools.

5) DO NOT ENABLE SERIAL 1 !!!! in armbian-config

6) Download the next git repo to your board:  https://github.com/lwfinger/rtl8723bs_bt.git

7) Unpack the archive, run make

8) Copy the next firmware files to /lib/firmwares/rtl_bt:

1.   sudo cp rtlbt_fw_new /lib/firmware/rtl_bt/rtl8723bs_fw.bin
2. sudo cp rtlbt_config /lib/firmware/rtl_bt/rtl8723bs_config.bin

9) Reboot

Expected dmesg output:

[   45.107273] Bluetooth: HCI UART driver ver 2.3
[   45.107279] Bluetooth: HCI UART protocol H4 registered
[   45.107281] Bluetooth: HCI UART protocol BCSP registered
[   45.107329] Bluetooth: HCI UART protocol LL registered
[   45.107331] Bluetooth: HCI UART protocol ATH3K registered
[   45.107375] Bluetooth: HCI UART protocol Three-wire (H5) registered
[   45.107509] Bluetooth: HCI UART protocol Intel registered
[   45.107592] Bluetooth: HCI UART protocol Broadcom registered
[   45.107614] Bluetooth: HCI UART protocol QCA registered
[   45.107616] Bluetooth: HCI UART protocol AG6XX registered
[   45.107642] Bluetooth: HCI UART protocol Marvell registered

[   45.845446] Bluetooth: hci0: RTL: examining hci_ver=06 hci_rev=000b lmp_ver=06 lmp_subver=8723
[   45.849521] Bluetooth: hci0: RTL: rom_version status=0 version=1
[   45.849529] Bluetooth: hci0: RTL: loading rtl_bt/rtl8723bs_fw.bin
[   46.055000] Bluetooth: hci0: RTL: loading rtl_bt/rtl8723bs_config.bin
[   46.096579] Bluetooth: hci0: RTL: cfg_sz 55, total sz 23699

[   46.929071] Bluetooth: hci0: RTL: fw version 0x373e6962

'hciconfig list' output:

hci0:    Type: Primary  Bus: UART
    BD Address: 48:46:C1:3A:6B:5F  ACL MTU: 820:8  SCO MTU: 255:16
    UP RUNNING PSCAN ISCAN 
    RX bytes:1982677 acl:3028 sco:0 events:491 errors:0
    TX bytes:91688 acl:232 sco:0 commands:225 errors:0

File transfer from Pine to Samsung is working... haven't tested anything else..

Regards,

__Dirk__ 

Let me know if I need to do something else for the PR to be merged.

Thanks.

Since I still couldn't find a enclosure for my Pine64 H64 model-B, I mocked up one myself using a Eur 6,50 Raspberry Pi 4 case.  

1) From the USB/ETH connector side I cut out the sections in between the connectors since there is a small offset that pushes the Pine64 board aside when closing the case.

2) From one of the cover lulls, I cut out a section to fit over the IR sensor.

3) On the HDMI side I cut out the two ports holes of the RPI micro hdmi connections  and I made a notch in the USB-C hole to fit the power connector of the Pine64.

4) Drilled a hole in the cover large enough for the WIFI/BT antenna connector, on the board, to fit through.

The pcb takes the exact same mounting points inside the enclosure as the rpi4, so you don't have to fiddle around there.  MicroSD card slot matches exactly

I only forgot to add some holes for the two buttons (Reset/Poweroff) on the SDcard side.

A very thin hot knife works very nice to cut in/out the case material.

Regards,

__Dirk__

I've found a way to install VSCode named Code OSS headmelted, but after 15 minutes the memory gone to be overflow, with the risk to collapse the os.

Excluding Geany, is there some IDE that works and can be used for NodeJS/ES6 ?

The resolution of my desktop (using x11vnc) is 1024x768.

This is the pastebin from dmesg: dmesg from Pine64

There are some error on sunxi8.

Can someone help me?

images 19.11.3, GUI XFCE 4.12  dont not run after upgrade

images 20.02 GUI does not work from begining after installed.

Never mind i build 19.11.5 kernel 5.4.18 and works

Pine64-LTS board. I noticed that i could not get all the serial ports to work. I needed to make a

couple of changes in order to get them all working. Maybe i did something wrong and my changes

were not needed, but i still would like to list them here in order to help other users who are

having problems with the serial ports.

When first starting up the armbian release i used the armbian-config tool to enable the uart 1,

uart 2, uart 3 and uart4. I rebooted but noticed not all ports where present. I noticed a message

in the dmesg log showing ttyS4 error -28. After some research (zcat /proc/config.gz) i noticed the

kernel was compiled with only max 4 serial ports -> CONFIG_SERIAL_8250_NR_UARTS=4 

Sadly this meant i had to recompile the kernel since this item can't be increased with a

kernel parameter setting.

After recompiling the kernel with CONFIG_SERIAL_8250_NR_UARTS=16 and

CONFIG_SERIAL_8250_RUNTIME_UARTS=5 i rebooted the system with the new kernel and

this time got the last uart 4 (addressed by 1c29000.serial) initialized (no more error -28).

I did noticed a new problem. The uart 1 (addressed by 1c28400.serial) was initialized by

the kernel as /dev/ttyS1 but after looking in the /dev directory there was no /dev/ttyS1

I did some more research and thought this was due to the bluetooh hci_uart or other

bluetooth items. So i blacklisted the modules by creating files in

/dev/modprobe.d/<module name>.conf containing the line 'blacklist <module name>'.

This stopped the bluetooth modules from loading but still the /dev/ttyS1 got lost.

I thought this was probably due to some issue in the dtb file so i converted the

/boot/dtb/allwinner/sun50i-a64-pine64-lts.dtb file to a dts file so i could read what was

going on (using the dtc command):

dtc -I dtb -O dts -o sun50i-a64-pine64-lts.dts sun50i-a64-pine64-lts.dtb

In the dts file i noticed the uart 1 (addressed by 1c28400.serial) also contained a bluetooth

part:

serial@1c28400 {
                        compatible = "snps,dw-apb-uart";
                        reg = < 0x1c28400 0x400 >;
                        interrupts = < 0x00 0x01 0x04 >;
                        reg-shift = < 0x02 >;
                        reg-io-width = < 0x04 >;
                        clocks = < 0x02 0x44 >;
                        resets = < 0x02 0x2f >;
                        status = "okay";
                        pinctrl-names = "default";
                        pinctrl-0 = < 0x32 0x33 >;
                        phandle = < 0x76 >;

                        bluetooth {
                                compatible = "realtek,rtl8723bs-bt";
                                reset-gpios = < 0x34 0x00 0x04 0x01 >;
                                device-wake-gpios = < 0x34 0x00 0x05 0x00 >;
                                host-wake-gpios = < 0x34 0x00 0x06 0x00 >;
                                firmware-postfix = "pine64";
                        };
                };

I removed the complete bluetooth part, so this part looked like:

serial@1c28400 {
                        compatible = "snps,dw-apb-uart";
                        reg = < 0x1c28400 0x400 >;
                        interrupts = < 0x00 0x01 0x04 >;
                        reg-shift = < 0x02 >;
                        reg-io-width = < 0x04 >;
                        clocks = < 0x02 0x44 >;
                        resets = < 0x02 0x2f >;
                        status = "okay";
                        pinctrl-names = "default";
                        pinctrl-0 = < 0x32 0x33 >;
                        phandle = < 0x76 >;
                };

I first made a backup of the original dtb file:

cp /boot/dtb/allwinner/sun50i-a64-pine64-lts.dtb /boot/dtb/allwinner/sun50i-a64-pine64-lts.dtb-orig

I then converted the altered dts file back into a dtb format with the help of the following command:

dtc -I dts -O dtb -o sun50i-a64-pine64-lts.dtb sun50i-a64-pine64-lts.dts

I rebooted the system and this time i did got all 5 serial ports working and also available via /dev/ttyS* device nodes.

dmesg log (serial lines)
[    2.877614] 1c28000.serial: ttyS0 at MMIO 0x1c28000 (irq = 30, base_baud = 1500000) is a U6_16550A
[    2.929097] 1c28400.serial: ttyS1 at MMIO 0x1c28400 (irq = 31, base_baud = 1500000) is a U6_16550A
[    2.952307] 1c28800.serial: ttyS2 at MMIO 0x1c28800 (irq = 32, base_baud = 1500000) is a U6_16550A
[    2.975520] 1c28c00.serial: ttyS3 at MMIO 0x1c28c00 (irq = 33, base_baud = 1500000) is a U6_16550A
[    2.998728] 1c29000.serial: ttyS4 at MMIO 0x1c29000 (irq = 34, base_baud = 1500000) is a U6_16550A

ls -al /dev/ttyS*
crw-rw---- 1 root dialout 4, 64 Feb 25 12:54 /dev/ttyS0
crw-rw---- 1 root dialout 4, 65 Feb 25 11:42 /dev/ttyS1
crw-rw---- 1 root dialout 4, 66 Feb 25 11:42 /dev/ttyS2
crw-rw---- 1 root dialout 4, 67 Feb 25 11:42 /dev/ttyS3
crw-rw---- 1 root dialout 4, 68 Feb 25 11:42 /dev/ttyS4

I do not know who is maintaining these parts of Armbian but would like to propose to remove the bluetooth item

from the default DTB file and create an overlay for enabling bluetooth. Possibly with the help of armbian-config

to enable and disable it. Also the kernel should have at least the amount of uarts enabled to make use of it

without recompiling it.

I did the same steps with the Armbian image and write the Armbian image on the eMMC (with the Ayufan image on SD card)

        sudo dd bs=30M if=Image/Armbian_5.38_Pine64so_Ubuntu_xenial_default_3.10.107.img of=/dev/mmcblk1

and nothings happens after the reboot.

There are further steps that I have to carry out?

I'm at research stage, and will be looking into using a current 5.x kernel.

If anyone has any info on the waveshare lcd's I need to watch out for or suggestions to get further info (specifically the touch driver side), please post a response.

Progress on the project will be posted here, links will be added once I have some basics running.

This can hopefully open up the waveshare displays to other devices.

@Igor Yes I've read This post but am willing to do what I can to get Armbian to support the displays as best I can.

• Is this board supported by the images on the Pine H64 page which show a Model A board? (There was mention they work but without ethernet support.)
• Has ethernet support been fixed in the Pine H64 images for Model B?
• Are nightly builds still disabled for these boards?

I'm trying to build my own distribution for the Pine64, and I use armbian as a working reference.

I'm able to compile ATF + U-boot + Kernel + rootfs and the board actually boots and I get a console over the serial interface and over HDMI.

The problem is that GbE Ethernet does not work. It appears that the 8211 phy is not powered.

The good guys on the pine64 IRC pointed to the ATF, where the DC1SW regulator should be turned on in order to power the phy.

On armbian everything works just fine.

I think I messed up something in the build - wrong version / config / dts in either ATF, U-boot or the linux kernel.

I tried to understand how the armbian Pine64 image was built - but since I'm totally new to armbian I got lost pretty quick.

So basically I want to know how can I find the following information:

1. What version + platform of ATF is used? Is it from the official ARM repo, or some fork?

2. What version + config + dts of U-Boot is used?

3. What version + config + dts of Linux is used? Is it mainline / LTS kernel? are there any special patches applied that I should be aware?

I know it is a bit weird question to ask here, but I really want to learn how to create my distro, and armbian is a great reference.

In my project I am using the ports PC0-PC3 (GPIO 64 - 67) for in-circuit programming (with avrdude). Everything was fine until I switched from kernel 4.14 to kernel 4.19.

Now the ports are already in use. (Although according to the pine64 schematics nothing is connected to those ports)

sudo cat /sys/kernel/debug/pinctrl/1c20800.pinctrl/pinmux-pins
...
pin 64 (PC0): device 1c68000.spi function spi0 group PC0
pin 65 (PC1): device 1c68000.spi function spi0 group PC1
pin 66 (PC2): device 1c68000.spi function spi0 group PC2
pin 67 (PC3): device 1c68000.spi function spi0 group PC3
...

In kernel 4.14 the ports were unclaimed:

sudo cat /sys/kernel/debug/pinctrl/1c20800.pinctrl/pinmux-pins

...

pin 64 (PC0): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 65 (PC1): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 66 (PC2): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 67 (PC3): (MUX UNCLAIMED) (GPIO UNCLAIMED)

...

How can I free the ports so I can use kernel 4.19 in my project?

Here is the related information from armbianmonitor -u:

[ 5222.922107] sun50i-a64-pinctrl 1c20800.pinctrl: pin PC3 already requested by 1c68000.spi; cannot claim for 1c20800.pinctrl:67 [ 5222.922122] sun50i-a64-pinctrl 1c20800.pinctrl: pin-67 (1c20800.pinctrl:67) status -22

Thanks for any information in advance.

It gets the same cpu as the pine64. If you have a pine64 can

it run common programs like firefox, vlc, libre office,

gimp and jitsi?

Is the pine64 as fast

as the orange pi

one?

Dmesg shows:

Quote

saus. 14 03:26:23 pine64 kernel: rcu: INFO: rcu_sched self-detected stall on CPU
saus. 14 03:26:23 pine64 kernel: rcu:         2-...0: (286 GPs behind) idle=ad6/0/0x1 softirq=380346/380347 fqs=2
saus. 14 03:26:23 pine64 kernel: rcu:          (t=60094 jiffies g=291549 q=3)
saus. 14 03:26:23 pine64 kernel: Task dump for CPU 2:
saus. 14 03:26:23 pine64 kernel: swapper/2       R  running task        0     0      1 0x0000002a
saus. 14 03:26:23 pine64 kernel: Call trace:
saus. 14 03:26:23 pine64 kernel:  dump_backtrace+0x0/0x1c0
saus. 14 03:26:23 pine64 kernel:  show_stack+0x14/0x20
saus. 14 03:26:23 pine64 kernel:  sched_show_task+0x160/0x198
saus. 14 03:26:23 pine64 kernel:  dump_cpu_task+0x40/0x50
saus. 14 03:26:23 pine64 kernel:  rcu_dump_cpu_stacks+0xc0/0x100
saus. 14 03:26:23 pine64 kernel:  rcu_check_callbacks+0x594/0x780
saus. 14 03:26:23 pine64 kernel:  update_process_times+0x2c/0x58
saus. 14 03:26:23 pine64 kernel:  tick_sched_handle.isra.5+0x30/0x48
saus. 14 03:26:23 pine64 kernel:  tick_sched_timer+0x48/0x98
saus. 14 03:26:23 pine64 kernel:  __hrtimer_run_queues+0xe4/0x1f8
saus. 14 03:26:23 pine64 kernel:  hrtimer_interrupt+0xf4/0x2b0
saus. 14 03:26:23 pine64 kernel:  arch_timer_handler_phys+0x28/0x40
saus. 14 03:26:23 pine64 kernel:  handle_percpu_devid_irq+0x80/0x138
saus. 14 03:26:23 pine64 kernel:  generic_handle_irq+0x24/0x38
saus. 14 03:26:23 pine64 kernel:  __handle_domain_irq+0x5c/0xb0
saus. 14 03:26:23 pine64 kernel:  gic_handle_irq+0x58/0xa8
saus. 14 03:26:23 pine64 kernel:  el1_irq+0xb0/0x140
saus. 14 03:26:23 pine64 kernel:  arch_cpu_idle+0x10/0x18
saus. 14 03:26:23 pine64 kernel:  do_idle+0x1d4/0x298
saus. 14 03:26:23 pine64 kernel:  cpu_startup_entry+0x24/0x28
saus. 14 03:26:23 pine64 kernel:  secondary_start_kernel+0x18c/0x1c8
saus. 14 03:26:23 pine64 kernel: Task dump for CPU 3:
saus. 14 03:26:23 pine64 kernel: tor             R  running task        0  2964      1 0x00000802
saus. 14 03:26:23 pine64 kernel: Call trace:
saus. 14 03:26:23 pine64 kernel:  __switch_to+0x94/0xd8
saus. 14 03:26:23 pine64 kernel:  do_mem_abort+0x54/0x100
saus. 14 03:26:23 pine64 kernel:  el0_da+0x20/0x24

Armbian-release:

BOARD=pine64
BOARD_NAME="Pine64"
BOARDFAMILY=sun50iw1
VERSION=5.70
LINUXFAMILY=sunxi64
BRANCH=next
ARCH=arm64
IMAGE_TYPE=stable
BOARD_TYPE=conf
INITRD_ARCH=arm64
KERNEL_IMAGE_TYPE=Image

With Armbian Pine64 3.10 kernel board worked without hanging for 2+ years.

I also tried 4.18.xx-sunxi64 kernel from dev branch - same problem.

I can get AOSC to start on it, but needed to get Ambian to work. It will partly boot up, but never gets to the the CLI or desktop

I have a good SD Card (AOSC works fine, works on a Pi; tried 32G and 128G, ) and power supply.

Armbian_5.89.190626_Pineh64_Debian_stretch_dev_5.1.12.img
Armbian_5.88_Pineh64_Debian_stretch_dev_5.1.7.img
Armbian_5.88_Pineh64_Ubuntu_bionic_dev_5.1.7.img

They get up to:

Welcome to Debian GNU/Linux 9 (stretch)!

... snip ... 

[ OK ] Started Flush Journal to Persistent Storage.
[ OK ] Started udev Kernel Device Manager.
[ OK ] Started udev Coldplug all Devices.

Then it hangs for > 12 hours.

Ubuntu is similar:

Welcome to Ubuntu 18.04.2 LTS!

... snip ... 

[ OK ] Started Flush Journal to Persistent Storage.
[ OK ] Started Create Static Device Nodes in /dev
       Starting udev Kernel Device Manager...
[ OK ] Started udev Coldplug all Devices.
[ OK ] Started udev Kernel Device Manager.
[ OK ] Started Set the console keyboard layout.
[ OK ] Started Reached target Local File Systems (Pre).

Hangs for a day or so.

I guess I can use AOSC, but for compatibility with the 5+ Pi's we have, I was hoping to get Armbian to work.

Any ideas?  

Thank you,

        == John ==

This is my first attempt to install Armbian on a Pine64 + that I bought 2 weeks ago. I created one from the source, but as the battery management failed, I tried it with a constructed image (Armbian_5.69_Pine64_Debian_stretch_next_4.19.13.img), but it's still the same: everything works fine, except battery management. The state of battery and energy should appear as files in the /sys/class/power/directory, but this directory is not created. I can see this directory and the battery information in other images (like the version of the 3.1 kernel of Ayufan).

What I have seen is a strange error (for me) in dmesg, related to the power management modules (axp..), but I do not know how to solve it:

root@pine64:~# uname -a
Linux pine64 4.19.13-sunxi64 #5.69 SMP Wed Jan 9 18:10:00 CET 2019 aarch64 GNU/Linux

root@pine64:~# dmesg | grep axp

[    1.787551] axp20x-rsb sunxi-rsb-3a3: AXP20x variant AXP803 found

[    1.790301] input: axp20x-pek as /devices/platform/soc/1f03400.rsb/sunxi-rsb-3a3/axp221-pek/input/input0

[    1.795894] axp20x-rsb sunxi-rsb-3a3: AXP20X driver loaded

[    3.065498] axp20x-gpio axp20x-gpio: DMA mask not set

[    3.066057] axp20x-gpio axp20x-gpio: AXP209 pinctrl and GPIO driver loaded

[    5.313564] axp20x-battery-power-supply axp20x-battery-power-supply: DMA mask not set

[    5.316583] axp20x-ac-power-supply axp20x-ac-power-supply: DMA mask not set

[    5.371486] axp20x-adc axp813-adc: DMA mask not set

The same dmesg in other images (but these images are based on kernels that are too old for what I need):

root@pinebook:/home/adminq# uname -a
Linux pinebook 3.10.105-bsp-1.2-ayufan-136 #1 SMP PREEMPT Sat Oct 27 21:18:35 UTC 2018 aarch64 GNU/Linux
root@pinebook:/home/adminq# dmesg | grep axp
[   10.729542] axp81x_board_init: axp regl_devs num = 23
[   11.990682] input: axp81x-supplyer as /devices/platform/axp81x_board/axp81x-supplyer.47/input/input1
root@pinebook:/home/adminq# ls /sys/class/power_supply/
ac  battery  usb

Thank you very much for your wonderful work.

Regards.

1c30000.ethernet: Unsupported interface mode: rgmii-txid

I have successfully make my 3.5 TFT screen work but not the touch screen. I read some tutorials,  mostly guide.

This guide for TFT and Touch is really detailed. For touch:

- Step 1: ads7846 driver seems ok

- Step 2: ads7846_device there is a warning after make and make install, and it said to skip depmod

- After this, I tried 

sudo modprob ads7846
sudo modprob ads7846_device model=7846 cs=1 gpio_pendown=1 keep_vref_on=1 swap_xy=1 pressure_max=255 x_plate_ohms=60 x_min=200 x_max=3900 y_min=200 y_max=3900

ads7846 is ok (confirmed with lsmod).

But ads7846_device return invalid argument, it means that module ads7846_device is not in the system.

Anyone succeed with Pine64?

Yes, it's not new, but I noticed the problem only now.   It's because my use - in short, I use these boards for hobbyistic low level programming - say an OS loader writing, so it's flash and test, never been looking into linux too deep - only needed utilities. staring at the top is not of that set.

Now, when reached the DT parsing, passed by uboot, on this board, my loader, noticed 1GB of RAM... Basically, 1GB, as I see, is a default value set in the dts for pine64-plus yet. The DT is not updated on the fly by uboot, as it looks should be. and when I went to Linux, I saw the same - it sees it as 1GB! I don't see different downloads for variants of this board, so how does armbian distinguish between them? Is that discrimination being done right? I saw in the output, that uboot does see 2GB of RAM, still passes stale information in the DT. What is this, how do you think, is it my miserable fault, a known problem, got it fixed now? Maybe a lot of people keep using their 2GB models not even suspecting linux sees only 1GB?

I got some brand new Pine H64 Model B this week.

Anyone interested in a free test device?

Markus

Hello, I have Pine64 2GB I want to connect the temperature sensor DS18B20.

 How to connect it.

Sorry for my English

This is a first generation Pine64 2Gb computer that I got during the start up of the company.

Currently utilizing a 2 AMP 5VDC PS connected to the Euler bus, heatsinks on the top and bottom of the board and a boot up 100Mb mode.

It would run fine for months then occassionally wouldn't start on boot.

Recently redid the box using Armbian.
 

|  _ \(_)_ __   ___ / /_ | || |  
| |_) | | '_ \ / _ \ '_ \| || |_
|  __/| | | | |  __/ (_) |__   _|
|_|   |_|_| |_|\___|\___/   |_|  
                                 

Welcome to ARMBIAN 5.73 stable Ubuntu 18.04.2 LTS 4.19.25-sunxi64   
System load:   0.36 0.44 0.33      Up time:       1:27 hour        
Memory usage:  31 % of 2001MB     IP:            192.168.244.149
CPU temp:      42°C               
Usage of /:    20% of 30G        

Last login: Tue Apr 16 17:22:07 2019 from 192.168.244.232

Which works well except that every few days the time gets reset to some odd date a couple of hundred years from now and then shuts down the network port.

Checking the RTC (with battery) the time is always right.

Here using an NTP server plugin with PFSense.  Particular about time.

These issues are messing with my automation schedules.

Should I update to a nightly build? 

user@pine64:~$ cat /etc/armbian-release 
# PLEASE DO NOT EDIT THIS FILE
BOARD=pine64
BOARD_NAME="Pine64"
BOARDFAMILY=sun50iw1
VERSION=5.76.190218
LINUXFAMILY=sunxi64
BRANCH=next
ARCH=arm64
IMAGE_TYPE=nightly
BOARD_TYPE=conf
INITRD_ARCH=arm64
KERNEL_IMAGE_TYPE=Image

user@pine64:~$ uname -a
Linux pine64 4.19.25-sunxi64 #5.76.190310 SMP Sun Mar 10 16:22:07 CET 2019 aarch64 GNU/Linux

user@pine64:~$ gzip -d < /proc/config.gz | egrep -i pps
CONFIG_PPS=y
# CONFIG_PPS_DEBUG is not set
# PPS clients support
# CONFIG_PPS_CLIENT_KTIMER is not set
# CONFIG_PPS_CLIENT_LDISC is not set
# CONFIG_PPS_CLIENT_GPIO is not set
# PPS generators support

This appears to likely be from upstream changes in default kernel config options, though I haven't investigated this yet.

Would it be possible to re-add these to the default armbian configurations (CONFIG_PPS_CLIENT_LDISC and CONFIG_PPS_CLIENT_GPIO)?  I can look to submitting a pull request with the needed changes if needed.

I have a Pine64-1gb laying around collecting dust for more that a year and had the idea to replace my RPi3 whitch is now running as a VPN Router.

The RPi3 is restricted to 2 streams and cause cpu load to 100% so mabe the Pine64 could help here.

As I already setup the RPi3 as VPN Router I thought I use the same procedure for the Pine64 with Armbian Jessie.

This is what I use:

HW: Pine64 with 1gb ram (Model: PA641GB)

OS: ARMBIAN 5.38 stable Debian GNU/Linux 8 (jessie) 3.10.107-pine64

VPN software: OpenVPN

VPN Service: PIA

Here a small tutorial of the commands that I'v been used to create this VPN Gateway:

Fist start to setup a Static IP address like this: command ~#sudo nano /etc/network/interfaces

auto lo
iface lo inet loopback 
auto eth0
allow-hotplug eth0
iface eth0 inet static
	address 192.168.1.2
	netmask 255.255.255.0
	gateway 192.168.1.1
	dns-nameservers 1.1.1.1

I also used armbian-config to do this but I always received a message complaining about dnsmasq.

So I did this and the problem went away:

sudo apt-get update
sudo apt-get install dnsmasq

Setup the VPN Client

installing openvpn client

sudo apt-get install openvpn

Download and unzip PIA OpenVPN profiles

wget https://www.privateinternetaccess.com/openvpn/openvpn.zip
unzip openvpn.zip -d openvpn

Copy the profile and certificates to OpenVPN Folder

sudo cp openvpn/ca.rsa.2048.crt
openvpn/crl.rsa.2048.pem /etc/openvpn/
sudo cp openvpn/put-your-chosed-server-name-here.ovpn /etc/openvpn/-put-your-server-name-here-to-create.conf

notice that the extension has changed from ovpn to conf create a login file with username and password for PIA

sudo nano /etc/openvpn/login

add your username and password per line

put-your-username-here
put-your-password-here

now we need to change the config file to point to correct file locations

sudo nano /etc/openvpn/put-your-server-name-here-that-your-create-.conf

change the following lines and add the paths:

auth-user-pass 
ca ca.rsa.2048.crt
crl-verif crl.rsa.2048.pem

to:

auth-user-pass /etc/openvpn/login 
ca /etc/openvpn/ca.rsa.2048.crt
crl-verif /etc/openvpn/crl.rsa.2048.pem

Now reboot: sudo reboot

Now let's test the VPN

sudo openvpn --config /etc/openvpn/-put-your-created-server-name-here-.conf

to Exit use Ctrl + c Enable VPN at boot

sudo systemctl enable openvpn@-your-created-server-here-
example: sudo systemctl enable openvpn@Japan (you get the point)

Setup IPTables

sudo nano /etc/sysctl.conf

uncomment the # to allow forwarding

net.ipv4.ip_forward = 1

enable the service by typing this command:

sudo sysctl -p

IPTables this is best to just copy and past this to your ssh session. If you want to know more details about these rules, check out the video

sudo iptables -A INPUT -i lo -m comment --comment "loopback" -j ACCEPT 
sudo iptables -A OUTPUT -o lo -m comment --comment "loopback" -j ACCEPT 
sudo iptables -I INPUT -i eth0 -m comment --comment "In from LAN" -j ACCEPT 
sudo iptables -I OUTPUT -o tun+ -m comment --comment "Out to VPN" -j ACCEPT 
sudo iptables -A OUTPUT -o eth0 -p udp --dport 1198 -m comment --comment "openvpn" -j ACCEPT 
sudo iptables -A OUTPUT -o eth0 -p udp --dport 123 -m comment --comment "ntp" -j ACCEPT 
sudo iptables -A OUTPUT -p UDP --dport 67:68 -m comment --comment "dhcp" -j ACCEPT 
sudo iptables -A OUTPUT -o eth0 -p udp --dport 53 -m comment --comment "dns" -j ACCEPT 
sudo iptables -A FORWARD -i tun+ -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT 
sudo iptables -A FORWARD -i eth0 -o tun+ -m comment --comment "LAN out to VPN" -j ACCEPT 
sudo iptables -t nat -A POSTROUTING -o tun+ -j MASQUERADE

make the rules persistent when reboot:

sudo apt-get install iptables-persistent

the installer will ask to save the rules IPv4 select YES and also YES for IPv6.

sudo netfilter-persistent save

lets apply this netfilter to the startup:

sudo systemctl enable netfilter-persistent

sudo reboot

Enjoy !!!!

Armbian Bionic mainline kernel 4.19.y (next). Only Armbian Xenial desktop legacy kernel 3.10.y is working correctly.

Can you help me?

Maybe I can fix it, too, but I don't know, how  and where to start.

Thanks

I am glad you are interested to help us.

A long time ago at the end of 2015 the Kickstarter was founded and since middle of 2016 the hardware is available.

If you look at our download page of Pine64 you can see that since then we have collected a lot of information of which some of it maybe obsolete/outdated/resolved: https://www.armbian.com/pine64/

Now, if you are a lucky owner of such a SBC you have THE CHANCE to help the armbian project. Will you please download the latest Xenial legacy kernel 3.10.y and verifiy if some of the problems listed on the website are already solved in the current release?

And if so, please report back here what you have tested and which of the lines of the website (by quoting these) are obsolete or if you know how it can be resolved.

Let's start bug hunting

and spread the word to support us hunting.

I want to monitor the temperature of my Pine64, because I run the pine in an relatively warm environment.  Unfortunately, the usual ways do not lead to a reasonable result:

I tried the armbianmonitor: "armbianmonitor -m"

with this result:
Time      CPU n/a    load %cpu %sys %usr %nice %io %irq   CPU

17:08:20:   ---      0.00   0%   0%   0%   0%   0%   0% -13552°C
17:08:25:   ---      0.00   0%   0%   0%   0%   0%   0% -13673°C

and read the file: /sys/devices/virtual/thermal/thermal_zone0/temp: contains the same wrong value -13552

Is there a way to activate the temperature measurement? 

I am using the following system: ARMBIAN 5.49.180626 nightly Ubuntu 16.04.4 LTS 4.14.52-sunxi64

Thanks a lot

Linda

I have an issue, i am running the Pine LTS board on eMMC using Armbian latest stable image.  We want to access the serial port on the board, so to test i downloaded putty, i select serial and click open. I get an error when opening this, so i have to run: sudo chmod 777 /dev/tty50 and sudo chmod /dev/tty52 on each boot, then i am able to open the serial port using putty. 

When i look at the ls -l /dev/tty50 i get: crw--w---- 1 root tty 4, 50 Jan 30 30 16:07 tty50. After etensive research i added my user cst to the tty group, but when i reboot i still have to manually run chmod again to access the serial port. 

Can someone please assist me with getting this command to run on boot or some solution as i cannot every time run this command as these boards are Gateways which will be in remote locations.  I did try rc.local but i understand that this is not available anymore. 

I am not too much of a Armbian guru so if you could assist in detailed steps i would appreciate it. 

No URL is given when i run the armbianmonitor command, it is blank. 

Thanks!

Armbian Version: 5.69

I am unable to get audio signal (output) from the Audio Jack.

Tried normal headphone with 3 contacts, also tried headset with 4 contacts, BOTH fail to get audio out.

Tried Stretch and also Ubuntu, no success...

Does anybody succeed getting audio out from the onboard audio jack with Armbiam?

If so, can you give a brief description of the procedure/steps and the soft(s) you are using?

When using a external USB Audio adapter everything seems to work fine (connecting to the Adapter Audio Jack), so, I guess that from the point of view of software the problem is really located around the Onboard Audio Jack...

Right now my basic need is to be able to get AUDIO OUTPUT from the Jack (connector)...

Thanks all,

Valter Fukuoka

I tried to initiate Waveshare screen by following steps:

- Enable spidev0.0 from armbianEnv.txt (confirm with /dev/spidev0.0)

- modprobe fbtft by:

sudo modprobe fbtft_device name=piscreen

But I got error with step 2. Here is the output of dmesg

[ 4419.154174] fbtft: module is from the staging directory, the quality is unknown, you have been warned.
[ 4419.163004] fbtft_device: module is from the staging directory, the quality is unknown, you have been warned.
[ 4419.164436] spidev spi0.0: spidev spi0.0 1000kHz 8 bits mode=0x00
[ 4419.164564] spidev spi0.0: Deleting spi0.0
[ 4419.165176] fbtft_device: GPIOS used by 'piscreen':
[ 4419.165183] fbtft_device: 'reset' = GPIO25
[ 4419.165187] fbtft_device: 'dc' = GPIO24
[ 4419.165190] fbtft_device: 'led' = GPIO22
[ 4419.165203] spi spi0.0: fb_ili9486 spi0.0 32000kHz 8 bits mode=0x00
[ 4419.186567] fb_ili9486: module is from the staging directory, the quality is unknown, you have been warned.
[ 4419.188554] fb_ili9486 spi0.0: fbtft_request_gpios: gpio_request_one('reset'=25) failed with -517

It seems that GPIO25 is not responded. I know that many have success with OrangePi, but no one with Pine64.

Any suggestion?

Thanks.

I'm having trouble getting the camera module s5k4ec to work for my pine64 running armbian 5.60

#cat /etc/lsb-release

DISTRIB_ID=Ubuntu

DISTRIB_RELEASE=16.04

DISTRIB_CODENAME=xenial

DISTRIB_DESCRIPTION="Ubuntu 16.04.5 LTS"

Here my armbianmonitor -u http://ix.io/1wU9. 

i've activated the module in/boot/armbianEnv.txt

verbosity=1
console=both
disp_mode=720p60
camera_type=s5k4ec
pine64_lcd=off
overlay_prefix=sun50i-a64
rootdev=UUID=97dbd6a3-cb6e-4dd8-a999-76e955b73f0e
rootfstype=ext4
usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u

I tried to follow https://github.com/avafinger/pine64_camera with no success; i'm stuck here "rename in SD card: [sdcard]/BOOT/pine64/sun50i-a64-pine64-plus.dtb to [sdcard]/BOOT/pine64/sun50i-a64-pine64-plus.dtb_no_camera" 

since i've [sdcard]/boot/dtb instead of [sdcard]/boot/pine64. Iìve tried to copy sun50i-a64-pine64-plus.dtb in /boot/dtb but it seems it no work - I don't have /dev/video0.

I also tried with motion, same results 

[0] [NTC] [ALL] [Dec 27 15:24:20] main: Motion thread 1 restart
[1] [NTC] [ALL] [Dec 27 15:24:20] motion_init: Thread 1 started , motion detection Enabled
[1] [NTC] [VID] [Dec 27 15:24:20] vid_v4lx_start: Using videodevice /dev/video0 and input -1
[1] [ALR] [VID] [Dec 27 15:24:20] vid_v4lx_start: Failed to open video device /dev/video0: No such file or directory
[1] [WRN] [ALL] [Dec 27 15:24:20] motion_init: Could not fetch initial image from camera Motion continues using width and height from config file(s)
[1] [NTC] [ALL] [Dec 27 15:24:20] image_ring_resize: Resizing pre_capture buffer to 1 items

surely I'm wrong with something since I'm a noob trying to become -at leats - good. 

someone who wants to give me some advice? 

Many Thanks,

Andi. 

CONFIG_SND_SOC_SUNXI_RW=y
CONFIG_SND_SOC_SUNXI_AUDIO_DMA=y
CONFIG_SND_SOC_SUNXI_TDM=y
CONFIG_SND_SUNXI_SOC=y
CONFIG_SND_SOC_INTERNAL_AUDIOCODEC=y
CONFIG_SND_SOC_INTERNAL_I2S=y
CONFIG_SND_SOC_AUDIO_CODEC_MACHINE=y
CONFIG_SND_SOC_DAUDIO_PLATFORM=y
CONFIG_SND_SOC_VIRCODEC=y
CONFIG_SND_SOC_DAUDIO0_MACHINE=y
# CONFIG_SND_SOC_DAUDIO1_MACHINE is not set
CONFIG_SND_SUNXI_SOC_HDMIAUDIO=y

The Internal Audio  and HDMI Audio are initialized successfully but failed to snddaudio0 which can be accessed from Euler bus pins.  below is the error log.

Dec  4 02:22:10 localhost kernel: [   10.453351] snddaudio0 sound.8: ASoC: CPU DAI (null) not registered
Dec  4 02:22:10 localhost kernel: [   10.453386] snddaudio0 sound.8: snd_soc_register_card() failed: -517
Dec  4 02:22:10 localhost kernel: [   10.453390] [RANJ] sunxi_snddaudio0_dev_probe done with -517

apaly - l returns the following

root@pine64:/boot# aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: audiocodec [audiocodec], device 0: SUNXI-CODEC codec-aif1-0 []
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: audiocodec [audiocodec], device 1: bb Voice codec-aif2-1 []
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: audiocodec [audiocodec], device 2: bb-bt-clk codec-aif2-2 []
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: audiocodec [audiocodec], device 3: bt Voice codec-aif3-3 []
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: sndhdmi [sndhdmi], device 0: SUNXI-HDMIAUDIO sndhdmi-0 []
  Subdevices: 1/1
  Subdevice #0: subdevice #0

Before I tried to load as modules with below changes .

<*>   ASoC support for audiocodec
   <M>   ASoC support for internal-i2s 
   <M>   ASoC support for audiocodec machine 
   <M>   ASoC support for daudio platform. 
   <M>   ASoC support for vircodec  
   <M>   ASoC support for daudio0 machine 
   < >   ASoC support for daudio1 machine 
   <M>   ASoC support for hdmiaudio 

changed the device tree file for sound@1  (sun50iw1pi-pine64-plus.dtb)

sound@1 {
compatible = "allwinner,sunxi-daudio0-machine";
sunxi,daudio0-controller = <0x4e>;
status = "disabled";   -------> "okay"
device_type = "snddaudio0";
};

The result is same.   Please help me to enable I2S codec testing on Euler bus I2S pins using  Armbian build image.

Regards

Ranjit

The other topic is there :

Yesterday I tried using `rtk_hciattach` from https://github.com/lwfinger/rtl8723bs_bt

That was the program I was using with legacy kernel.

After a fresh start (removed the Power USB and plugged it back in) I get this output :

root@pine64:~/src/rtl8723bs_bt# ./rtk_hciattach -n -s 115200 /dev/ttyS1 rtk_h5
Realtek Bluetooth init uart with init speed:115200, final_speed:115200, type:HCI UART H5
Realtek Bluetooth :Realtek hciattach version 2.5

Realtek Bluetooth :3-wire sync pattern resend : 1, len: 8

Realtek Bluetooth :Get SYNC Resp Pkt

Realtek Bluetooth :Get SYNC pkt-active mode

Realtek Bluetooth :3-wire config pattern resend : 1 , len: 10
Realtek Bluetooth :Get CONFG pkt-active mode

Realtek Bluetooth :Get CONFG resp pkt-active mode

Realtek Bluetooth :H5 init finished

Realtek Bluetooth ERROR: can't access bt config file:/lib/firmware/rtl_bt/rtlbt_config, errno:2

Realtek Bluetooth ERROR: Get Config file error, just use efuse settings
Realtek Bluetooth ERROR: Can't access firmware, errno:2
Realtek Bluetooth ERROR: Get BT firmware error
Can't initialize device: No such file or directory
root@pine64:~/src/rtl8723bs_bt# make install
mkdir -p /lib/firmware/rtl_bt
cp -p rtlbt_* /lib/firmware/rtl_bt/.
root@pine64:~/src/rtl8723bs_bt# ./rtk_hciattach -n -s 115200 /dev/ttyS1 rtk_h5
Realtek Bluetooth init uart with init speed:115200, final_speed:115200, type:HCI UART H5
Realtek Bluetooth :Realtek hciattach version 2.5

Realtek Bluetooth :3-wire sync pattern resend : 1, len: 8

Realtek Bluetooth :3-wire sync pattern resend : 2, len: 8

Realtek Bluetooth :3-wire sync pattern resend : 3, len: 8

Realtek Bluetooth :Get SYNC Resp Pkt

Realtek Bluetooth :Get SYNC pkt-active mode

Realtek Bluetooth :3-wire config pattern resend : 1 , len: 10
Realtek Bluetooth :Get CONFG pkt-active mode

Realtek Bluetooth :Get CONFG resp pkt-active mode

Realtek Bluetooth :H5 init finished

Realtek Bluetooth :config offset(f4),length(8)
Realtek Bluetooth :config baud rate to :4928002, hwflowcontrol:5f, 1
Realtek Bluetooth :config offset(27),length(1)
Realtek Bluetooth :config offset(fe),length(1)
Realtek Bluetooth :config offset(15b),length(4)
Realtek Bluetooth :config offset(1e3),length(1)
Realtek Bluetooth :Get config baud rate from config file:4928002
Realtek Bluetooth :Load FW OK
Realtek Bluetooth :RTK send HCI_VENDOR_READ_RTK_ROM_VERISION_Command

Realtek Bluetooth :Received reliable seqno 0 from card
Realtek Bluetooth :receive hci command complete event with command:1001

Realtek Bluetooth :Read RTK LMP version with Status:0
Realtek Bluetooth :gLmpVersion = 0x8723
Realtek Bluetooth :RTK send HCI_VENDOR_READ_RTK_ROM_VERISION_Command

Realtek Bluetooth :Received reliable seqno 1 from card
Realtek Bluetooth :receive hci command complete event with command:fc6d

Realtek Bluetooth :Read RTK rom version with Status:0
Realtek Bluetooth :rtk_hw_cfg.eversion = 1
Realtek Bluetooth :rtk_get_fw_project_id: opcode 0, len 1, data 1
Realtek Bluetooth :fw_ver 0x1e3ee40e, patch_num 2
Realtek Bluetooth :patch length is 0x5e90
Realtek Bluetooth :start offset is 0x4f00
Realtek Bluetooth :fw: exists, config file: exists
Realtek Bluetooth :baudrate in change speed command: 0x2 0x80 0x92 0x4

Realtek Bluetooth :Received reliable seqno 2 from card
Realtek Bluetooth :receive hci command complete event with command:fc17

Realtek Bluetooth :Change BD Rate with status:0
Realtek Bluetooth :final_speed 1500000

Realtek Bluetooth :hw flow control enable
Realtek Bluetooth :iEndIndex:96  iLastPacketLen:71 iAdditionpkt:4

Realtek Bluetooth :hci_download_patch tx_index:0 rx_index: -1

Realtek Bluetooth :Received reliable seqno 3 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 0

Realtek Bluetooth :hci_download_patch tx_index:1 rx_index: 0

Realtek Bluetooth :Received reliable seqno 4 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 1

Realtek Bluetooth :hci_download_patch tx_index:2 rx_index: 1

Realtek Bluetooth :Received reliable seqno 5 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 2

Realtek Bluetooth :hci_download_patch tx_index:3 rx_index: 2

Realtek Bluetooth :Received reliable seqno 6 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 3

Realtek Bluetooth :hci_download_patch tx_index:4 rx_index: 3

Realtek Bluetooth :Received reliable seqno 7 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 4

Realtek Bluetooth :hci_download_patch tx_index:5 rx_index: 4

Realtek Bluetooth :Received reliable seqno 0 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 5

Realtek Bluetooth :hci_download_patch tx_index:6 rx_index: 5

Realtek Bluetooth :Received reliable seqno 1 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 6

Realtek Bluetooth :hci_download_patch tx_index:7 rx_index: 6

Realtek Bluetooth :Received reliable seqno 2 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 7

Realtek Bluetooth :hci_download_patch tx_index:8 rx_index: 7

Realtek Bluetooth :Received reliable seqno 3 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 8

Realtek Bluetooth :hci_download_patch tx_index:9 rx_index: 8

Realtek Bluetooth :Received reliable seqno 4 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 9

Realtek Bluetooth :hci_download_patch tx_index:10 rx_index: 9

Realtek Bluetooth :Received reliable seqno 5 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 10

Realtek Bluetooth :hci_download_patch tx_index:11 rx_index: 10

Realtek Bluetooth :Received reliable seqno 6 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 11

Realtek Bluetooth :hci_download_patch tx_index:12 rx_index: 11

Realtek Bluetooth :Received reliable seqno 7 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 12

Realtek Bluetooth :hci_download_patch tx_index:13 rx_index: 12

Realtek Bluetooth :Received reliable seqno 0 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 13

Realtek Bluetooth :hci_download_patch tx_index:14 rx_index: 13

Realtek Bluetooth :Received reliable seqno 1 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 14

Realtek Bluetooth :hci_download_patch tx_index:15 rx_index: 14

Realtek Bluetooth :Received reliable seqno 2 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 15

Realtek Bluetooth :hci_download_patch tx_index:16 rx_index: 15

Realtek Bluetooth :Received reliable seqno 3 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 16

Realtek Bluetooth :hci_download_patch tx_index:17 rx_index: 16

Realtek Bluetooth :Received reliable seqno 4 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 17

Realtek Bluetooth :hci_download_patch tx_index:18 rx_index: 17

Realtek Bluetooth :Received reliable seqno 5 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 18

Realtek Bluetooth :hci_download_patch tx_index:19 rx_index: 18

Realtek Bluetooth :Received reliable seqno 6 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 19

Realtek Bluetooth :hci_download_patch tx_index:20 rx_index: 19

Realtek Bluetooth :Received reliable seqno 7 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 20

Realtek Bluetooth :hci_download_patch tx_index:21 rx_index: 20

Realtek Bluetooth :Received reliable seqno 0 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 21

Realtek Bluetooth :hci_download_patch tx_index:22 rx_index: 21

Realtek Bluetooth :Received reliable seqno 1 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 22

Realtek Bluetooth :hci_download_patch tx_index:23 rx_index: 22

Realtek Bluetooth :Received reliable seqno 2 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 23

Realtek Bluetooth :hci_download_patch tx_index:24 rx_index: 23

Realtek Bluetooth :Received reliable seqno 3 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 24

Realtek Bluetooth :hci_download_patch tx_index:25 rx_index: 24

Realtek Bluetooth :Received reliable seqno 4 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 25

Realtek Bluetooth :hci_download_patch tx_index:26 rx_index: 25

Realtek Bluetooth :Received reliable seqno 5 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 26

Realtek Bluetooth :hci_download_patch tx_index:27 rx_index: 26

Realtek Bluetooth :Received reliable seqno 6 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 27

Realtek Bluetooth :hci_download_patch tx_index:28 rx_index: 27

Realtek Bluetooth :Received reliable seqno 7 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 28

Realtek Bluetooth :hci_download_patch tx_index:29 rx_index: 28

Realtek Bluetooth :Received reliable seqno 0 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 29

Realtek Bluetooth :hci_download_patch tx_index:30 rx_index: 29

Realtek Bluetooth :Received reliable seqno 1 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 30

Realtek Bluetooth :hci_download_patch tx_index:31 rx_index: 30

Realtek Bluetooth :Received reliable seqno 2 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 31

Realtek Bluetooth :hci_download_patch tx_index:32 rx_index: 31

Realtek Bluetooth :Received reliable seqno 3 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 32

Realtek Bluetooth :hci_download_patch tx_index:33 rx_index: 32

Realtek Bluetooth :Received reliable seqno 4 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 33

Realtek Bluetooth :hci_download_patch tx_index:34 rx_index: 33

Realtek Bluetooth :Received reliable seqno 5 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 34

Realtek Bluetooth :hci_download_patch tx_index:35 rx_index: 34

Realtek Bluetooth :Received reliable seqno 6 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 35

Realtek Bluetooth :hci_download_patch tx_index:36 rx_index: 35

Realtek Bluetooth :Received reliable seqno 7 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 36

Realtek Bluetooth :hci_download_patch tx_index:37 rx_index: 36

Realtek Bluetooth :Received reliable seqno 0 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 37

Realtek Bluetooth :hci_download_patch tx_index:38 rx_index: 37

Realtek Bluetooth :Received reliable seqno 1 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 38

Realtek Bluetooth :hci_download_patch tx_index:39 rx_index: 38

Realtek Bluetooth :Received reliable seqno 2 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 39

Realtek Bluetooth :hci_download_patch tx_index:40 rx_index: 39

Realtek Bluetooth :Received reliable seqno 3 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 40

Realtek Bluetooth :hci_download_patch tx_index:41 rx_index: 40

Realtek Bluetooth :Received reliable seqno 4 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 41

Realtek Bluetooth :hci_download_patch tx_index:42 rx_index: 41

Realtek Bluetooth :Received reliable seqno 5 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 42

Realtek Bluetooth :hci_download_patch tx_index:43 rx_index: 42

Realtek Bluetooth :Received reliable seqno 6 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 43

Realtek Bluetooth :hci_download_patch tx_index:44 rx_index: 43

Realtek Bluetooth :Received reliable seqno 7 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 44

Realtek Bluetooth :hci_download_patch tx_index:45 rx_index: 44

Realtek Bluetooth :Received reliable seqno 0 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 45

Realtek Bluetooth :hci_download_patch tx_index:46 rx_index: 45

Realtek Bluetooth :Received reliable seqno 1 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 46

Realtek Bluetooth :hci_download_patch tx_index:47 rx_index: 46

Realtek Bluetooth :Received reliable seqno 2 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 47

Realtek Bluetooth :hci_download_patch tx_index:48 rx_index: 47

Realtek Bluetooth :Received reliable seqno 3 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 48

Realtek Bluetooth :hci_download_patch tx_index:49 rx_index: 48

Realtek Bluetooth :Received reliable seqno 4 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 49

Realtek Bluetooth :hci_download_patch tx_index:50 rx_index: 49

Realtek Bluetooth :Received reliable seqno 5 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 50

Realtek Bluetooth :hci_download_patch tx_index:51 rx_index: 50

Realtek Bluetooth :Received reliable seqno 6 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 51

Realtek Bluetooth :hci_download_patch tx_index:52 rx_index: 51

Realtek Bluetooth :Received reliable seqno 7 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 52

Realtek Bluetooth :hci_download_patch tx_index:53 rx_index: 52

Realtek Bluetooth :Received reliable seqno 0 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 53

Realtek Bluetooth :hci_download_patch tx_index:54 rx_index: 53

Realtek Bluetooth :Received reliable seqno 1 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 54

Realtek Bluetooth :hci_download_patch tx_index:55 rx_index: 54

Realtek Bluetooth :Received reliable seqno 2 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 55

Realtek Bluetooth :hci_download_patch tx_index:56 rx_index: 55

Realtek Bluetooth :Received reliable seqno 3 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 56

Realtek Bluetooth :hci_download_patch tx_index:57 rx_index: 56

Realtek Bluetooth :Received reliable seqno 4 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 57

Realtek Bluetooth :hci_download_patch tx_index:58 rx_index: 57

Realtek Bluetooth :Received reliable seqno 5 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 58

Realtek Bluetooth :hci_download_patch tx_index:59 rx_index: 58

Realtek Bluetooth :Received reliable seqno 6 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 59

Realtek Bluetooth :hci_download_patch tx_index:60 rx_index: 59

Realtek Bluetooth :Received reliable seqno 7 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 60

Realtek Bluetooth :hci_download_patch tx_index:61 rx_index: 60

Realtek Bluetooth :Received reliable seqno 0 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 61

Realtek Bluetooth :hci_download_patch tx_index:62 rx_index: 61

Realtek Bluetooth :Received reliable seqno 1 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 62

Realtek Bluetooth :hci_download_patch tx_index:63 rx_index: 62

Realtek Bluetooth :Received reliable seqno 2 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 63

Realtek Bluetooth :hci_download_patch tx_index:64 rx_index: 63

Realtek Bluetooth :Received reliable seqno 3 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 64

Realtek Bluetooth :hci_download_patch tx_index:65 rx_index: 64

Realtek Bluetooth :Received reliable seqno 4 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 65

Realtek Bluetooth :hci_download_patch tx_index:66 rx_index: 65

Realtek Bluetooth :Received reliable seqno 5 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 66

Realtek Bluetooth :hci_download_patch tx_index:67 rx_index: 66

Realtek Bluetooth :Received reliable seqno 6 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 67

Realtek Bluetooth :hci_download_patch tx_index:68 rx_index: 67

Realtek Bluetooth :Received reliable seqno 7 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 68

Realtek Bluetooth :hci_download_patch tx_index:69 rx_index: 68

Realtek Bluetooth :Received reliable seqno 0 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 69

Realtek Bluetooth :hci_download_patch tx_index:70 rx_index: 69

Realtek Bluetooth :Received reliable seqno 1 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 70

Realtek Bluetooth :hci_download_patch tx_index:71 rx_index: 70

Realtek Bluetooth :Received reliable seqno 2 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 71

Realtek Bluetooth :hci_download_patch tx_index:72 rx_index: 71

Realtek Bluetooth :Received reliable seqno 3 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 72

Realtek Bluetooth :hci_download_patch tx_index:73 rx_index: 72

Realtek Bluetooth :Received reliable seqno 4 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 73

Realtek Bluetooth :hci_download_patch tx_index:74 rx_index: 73

Realtek Bluetooth :Received reliable seqno 5 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 74

Realtek Bluetooth :hci_download_patch tx_index:75 rx_index: 74

Realtek Bluetooth :Received reliable seqno 6 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 75

Realtek Bluetooth :hci_download_patch tx_index:76 rx_index: 75

Realtek Bluetooth :Received reliable seqno 7 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 76

Realtek Bluetooth :hci_download_patch tx_index:77 rx_index: 76

Realtek Bluetooth :Received reliable seqno 0 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 77

Realtek Bluetooth :hci_download_patch tx_index:78 rx_index: 77

Realtek Bluetooth :Received reliable seqno 1 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 78

Realtek Bluetooth :hci_download_patch tx_index:79 rx_index: 78

Realtek Bluetooth :Received reliable seqno 2 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 79

Realtek Bluetooth :hci_download_patch tx_index:80 rx_index: 79

Realtek Bluetooth :Received reliable seqno 3 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 80

Realtek Bluetooth :hci_download_patch tx_index:81 rx_index: 80

Realtek Bluetooth :Received reliable seqno 4 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 81

Realtek Bluetooth :hci_download_patch tx_index:82 rx_index: 81

Realtek Bluetooth :Received reliable seqno 5 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 82

Realtek Bluetooth :hci_download_patch tx_index:83 rx_index: 82

Realtek Bluetooth :Received reliable seqno 6 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 83

Realtek Bluetooth :hci_download_patch tx_index:84 rx_index: 83

Realtek Bluetooth :Received reliable seqno 7 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 84

Realtek Bluetooth :hci_download_patch tx_index:85 rx_index: 84

Realtek Bluetooth :Received reliable seqno 0 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 85

Realtek Bluetooth :hci_download_patch tx_index:86 rx_index: 85

Realtek Bluetooth :Received reliable seqno 1 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 86

Realtek Bluetooth :hci_download_patch tx_index:87 rx_index: 86

Realtek Bluetooth :Received reliable seqno 2 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 87

Realtek Bluetooth :hci_download_patch tx_index:88 rx_index: 87

Realtek Bluetooth :Received reliable seqno 3 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 88

Realtek Bluetooth :hci_download_patch tx_index:89 rx_index: 88

Realtek Bluetooth :Received reliable seqno 4 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 89

Realtek Bluetooth :hci_download_patch tx_index:90 rx_index: 89

Realtek Bluetooth :Received reliable seqno 5 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 90

Realtek Bluetooth :hci_download_patch tx_index:91 rx_index: 90

Realtek Bluetooth :Received reliable seqno 6 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 91

Realtek Bluetooth :hci_download_patch tx_index:92 rx_index: 91

Realtek Bluetooth :Received reliable seqno 7 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 92

Realtek Bluetooth :hci_download_patch tx_index:93 rx_index: 92

Realtek Bluetooth :Received reliable seqno 0 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 93

Realtek Bluetooth :hci_download_patch tx_index:94 rx_index: 93

Realtek Bluetooth :Received reliable seqno 1 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 94

Realtek Bluetooth :hci_download_patch tx_index:95 rx_index: 94

Realtek Bluetooth :Received reliable seqno 2 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 95

Realtek Bluetooth :hci_download_patch tx_index:96 rx_index: 95

Realtek Bluetooth :Received reliable seqno 3 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 96

Realtek Bluetooth :hci_download_patch tx_index:97 rx_index: 96

Realtek Bluetooth :Received reliable seqno 4 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 97

Realtek Bluetooth :hci_download_patch tx_index:98 rx_index: 97

Realtek Bluetooth :Received reliable seqno 5 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 98

Realtek Bluetooth :hci_download_patch tx_index:99 rx_index: 98

Realtek Bluetooth :Received reliable seqno 6 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 99

Realtek Bluetooth :Send FW last command
Realtek Bluetooth :hci_download_patch tx_index:100 rx_index: 99

Realtek Bluetooth :Received reliable seqno 7 from card
Realtek Bluetooth :rtk_hw_cfg.rx_index 100

Realtek Bluetooth :Init Process finished
Can't set device: Protocol not supported
Can't initialize device: Protocol not supported

So that does not work but it seems the communication with the chip is working.

If I retry after a normal reboot then `rtk_hciattach` completely fail.

I'm building a kernel with this patch enabled : https://github.com/armbian/build/blob/master/patch/kernel/sunxi-dev/0142-Bluetooth-hci_h5-Add-support-for-binding-RTL8723BS-w.patch.disabled

I'll see if that helps

If anyone has an idea I'm all ears

our compile env:

root@ubuntu69:/tycom/armbian# uname -a
Linux ubuntu69 4.15.0-36-generic #39-Ubuntu SMP Mon Sep 24 16:19:09 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
root@ubuntu69:/tycom/armbian# cat /etc/os-release
NAME="Ubuntu"
VERSION="18.04.1 LTS (Bionic Beaver)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 18.04.1 LTS"
VERSION_ID="18.04"
 

Board：PINE H64

Compile Env：from https://github.com/armbian

In our compile environment，generate the image file：Armbian_5.67_Pineh64_Debian_stretch_dev_4.19.2.img，we burn it into SD by Etcher，the booting is hang，no error message:

Starting kernel ...

[    1.188734] sunxi-mmc 4022000.mmc: initialized, max. request size: 2048 KB
[    1.194122] sunxi-mmc 4020000.mmc: initialized, max. request size: 16384 KB, uses new timings mode
[    1.261947] random: fast init done
[    1.313257] mmc1: new high speed MMC card at address 0001
[    1.319604] mmcblk1: mmc1:0001 8GME4R 7.28 GiB 
[    1.324848] mmcblk1boot0: mmc1:0001 8GME4R partition 1 4.00 MiB
[    1.331482] mmcblk1boot1: mmc1:0001 8GME4R partition 2 4.00 MiB
[    1.338769]  mmcblk1: p1
[    1.774235] mmc0: host does not support reading read-only switch, assuming write-enable
[    1.785748] mmc0: new high speed SDHC card at address 1388
[    1.792102] mmcblk0: mmc0:1388 USD00 14.7 GiB 
[    1.797771]  mmcblk0: p1
[    4.502167] usb 1-1: new high-speed USB device number 2 using ehci-platform
[    4.526161] usb 3-1: new high-speed USB device number 2 using ehci-platform
[    4.647329] usb 1-1: New USB device found, idVendor=2c7c, idProduct=0125, bcdDevice= 3.18
[    4.655531] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[    4.662681] usb 1-1: Product: Android

[    4.666360] usb 1-1: Manufacturer: Android
[    4.692293] usb 3-1: New USB device found, idVendor=2c7c, idProduct=0125, bcdDevice= 3.18
[    4.700487] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[    4.707633] usb 3-1: Product: Android
[    4.711312] usb 3-1: Manufacturer: Android

But we download the image file (Armbian_5.59.180824_Pineh64_Debian_stretch_dev_4.18.0-rc7.img) from armbian officail website, and then burn it into SD card，all going well，any advise ? pls help to check, thanks a lot.

Anarsoul has done a lot of work on the A64 and has custom patches for the Pine A64, SOPine and the Pinebook that have not found their way into mainline yet (his git: https://github.com/anarsoul/). He only does Arch and has no knowledge of Debian/ Ubuntu. I recently asked on Twitter and PINE64 forum which OS users would like to see the Pinebook ship and many users reported Armbian.

If anyone would be willing to help incorporate Anarsoul's work into Armbian so that we could have more features working on the aforementioned devices on mainline, then please have a chat with him in the linux-sunxi or pine64 IRC. 

Cheers,

Dolf.

How do I change the DSI clock for Pine A64-LTS ?

Thank you.

I'm trying to use the emmc device located on the Pine64LTS - not neccessarily to boot (though that would be nice).  I'm employing a 16GB FORESEE card, which I obtained from the Pine folks.

First I installed the Stable SoPine64 Armbian_5.30_Pine64so_Ubuntu_xenial_default_3.10.105 image from the Download web page.  When I booted the image from an microSD card, only /dev/mmcblk0 showed up - no /dev/mmcblk1.  When I tried to boot from the image loaded on the emmc card, the boot failed.

Next I tried to build a more up-to-date image, using:

git clone --depth 1 https://github.com/armbian/build
cd build
./compile.sh

And using the choices for the Pine64so legacy kernel and the full desktop build.  Again the same result: no /dev/mmcblk1.  So, I'm wondering - is it possible to utilize the emmc device on this board (one of its big attractions).

Tom

thank you very much for your comprehensive answers and letting me know that the issue is caused by an EOL fact.

So i changed to the recommended builds, but unfortunately it seems that none of it is bootable, or useable, neither Xenial, nor jessie, not even the newest bionic.

Is there some sort of general problem that makes those builds unbootlable?

Jessie

Xenial

On 7/14/2018 at 12:07 PM, Igor said:

for

I previously had an issue with the ethernet not working at u-boot level using the sopine based R18 board, this I resolved by patching u-boot with the relevant emac sections that were missing from the device tree.

On the custom board we have used the R18 processor with the LAN8720 ethernet-phy chip rather than the RTL8211 used by the pine, and can't get the ethernet to initialise.

We have checked rmii clock timings etc and compared the custom board to the Pine and have noticed the following:-

MDC has been measured to be running at 18.6Mhz, resulting in 53ns pulse periods, on both our custom and the pine64 board.

The minimum MDC clock period for both the lan8720 and rtl8211 however is 400ns according to datasheet.

The ethernet is not working on the LAN, yet it is on the RTL.

It seems the RTL is capable of running at that speed, although spec is 400ns, but the LAN is conforming to it's spec.

Any ideas on how to slow this clock speed down to the minimum 400ns period would be appreciated.

Gavin

I have Pine64+ with LCD + TouchScreen - all from Pine team.

I checked some OS, but only Armbian DE is responsiveness enough for me.

Now, Armbian Jessie is on SD card, stable ISO with all updates and upgrades installed - 3.10.107-pine64.

Change from HDMI to LCD done by changing pine64_lcd to 'on' in /boot/armbianEnv.txt 

I add gt9xxf_ts in /etc/modues and restart Pine64. But cursor doesn't move on any touch.

I confirm that the gt9xxf_ts module loaded by runing 'lsmod' as root, but this module is used by 0 (nobody).

I've checked which event is assigned and I got:

cat /proc/bus/input/devices | grep -B 2 -A 8 gt9xxf_ts

I: Bus=0018 Vendor=dead Product=beef Version=28bb
N: Name="gt9xxf_ts"
P: Phys=input/goodix-ts
S: Sysfs=/devices/virtual/input/input4
U: Uniq=
H: Handlers=event4 autohotplug cpufreq_interactive
B: PROP=2
B: EV=b
B: KEY=400 0 0 0 0 0
B: ABS=265000000000000

I even check if module works correctly. I installed 'evtest' and run it:

apt-get install evtest
evtest /dev/input/event4

I received confirmation that module works:

First part after start testing, second after touching the screen.

Input driver version is 1.0.1
Input device ID: bus 0x18 vendor 0xdead product 0xbeef version 0x28bb
Input device name: "gt9xxf_ts"
Supported events:
  Event type 0 (EV_SYN)
  Event type 1 (EV_KEY)
    Event code 330 (BTN_TOUCH)
  Event type 3 (EV_ABS)
    Event code 48 (ABS_MT_TOUCH_MAJOR)
      Value      0
      Min        0
      Max      255
    Event code 50 (ABS_MT_WIDTH_MAJOR)
      Value      0
      Min        0
      Max      255
    Event code 53 (ABS_MT_POSITION_X)
      Value      0
      Min        0
      Max     1024
    Event code 54 (ABS_MT_POSITION_Y)
      Value      0
      Min        0
      Max      600
    Event code 57 (ABS_MT_TRACKING_ID)
      Value      0
      Min        0
      Max      255
Properties:
  Property type 1 (INPUT_PROP_DIRECT)
Testing ... (interrupt to exit)


[...]
Event: time 1533817457.820178, type 1 (EV_KEY), code 330 (BTN_TOUCH), value 1
Event: time 1533817457.820178, type 3 (EV_ABS), code 53 (ABS_MT_POSITION_X), value 292
Event: time 1533817457.820178, type 3 (EV_ABS), code 54 (ABS_MT_POSITION_Y), value 247
Event: time 1533817457.820178, type 3 (EV_ABS), code 48 (ABS_MT_TOUCH_MAJOR), value 37
Event: time 1533817457.820178, type 3 (EV_ABS), code 50 (ABS_MT_WIDTH_MAJOR), value 37
Event: time 1533817457.820178, type 3 (EV_ABS), code 57 (ABS_MT_TRACKING_ID), value 0
Event: time 1533817457.820178, ++++++++++++++ EV_REL ++++++++++++
Event: time 1533817457.820178, -------------- EV_SYN ------------
Event: time 1533817457.830562, type 3 (EV_ABS), code 53 (ABS_MT_POSITION_X), value 292
Event: time 1533817457.830562, type 3 (EV_ABS), code 54 (ABS_MT_POSITION_Y), value 247
Event: time 1533817457.830562, type 3 (EV_ABS), code 48 (ABS_MT_TOUCH_MAJOR), value 37
Event: time 1533817457.830562, type 3 (EV_ABS), code 50 (ABS_MT_WIDTH_MAJOR), value 37
Event: time 1533817457.830562, type 3 (EV_ABS), code 57 (ABS_MT_TRACKING_ID), value 0
Event: time 1533817457.830562, ++++++++++++++ EV_REL ++++++++++++
Event: time 1533817457.830562, -------------- EV_SYN ------------
Event: time 1533817457.841032, type 3 (EV_ABS), code 53 (ABS_MT_POSITION_X), value 292
Event: time 1533817457.841032, type 3 (EV_ABS), code 54 (ABS_MT_POSITION_Y), value 247
Event: time 1533817457.841032, type 3 (EV_ABS), code 48 (ABS_MT_TOUCH_MAJOR), value 37
Event: time 1533817457.841032, type 3 (EV_ABS), code 50 (ABS_MT_WIDTH_MAJOR), value 37
Event: time 1533817457.841032, type 3 (EV_ABS), code 57 (ABS_MT_TRACKING_ID), value 0
Event: time 1533817457.841032, ++++++++++++++ EV_REL ++++++++++++
Event: time 1533817457.841032, -------------- EV_SYN ------------
Event: time 1533817457.851437, type 3 (EV_ABS), code 53 (ABS_MT_POSITION_X), value 292
Event: time 1533817457.851437, type 3 (EV_ABS), code 54 (ABS_MT_POSITION_Y), value 247
Event: time 1533817457.851437, type 3 (EV_ABS), code 48 (ABS_MT_TOUCH_MAJOR), value 37
Event: time 1533817457.851437, type 3 (EV_ABS), code 50 (ABS_MT_WIDTH_MAJOR), value 37
Event: time 1533817457.851437, type 3 (EV_ABS), code 57 (ABS_MT_TRACKING_ID), value 0
Event: time 1533817457.851437, ++++++++++++++ EV_REL ++++++++++++
Event: time 1533817457.851437, -------------- EV_SYN ------------
Event: time 1533817457.861906, type 3 (EV_ABS), code 53 (ABS_MT_POSITION_X), value 292
Event: time 1533817457.861906, type 3 (EV_ABS), code 54 (ABS_MT_POSITION_Y), value 247
Event: time 1533817457.861906, type 3 (EV_ABS), code 48 (ABS_MT_TOUCH_MAJOR), value 37
Event: time 1533817457.861906, type 3 (EV_ABS), code 50 (ABS_MT_WIDTH_MAJOR), value 37
Event: time 1533817457.861906, type 3 (EV_ABS), code 57 (ABS_MT_TRACKING_ID), value 0
Event: time 1533817457.861906, ++++++++++++++ EV_REL ++++++++++++
Event: time 1533817457.861906, -------------- EV_SYN ------------
Event: time 1533817457.871984, type 3 (EV_ABS), code 53 (ABS_MT_POSITION_X), value 292
Event: time 1533817457.871984, type 3 (EV_ABS), code 54 (ABS_MT_POSITION_Y), value 247
Event: time 1533817457.871984, type 3 (EV_ABS), code 48 (ABS_MT_TOUCH_MAJOR), value 37
Event: time 1533817457.871984, type 3 (EV_ABS), code 50 (ABS_MT_WIDTH_MAJOR), value 37
Event: time 1533817457.871984, type 3 (EV_ABS), code 57 (ABS_MT_TRACKING_ID), value 0
Event: time 1533817457.871984, ++++++++++++++ EV_REL ++++++++++++
Event: time 1533817457.871984, -------------- EV_SYN ------------
Event: time 1533817457.882381, type 1 (EV_KEY), code 330 (BTN_TOUCH), value 0
Event: time 1533817457.882381, type 3 (EV_ABS), code 48 (ABS_MT_TOUCH_MAJOR), value 0
Event: time 1533817457.882381, type 3 (EV_ABS), code 50 (ABS_MT_WIDTH_MAJOR), value 0
Event: time 1533817457.882381, ++++++++++++++ EV_REL ++++++++++++
Event: time 1533817457.882381, -------------- EV_SYN ------------

What I miss to move cursor with touch?

since an Softwareupdate some time ago, i m not able to boot up the Pine64 with any Image.

It doesnt matter what distro, or what channel.

Does anybody have the same issue?

Quote

Loading Environment from FAT... ** Bad Device mmc 0 **

Loading Environment from FAT... Unable to use mmc 0:1... Failed (-5)

Does anybody have any idea what might go wrong? I know it's not stable yet. 
After that message, the device waits for an image from a TFTP Server.

I have a pine64 with the official touch screen, currently running Xenial with legacy kernel.

I followed the instructions to enable the touchscreen:

Also starting with 5.24 Pine64’s own LCD with touchscreen support can simply be activated in  /boot/armbianEnv.txt
by setting pine64_lcd=on and adding gt9xxf_ts to /etc/modules followed by a reboot.

 which works fine.

Preferably, I'd like to use a later kernel, as I'm not interested in any graphical  HW acceleration but would like some of the other improvements in later kernels.

When I tried the instructions with kernel 4.9, I couldn't find the  gt9xxf_ts module.

Is there any way of making this work with vanilla/developer kernels?

BR.

--Marius--

On a Pine64+ using mainline kernel (debian-stretch-next) I chose an interrupt-enabled pin (PH9) updated /boot/armbianEnv.txt with

overlays=pps-gpio uart1 uart2
param_pps_pin=PH9

and rebooted.  I have a device (a GPS) with its PPS output connected to the Pi2 bus pin 13 that corresponds to PH9 and during boot this appears to be configured as a new PPS source:

[    5.548061] pps pps0: new PPS source pps@0.-1
[    5.548135] pps pps0: Registered IRQ 145 as PPS source

/dev/pps0 is indeed created by udev, but unfortunately it never sees any assertions beyond the fist:

root@pine64:~# ppstest /dev/pps0
trying PPS source "/dev/pps0"
found PPS source "/dev/pps0"
ok, found 1 source(s), now start fetching data...
time_pps_fetch() error -1 (Connection timed out)
time_pps_fetch() error -1 (Connection timed out)
time_pps_fetch() error -1 (Connection timed out)
^C
root@pine64:~# cat /sys/class/pps/pps0/assert 
1478193403.873076084#1

I have confirmed the connected device is raising this line for 10ms every 1000ms using a scope and have confirmed this can be seen via the GPIO pin using 'cat' in a while loop to see the value change to 1 and back to 0 each second.

It appears the interrupt is not being raised beyond the initial device creation, which would be the reason pulses are never seen by any clients (such as ppstest)

root@pine64:~# egrep 145 /proc/interrupts 
145:          1          0          0          0  sunxi_pio_edge  41 Edge      pps@0.-1

Would anyone have any thoughts here?  I may try the legacy kernel to see if there is any difference.

First of all, thank you so much for putting these images together. Kudos to you all for some great work! Now on to my issue.

I installed Xenial build and it booted up nicely to XFCE. The only issue I am having is no audio over HDMI. I know the display works for HDMI audio as my nVidia Shield works fine. Any help on determining the issue?

If you need any logs, boot messages, and/or config files, let me know.

Thank you in advance,

Brian

The lastest update/upgrade installs the kernel 4.17. How can I avoid this kernel-update? For my long term-project I need the LTS-kernel 4.14.

Some time ago I updated by mainline-system (Ubuntu server kernel 4.13 to 4.14-kernel with the following command

apt-get  -y -qq --no-install-recommends install linux-image-next-sunxi64 linux-headers-next-sunxi64 linux-u-boot-pine64-next linux-xenial-root-next-pine64 linux-dtb-next-sunxi64

Thanks a lot.

I installed the Armbian legacy with 3.10.107 and was able to get Pine64 headers using apt-get install linux-headers-pine64 but they seem to be missing many files when i try to compile. Any help is greatly appreciated.

>> https://www.facebook.com/Bestmasticatingjuicers.zones

He became famous in the 1980s and 90s because of his prong-like toothbrushes and citrus-juicers for Alessi, his sculptural chairs for Kartell, and his revolutionary interiors for Ian Schrager's first creation of boutique resorts, one of them New York's Royalton along with Miami Beach's Delano. Since then, his interests have ranged wider still, from his StarckBike line of electric bicycles into the Venus, the yacht he made for Steve Jobs. In this year alone, Starck has established a voice- and app-controlled"smart" radiator valve, a trio of touch parfums, along with a modular woodstove and log-storage unit, while also hammering his redesign, in cooperation with his eldest daughter, Ara, of those restaurants in Paris's venerable Le Meurice hotel. Herewith, a few details gleaned from a conversation conducted together with the 67-year-old Frenchman, who spoke from his seaside house in southern Portugal-"a sort of Mies van der Rohe glass shoebox on a dune," as he explained it.

HE CONSIDERS himself to be productive in non-urban, non-office environments, alone but because of his wife, Jasmine, and their young daughter, Justice. HE OWNS several homes abutting a body of water, among them the glass home in Portugal, an oyster farm in southwest France, and island homes on Capri, Formentera (Ibiza's southern sibling), and Burano (near Venice).

HE ATTRIBUTES that this specific real-estate proclivity into an innate need to be proximate to mud. "The mud is essential for me," he states,"because the mud is what we call la soupe primaire -the primordial soup" HE DOES not have a computer and does not have any email address. His concession to contemporary gadgetry-mania is a iPad Mini, which he utilizes primarily as a music player-often with the Zik headphones he made for the French technician company Parrot.

HE LIKES to function with music playing, but just music that's conducive to concentration. His preferred composer-musicians in this respect are the atmospherists Brian Eno, Roger Eno, Alva Noto, and Ryuichi Sakamoto.

https://sites.google.com/site/bestcoldpressjuicers

HE GOES to bed early, about 10:30 P.M., and drops into an eventful, dream-filled sleep in which"I move and go to other worlds," he says. "With other light. With people I have not met. I talk about things that don't exist. I see incredible invention, incredible architecture" HE WAKES up exhausted and, to his chagrin, seldom remembers enough details of his wildest fantasies to incorporate them into his design function.

A RARE exception for this nightly encounter happened in the early 1980s, when, tasked with designing the private quarters at the elysee Palace for France's then president, Franeois Mitterrand, he dreamed of a table with a clear-glass surface atop collapsible metal legs. He hurried from his bed to his sketchbook to design it instantly.

HE WAS only in his late teens when he secured his first major job, helping develop Pierre Cardin's furniture line. Although he admired Cardin's intelligence and modernist aesthetic, he broke with his mentor on philosophical grounds. "My dream was to make one-dollar things for a million individuals; he wanted to make $1 million furniture for a couple of people," he states. HE HAS been requested by prospective customers to rectify the fact that air conditioners are awful by designing a beautiful one, however, has resisted. "The true answer is, open your window," he states. "We overlook easy solutions because it's not good company."

HE JUSTIFIES his getting to the perfume business because (a)"the material part is nothing, 100 grams of fluid," and (b) that he finds a fantastic odor reassuring,"a place in which you feel better, where you feel secure."

HE HAS homes in multiple countries but doesn't believe himself multi-lingual:"My English-we can say it is shit." HE HAS four older children from three preceding relationships. He and Jasmine were wed on December 15, 2007, in Paris.

http://juicerszones.com

HE LAST wore a necktie on such day. He also wore an Australian military-style jacket and a long, black Azzedine Alaea skirt, which proved drafty. HE AND Jasmine drove to their own wedding by motorcycle-a poor choice, given the skirt. "At 11 o'clock at night, I had been in my bed, using a doctor," he says,"and that I nearly die." HIS HAIR is closely cropped and becomingly salt-and-pepper but from the 1980s was a dark-brown, mushroom-shaped pouf.

HE CREDITS his previous look entirely to his friend Jean-Baptiste Mondino, the photographer, who first styled it that way for a take. "I am very, very accurate in my creativity," he states. "But, for myself, my appearance, I don't care. I don't care about my physique. That's the reason why I am too fat."

HE IS a vegetarian. He became one when his only son, Oa, was born 21 years ago. "I found that I did not want everyone to consume my son," he said. "I don't want to kill. It's clearly philosophical."

I have been trying to allocate specific gpio's as input via the Device Tree, this ultimately being for a custom made board.

I can and have successfully allocated pins PB0, PB1, PB3 & PB5, which are showing in /dev/inputs/by-path and have been verified working with evtest.

Working code :-

/dts-v1/;
/plugin/;

/ {

  fragment@0 {
    target = <&pio>;
    __overlay__ {
      input_0: input_0 {
        pins = "PB0";
        function = "gpio_in";
        bias-pull-up;
      };
    };
  };

  fragment@1 {
    target-path = "/";
    __overlay__ {
      button_1 {
        compatible = "gpio-keys";
        pinctrl-names = "default";
        pinctrl-0 = <&input_0>;
        
        Button_1 {
          label = "Button_1";
          linux,code = <2>;
          gpios = <&pio 1 0 1>;
        };
      };
    };
  };
};

However, I need to use GPIO PG2, PG3 PG4 & PG5.

When changing the allocation, both 'pins = "PB0";' in fragment0 and 'gpios = <&pio 1 0 1>;' to PG2 and &pio 6 2 1, then overlay is successfully installed, but however not working.

/dts-v1/;
/plugin/;

/ {

  fragment@0 {
    target = <&pio>;
    __overlay__ {
      input_0: input_0 {
        pins = "PG2";
        function = "gpio_in";
        bias-pull-up;
      };
    };
  };

  fragment@1 {
    target-path = "/";
    __overlay__ {
      button_1 {
        compatible = "gpio-keys";
        pinctrl-names = "default";
        pinctrl-0 = <&input_0>;
        
        Button_1 {
          label = "Button_1";
          linux,code = <2>;
          gpios = <&pio 6 2 1>;
        };
      };
    };
  };
};

I have verified that the pins I intend to use are in fact IRQ pins, and can control the pins via sysfs, by manually exporting, setup and echo to toggle them.

I've haven't seen anything that stands out in the balance of the std Device Tree structure that might be causing this issue.

Any suggestions as to where else I could look into resolving this would be appreciated.

Regards

Gavin B