<![CDATA[PINE64 - Linux on Pine H64]]> https://forum.pine64.org/ Sat, 04 Apr 2026 10:30:49 +0000 MyBB <![CDATA[Manjaro update to Kernel 5.18 breaks install]]> https://forum.pine64.org/showthread.php?tid=16807 Fri, 10 Jun 2022 08:02:56 +0000 as365n4]]> https://forum.pine64.org/showthread.php?tid=16807
I downloaded the Manjaro-ARM-minimal-pine-h64-22.04 from Manjaro and flashed it onto an 16GB SD-Card, followed all the on-screen setup instructions/questions, SD-Card got resized and System was up and running.

Next I did the update with pacman and it revoked and signed some keys and had 80something files to update, confirmed with Y and let it run.
After pacman was finished I did a reboot and ended up with a black screen.... Rolleyes 

Got the UART Cable out and recorded the following:
Code:
U-Boot SPL 2021.10-2 (Dec 25 2021 - 19:35:48 +0000)
DRAM: 4096 MiB
Trying to boot from MMC1
NOTICE:  BL31: v2.5(release):d5992a4
NOTICE:  BL31: Built : 19:35:48, Dec 25 2021
NOTICE:  BL31: Detected Allwinner H6 SoC (1728)
NOTICE:  BL31: Found U-Boot DTB at 0xc08ebd0, model: Pine H64 model A


U-Boot 2021.10-2 (Dec 25 2021 - 19:35:48 +0000) Manjaro Linux ARM

CPU:   Allwinner H6 (SUN50I)
Model: Pine H64 model A
DRAM:  3 GiB
MMC:   mmc@4020000: 0, mmc@4022000: 1
Loading Environment from FAT... Unable to read "uboot.env" from mmc0:1... In:    serial@5000000
Out:   serial@5000000
Err:   serial@5000000
Net:   phy interface8
eth0: ethernet@5020000
starting USB...
Bus usb@5101000: USB EHCI 1.00
Bus usb@5101400: USB OHCI 1.0
Bus usb@5311000: USB EHCI 1.00
Bus usb@5311400: USB OHCI 1.0
scanning bus usb@5101000 for devices... 3 USB Device(s) found
scanning bus usb@5101400 for devices... 1 USB Device(s) found
scanning bus usb@5311000 for devices... 1 USB Device(s) found
scanning bus usb@5311400 for devices... 1 USB Device(s) found
       scanning usb for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot:  2  1  0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found /extlinux/extlinux.conf
Retrieving file: /extlinux/extlinux.conf
249 bytes read in 3 ms (81.1 KiB/s)
1:    Manjaro ARM
Retrieving file: /initramfs-linux.img
8553821 bytes read in 425 ms (19.2 MiB/s)
Retrieving file: /Image
24656384 bytes read in 1222 ms (19.2 MiB/s)
append: initrd=/initramfs-linux.img console=ttyS0,115200 root=PARTUUID=24bd05f5-5339-4ae2-8590-23c1846a16bc rw rootwait audit=0 splash plymouth.ignore-serial-consoles
Retrieving file: /dtbs/allwinner/sun50i-h6-pine-h64-model-b.dtb
32213 bytes read in 7 ms (4.4 MiB/s)
Moving Image from 0x40080000 to 0x40200000, end=41a20000
## Flattened Device Tree blob at 4fa00000
   Booting using the fdt blob at 0x4fa00000
   Loading Ramdisk to 497d7000, end 49fff55d ... OK
   Loading Device Tree to 00000000497cc000, end 00000000497d6dd4 ... OK

Starting kernel ...

It appears that the Manjaro 5.18 Kernel is broken. Undecided

Has anybody else this issue and how did you solved it?]]>
I downloaded the Manjaro-ARM-minimal-pine-h64-22.04 from Manjaro and flashed it onto an 16GB SD-Card, followed all the on-screen setup instructions/questions, SD-Card got resized and System was up and running.

Next I did the update with pacman and it revoked and signed some keys and had 80something files to update, confirmed with Y and let it run.
After pacman was finished I did a reboot and ended up with a black screen.... Rolleyes 

Got the UART Cable out and recorded the following:
Code:
U-Boot SPL 2021.10-2 (Dec 25 2021 - 19:35:48 +0000)
DRAM: 4096 MiB
Trying to boot from MMC1
NOTICE:  BL31: v2.5(release):d5992a4
NOTICE:  BL31: Built : 19:35:48, Dec 25 2021
NOTICE:  BL31: Detected Allwinner H6 SoC (1728)
NOTICE:  BL31: Found U-Boot DTB at 0xc08ebd0, model: Pine H64 model A


U-Boot 2021.10-2 (Dec 25 2021 - 19:35:48 +0000) Manjaro Linux ARM

CPU:   Allwinner H6 (SUN50I)
Model: Pine H64 model A
DRAM:  3 GiB
MMC:   mmc@4020000: 0, mmc@4022000: 1
Loading Environment from FAT... Unable to read "uboot.env" from mmc0:1... In:    serial@5000000
Out:   serial@5000000
Err:   serial@5000000
Net:   phy interface8
eth0: ethernet@5020000
starting USB...
Bus usb@5101000: USB EHCI 1.00
Bus usb@5101400: USB OHCI 1.0
Bus usb@5311000: USB EHCI 1.00
Bus usb@5311400: USB OHCI 1.0
scanning bus usb@5101000 for devices... 3 USB Device(s) found
scanning bus usb@5101400 for devices... 1 USB Device(s) found
scanning bus usb@5311000 for devices... 1 USB Device(s) found
scanning bus usb@5311400 for devices... 1 USB Device(s) found
       scanning usb for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot:  2  1  0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found /extlinux/extlinux.conf
Retrieving file: /extlinux/extlinux.conf
249 bytes read in 3 ms (81.1 KiB/s)
1:    Manjaro ARM
Retrieving file: /initramfs-linux.img
8553821 bytes read in 425 ms (19.2 MiB/s)
Retrieving file: /Image
24656384 bytes read in 1222 ms (19.2 MiB/s)
append: initrd=/initramfs-linux.img console=ttyS0,115200 root=PARTUUID=24bd05f5-5339-4ae2-8590-23c1846a16bc rw rootwait audit=0 splash plymouth.ignore-serial-consoles
Retrieving file: /dtbs/allwinner/sun50i-h6-pine-h64-model-b.dtb
32213 bytes read in 7 ms (4.4 MiB/s)
Moving Image from 0x40080000 to 0x40200000, end=41a20000
## Flattened Device Tree blob at 4fa00000
   Booting using the fdt blob at 0x4fa00000
   Loading Ramdisk to 497d7000, end 49fff55d ... OK
   Loading Device Tree to 00000000497cc000, end 00000000497d6dd4 ... OK

Starting kernel ...

It appears that the Manjaro 5.18 Kernel is broken. Undecided

Has anybody else this issue and how did you solved it?]]> <![CDATA[Armbian 22.02 Release Announcement]]> https://forum.pine64.org/showthread.php?tid=16188 Mon, 28 Feb 2022 23:07:24 +0000 TRS-80]]> https://forum.pine64.org/showthread.php?tid=16188 https://www.armbian.com/newsflash/armbia...ouncement/]]> https://www.armbian.com/newsflash/armbia...ouncement/]]> <![CDATA[Analog sound]]> https://forum.pine64.org/showthread.php?tid=15788 Wed, 19 Jan 2022 02:49:48 +0000 acwest]]> https://forum.pine64.org/showthread.php?tid=15788 <![CDATA[U-boot not booting on H64 model B]]> https://forum.pine64.org/showthread.php?tid=15653 Sat, 01 Jan 2022 07:47:24 +0000 CGNZVV]]> https://forum.pine64.org/showthread.php?tid=15653
I'm able to boot Armbian successfully, but the U-Boot I compile never works.

Any help would be appreciated.

I've tried these two scenarios:
- Flash Armbian to an SD card, it boots successfully, then overwrite my U-Boot onto that card, and it fails to boot. Filesystem and partitioning unmodified from what Armbian had, just overwrite U-Boot with dd.
- create an Arch Linux SD card using my U-Boot and rootfs. It fails to boot on the H64. I'm using a very similar method to what I do for an Odroid C4, and it works on the C4 - the C4 has a different uboot, but the process I use to make the SD card is the same.

In both cases, the UART shows:
Code:
U-Boot SPL 2022.01-rc4-00030-gb3f84a939f (Jan 01 2022 - 00:28:05 -0700)
DRAM: 4096 MiB
Trying to boot from MMC1

And it hangs at that last line.
Using the reset button just results in that message being printed again:
Code:
U-Boot SPL 2022.01-rc4-00030-gb3f84a939f (Jan 01 2022 - 00:28:05 -0700)
DRAM: 4096 MiB
Trying to boot from MMC1

U-Boot SPL 2022.01-rc4-00030-gb3f84a939f (Jan 01 2022 - 00:28:05 -0700)
DRAM: 4096 MiB
Trying to boot from MMC1

U-Boot SPL 2022.01-rc4-00030-gb3f84a939f (Jan 01 2022 - 00:28:05 -0700)
DRAM: 4096 MiB
Trying to boot from MMC1

I've also tried doing a power cycle instead of using the reset button, that leads to the same result.

I think I'm creating U-Boot in the right way. Here's what I'm doing (based off of https://github.com/qemu/u-boot/blob/mast...ME.sunxi64, and seems to match what as365n4 is doing in his post @ https://forum.pine64.org/showthread.php?tid=11703):
Code:
# compile ATF

git clone https://github.com/ARM-software/arm-trusted-firmware.git
cd arm-trusted-firmware
CROSS_COMPILE=aarch64-linux-gnu- PLAT=sun50i_h6 make bl31
=> Built build/fvp/release/bl31.bin successfully

# configure and compile U-Boot

git clone https://gitlab.denx.de/u-boot/u-boot.git
cd u-boot

cp ../arm-trusted-firmware/build/fvp/release/bl31.bin .

make pine_h64_defconfig
CROSS_COMPILE=aarch64-linux-gnu- SCP=/dev/null make -j16 all

I've tried master ATF & U-Boot both with and without SCP, compiled as such:
Code:
git clone https://github.com/crust-firmware/crust
cd crust
CROSS_COMPILE=or1k-elf- make pine_h64_defconfig
CROSS_COMPILE=or1k-elf- make scp
And then I copy the scp.bin file to u-boot folder and remove SCP=/dev/null from the make command.
The or1k-elf toolchain is a bit different from the or1k-linux-musl that the sunxi readme suggests, but SCP shouldn't be required anyway in the first place.

I've also tried ATF v2.3 with U-Boot 2020.10, since as365n4 reported that working for him on post 24 of his thread... but same result, hangs at "Trying to boot from MMC1".

Flashing U-Boot to the SD with:
Code:
dd if=u-boot-sunxi-with-spl.bin of=/dev/sda bs=8k seek=1

I've spent a few hours banging my head against this but haven't been able to get any result other than "Trying to boot from MMC1"...]]>
I'm able to boot Armbian successfully, but the U-Boot I compile never works.

Any help would be appreciated.

I've tried these two scenarios:
- Flash Armbian to an SD card, it boots successfully, then overwrite my U-Boot onto that card, and it fails to boot. Filesystem and partitioning unmodified from what Armbian had, just overwrite U-Boot with dd.
- create an Arch Linux SD card using my U-Boot and rootfs. It fails to boot on the H64. I'm using a very similar method to what I do for an Odroid C4, and it works on the C4 - the C4 has a different uboot, but the process I use to make the SD card is the same.

In both cases, the UART shows:
Code:
U-Boot SPL 2022.01-rc4-00030-gb3f84a939f (Jan 01 2022 - 00:28:05 -0700)
DRAM: 4096 MiB
Trying to boot from MMC1

And it hangs at that last line.
Using the reset button just results in that message being printed again:
Code:
U-Boot SPL 2022.01-rc4-00030-gb3f84a939f (Jan 01 2022 - 00:28:05 -0700)
DRAM: 4096 MiB
Trying to boot from MMC1

U-Boot SPL 2022.01-rc4-00030-gb3f84a939f (Jan 01 2022 - 00:28:05 -0700)
DRAM: 4096 MiB
Trying to boot from MMC1

U-Boot SPL 2022.01-rc4-00030-gb3f84a939f (Jan 01 2022 - 00:28:05 -0700)
DRAM: 4096 MiB
Trying to boot from MMC1

I've also tried doing a power cycle instead of using the reset button, that leads to the same result.

I think I'm creating U-Boot in the right way. Here's what I'm doing (based off of https://github.com/qemu/u-boot/blob/mast...ME.sunxi64, and seems to match what as365n4 is doing in his post @ https://forum.pine64.org/showthread.php?tid=11703):
Code:
# compile ATF

git clone https://github.com/ARM-software/arm-trusted-firmware.git
cd arm-trusted-firmware
CROSS_COMPILE=aarch64-linux-gnu- PLAT=sun50i_h6 make bl31
=> Built build/fvp/release/bl31.bin successfully

# configure and compile U-Boot

git clone https://gitlab.denx.de/u-boot/u-boot.git
cd u-boot

cp ../arm-trusted-firmware/build/fvp/release/bl31.bin .

make pine_h64_defconfig
CROSS_COMPILE=aarch64-linux-gnu- SCP=/dev/null make -j16 all

I've tried master ATF & U-Boot both with and without SCP, compiled as such:
Code:
git clone https://github.com/crust-firmware/crust
cd crust
CROSS_COMPILE=or1k-elf- make pine_h64_defconfig
CROSS_COMPILE=or1k-elf- make scp
And then I copy the scp.bin file to u-boot folder and remove SCP=/dev/null from the make command.
The or1k-elf toolchain is a bit different from the or1k-linux-musl that the sunxi readme suggests, but SCP shouldn't be required anyway in the first place.

I've also tried ATF v2.3 with U-Boot 2020.10, since as365n4 reported that working for him on post 24 of his thread... but same result, hangs at "Trying to boot from MMC1".

Flashing U-Boot to the SD with:
Code:
dd if=u-boot-sunxi-with-spl.bin of=/dev/sda bs=8k seek=1

I've spent a few hours banging my head against this but haven't been able to get any result other than "Trying to boot from MMC1"...]]> <![CDATA[Usable headless server distro]]> https://forum.pine64.org/showthread.php?tid=15552 Wed, 15 Dec 2021 13:50:09 +0000 altonian64]]> https://forum.pine64.org/showthread.php?tid=15552 <![CDATA[Icecat on Pine H64]]> https://forum.pine64.org/showthread.php?tid=14585 Wed, 04 Aug 2021 20:24:49 +0000 armuser97]]> https://forum.pine64.org/showthread.php?tid=14585 <![CDATA[Armbian: Ethernet port goes down shortly after successful configuration.]]> https://forum.pine64.org/showthread.php?tid=13643 Fri, 16 Apr 2021 09:05:45 +0000 Kawayuppie]]> https://forum.pine64.org/showthread.php?tid=13643
I am having trouble with Ethernet port on Pine H64 B. When I connect it to a GigE port on a switch, it goes get configured correctly, speed and and address, but quit quickly link goes down and there is no way to resurrect. Vert frustrating. I have yet to try a new kernel, but I am using latest GA of Armbian.

Linux pineh64 5.10.21-sunxi64 #21.02.3 SMP Mon Mar 8 00:45:13 UTC 2021 aarch64 GNU/Linux

These are the errors I see in the dmesg log (journalctl -k).


Quote:Feb 14 10:12:09 pineh64 kernel: dwmac-sun8i 5020000.ethernet eth0: PHY [stmmac-0:01] driver [RTL8211E Gigabit Ethernet] (irq=POLL)

Feb 14 10:12:09 pineh64 kernel: dwmac-sun8i 5020000.ethernet eth0: No Safety Features support found
Feb 14 10:12:09 pineh64 kernel: dwmac-sun8i 5020000.ethernet eth0: No MAC Management Counters available
Feb 14 10:12:09 pineh64 kernel: dwmac-sun8i 5020000.ethernet eth0: PTP not supported by HW
Feb 14 10:12:09 pineh64 kernel: dwmac-sun8i 5020000.ethernet eth0: configuring for phy/rgmii-id link mode
Feb 14 10:12:09 pineh64 kernel: rtl8723bs: acquire FW from file:rtlwifi/rtl8723bs_nic.bin
Feb 14 10:12:13 pineh64 kernel: dwmac-sun8i 5020000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
Feb 14 10:12:13 pineh64 kernel: IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Feb 14 10:12:15 pineh64 kernel: broken atomic modeset userspace detected, disabling atomic
Feb 14 10:12:18 pineh64 kernel: fuse: init (API version 7.32)
Feb 14 10:12:27 pineh64 kernel: vcc3v3: disabling
Feb 14 10:12:27 pineh64 kernel: vcc1v8: disabling
Feb 14 10:12:27 pineh64 kernel: vcc-ac200: disabling
Feb 14 10:12:28 pineh64 kernel: dwmac-sun8i 5020000.ethernet eth0: Link is Down


I will see if I can get a later kernel and try that but, however, in the meantime if someone who knows how to fix this, please let  me know.]]>
I am having trouble with Ethernet port on Pine H64 B. When I connect it to a GigE port on a switch, it goes get configured correctly, speed and and address, but quit quickly link goes down and there is no way to resurrect. Vert frustrating. I have yet to try a new kernel, but I am using latest GA of Armbian.

Linux pineh64 5.10.21-sunxi64 #21.02.3 SMP Mon Mar 8 00:45:13 UTC 2021 aarch64 GNU/Linux

These are the errors I see in the dmesg log (journalctl -k).


Quote:Feb 14 10:12:09 pineh64 kernel: dwmac-sun8i 5020000.ethernet eth0: PHY [stmmac-0:01] driver [RTL8211E Gigabit Ethernet] (irq=POLL)

Feb 14 10:12:09 pineh64 kernel: dwmac-sun8i 5020000.ethernet eth0: No Safety Features support found
Feb 14 10:12:09 pineh64 kernel: dwmac-sun8i 5020000.ethernet eth0: No MAC Management Counters available
Feb 14 10:12:09 pineh64 kernel: dwmac-sun8i 5020000.ethernet eth0: PTP not supported by HW
Feb 14 10:12:09 pineh64 kernel: dwmac-sun8i 5020000.ethernet eth0: configuring for phy/rgmii-id link mode
Feb 14 10:12:09 pineh64 kernel: rtl8723bs: acquire FW from file:rtlwifi/rtl8723bs_nic.bin
Feb 14 10:12:13 pineh64 kernel: dwmac-sun8i 5020000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
Feb 14 10:12:13 pineh64 kernel: IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Feb 14 10:12:15 pineh64 kernel: broken atomic modeset userspace detected, disabling atomic
Feb 14 10:12:18 pineh64 kernel: fuse: init (API version 7.32)
Feb 14 10:12:27 pineh64 kernel: vcc3v3: disabling
Feb 14 10:12:27 pineh64 kernel: vcc1v8: disabling
Feb 14 10:12:27 pineh64 kernel: vcc-ac200: disabling
Feb 14 10:12:28 pineh64 kernel: dwmac-sun8i 5020000.ethernet eth0: Link is Down


I will see if I can get a later kernel and try that but, however, in the meantime if someone who knows how to fix this, please let  me know.]]> <![CDATA[DietPi OS for PINE H64]]> https://forum.pine64.org/showthread.php?tid=12531 Wed, 16 Dec 2020 13:22:20 +0000 MichaIng]]> https://forum.pine64.org/showthread.php?tid=12531

DietPi is an extremely lightweight Debian-based OS. It is highly optimised for minimal CPU and RAM resource usage, ensuring your PINE H64 always runs at its maximum potential.

Use dietpi-software to quick and easy install Ready to Run & Optimised applications for your system. DietPi will do all the necessary configurations, including starting the services.

DietPi images are available for PINE A64, PINE H64, Pinebook, ROCK64 and ROCKPro64.

Our PINE64 images are based on the great kernel and firmware, developed by Armbian. However, if you face any issues, please contact us via forum or GitHub issue first.

Website: https://dietpi.com/
Download images: https://dietpi.com/#download
Documentation: https://dietpi.com/docs/
Forums: https://dietpi.com/phpbb/
GitHub repository: https://github.com/MichaIng/DietPi

DietPi is a free and open-source project. We are be happy if you consider to contribute or donate: https://dietpi.com/contribute.html
Consider to share your donation between DietPi and Armbian.]]>

DietPi is an extremely lightweight Debian-based OS. It is highly optimised for minimal CPU and RAM resource usage, ensuring your PINE H64 always runs at its maximum potential.

Use dietpi-software to quick and easy install Ready to Run & Optimised applications for your system. DietPi will do all the necessary configurations, including starting the services.

DietPi images are available for PINE A64, PINE H64, Pinebook, ROCK64 and ROCKPro64.

Our PINE64 images are based on the great kernel and firmware, developed by Armbian. However, if you face any issues, please contact us via forum or GitHub issue first.

Website: https://dietpi.com/
Download images: https://dietpi.com/#download
Documentation: https://dietpi.com/docs/
Forums: https://dietpi.com/phpbb/
GitHub repository: https://github.com/MichaIng/DietPi

DietPi is a free and open-source project. We are be happy if you consider to contribute or donate: https://dietpi.com/contribute.html
Consider to share your donation between DietPi and Armbian.]]> <![CDATA[Enabling UART2]]> https://forum.pine64.org/showthread.php?tid=12103 Tue, 10 Nov 2020 19:06:09 +0000 rgreen]]> https://forum.pine64.org/showthread.php?tid=12103 UPDATE: Solved.

uart2 is the Devil.  Long live uart3.  Enabled ias overlay on /dev/ttyS3 and Pi2 Bus Pins 37 and 36 (which differ between models)


I'm trying to adapt an Elelab Zigbee Shield( https://elelabs.com/products/elelabs-zigbee-shield.html) for use on a H64b but I'm finding it very difficult given the "Pi2" GPIO block is not actually compatible with pi shields.  The device works on simple (and universal) serial connection@115200 baud.  It should be trivial to get working and I can't figure out why .

So where I'm at with the h64b:
uname -a:
Code:
Linux ServerName 5.8.16-sunxi64 #20.08.16 SMP Sat Oct 24 23:52:46 CEST 2020 aarch64 GNU/Linux


According to schematics, there 5 system UART.  One of which is the console (uart0)
  • uart0 is the bitch of uboot and then getty.
  • uart1 is attached to pins on the wifi
  • uart2 is attached to the GPIO as the second function of pins 8 and 10
  • uart3 is, maybe, attached to GPIO mysteriously at pins 38 and 37
  • uart4 is a mysterious unicorn that is no longer enabled in many linux flavours.
Enabling uart2 causes the system to hang on reboot.  I don't have a 3.3v serial USB dongle so I can't currently read off uart0 at boot to see what's going on Sad I'd prefer to use this end of the GPIO but I'd go anywhere on the board to make this work.

Only uart2 and uart3 are suitable for my use case.  I've used device tree overlays to enable uart1 and uart3, but there is no README for the H6 in the /boot/dtb/allwinner/overlays/ folder like there is for the A64 and H5 chips so I'm flying a little blind.

Originally, while still targeting uart2, I decompiled the dtb and tore it apart in a couple different ways (removing all other uarts, rearranging serial@, pnctrl, etc) but I was never able to enable by overlay uart2 without hanging the system.

enabling uart3 works according to dmesg | grep serial:
Code:
[    2.243978] sun50i-h6-pinctrl 300b000.pinctrl: pin-198 (5000400.serial) status -517
[    2.244013] dw-apb-uart 5000400.serial: Error applying setting, reverse things back
[    2.244292] sun50i-h6-pinctrl 300b000.pinctrl: pin-119 (5000c00.serial) status -517
[    2.244328] dw-apb-uart 5000c00.serial: Error applying setting, reverse things back
[    2.246801] sun50i-h6-pinctrl 300b000.pinctrl: pin-198 (5000400.serial) status -517
[    2.246837] dw-apb-uart 5000400.serial: Error applying setting, reverse things back
[    2.247109] sun50i-h6-pinctrl 300b000.pinctrl: pin-119 (5000c00.serial) status -517
[    2.247145] dw-apb-uart 5000c00.serial: Error applying setting, reverse things back
[    2.647327] sun50i-h6-pinctrl 300b000.pinctrl: pin-198 (5000400.serial) status -517
[    2.647364] dw-apb-uart 5000400.serial: Error applying setting, reverse things back
[    2.647856] sun50i-h6-pinctrl 300b000.pinctrl: pin-119 (5000c00.serial) status -517
[    2.647893] dw-apb-uart 5000c00.serial: Error applying setting, reverse things back
[    2.704724] 5000400.serial: ttyS1 at MMIO 0x5000400 (irq = 26, base_baud = 1500000) is a 16550A
[    2.706044] 5000c00.serial: ttyS3 at MMIO 0x5000c00 (irq = 27, base_baud = 1500000) is a 16550A


Ok, I'm targeting my final option, uart3.  I've got the shield hooked to the 3v, Tx->RX(Pin 38), rx->TX(Pin 37), GND->GND(Pin 39).  But nothing!

Just before I threw up my hands in defeat last night, I came across the post for the similar issues with a z-wave shield on the A64+ (https://forum.pine64.org/showthread.php?...3#pid20643).  Their diagram: http://i0.wp.com/blog.etiennebretteville...otique.jpg indicates 100k resistors.  Do those pull the the pins high, serving UART instead of it's primary function?

Can someone explain how I can get this device to talk to uart3 or, preferably, how to do the same on uart2 without the system hanging?

Cheers,
R.]]> UPDATE: Solved.

uart2 is the Devil.  Long live uart3.  Enabled ias overlay on /dev/ttyS3 and Pi2 Bus Pins 37 and 36 (which differ between models)


I'm trying to adapt an Elelab Zigbee Shield( https://elelabs.com/products/elelabs-zigbee-shield.html) for use on a H64b but I'm finding it very difficult given the "Pi2" GPIO block is not actually compatible with pi shields.  The device works on simple (and universal) serial connection@115200 baud.  It should be trivial to get working and I can't figure out why .

So where I'm at with the h64b:
uname -a:
Code:
Linux ServerName 5.8.16-sunxi64 #20.08.16 SMP Sat Oct 24 23:52:46 CEST 2020 aarch64 GNU/Linux


According to schematics, there 5 system UART.  One of which is the console (uart0)
  • uart0 is the bitch of uboot and then getty.
  • uart1 is attached to pins on the wifi
  • uart2 is attached to the GPIO as the second function of pins 8 and 10
  • uart3 is, maybe, attached to GPIO mysteriously at pins 38 and 37
  • uart4 is a mysterious unicorn that is no longer enabled in many linux flavours.
Enabling uart2 causes the system to hang on reboot.  I don't have a 3.3v serial USB dongle so I can't currently read off uart0 at boot to see what's going on Sad I'd prefer to use this end of the GPIO but I'd go anywhere on the board to make this work.

Only uart2 and uart3 are suitable for my use case.  I've used device tree overlays to enable uart1 and uart3, but there is no README for the H6 in the /boot/dtb/allwinner/overlays/ folder like there is for the A64 and H5 chips so I'm flying a little blind.

Originally, while still targeting uart2, I decompiled the dtb and tore it apart in a couple different ways (removing all other uarts, rearranging serial@, pnctrl, etc) but I was never able to enable by overlay uart2 without hanging the system.

enabling uart3 works according to dmesg | grep serial:
Code:
[    2.243978] sun50i-h6-pinctrl 300b000.pinctrl: pin-198 (5000400.serial) status -517
[    2.244013] dw-apb-uart 5000400.serial: Error applying setting, reverse things back
[    2.244292] sun50i-h6-pinctrl 300b000.pinctrl: pin-119 (5000c00.serial) status -517
[    2.244328] dw-apb-uart 5000c00.serial: Error applying setting, reverse things back
[    2.246801] sun50i-h6-pinctrl 300b000.pinctrl: pin-198 (5000400.serial) status -517
[    2.246837] dw-apb-uart 5000400.serial: Error applying setting, reverse things back
[    2.247109] sun50i-h6-pinctrl 300b000.pinctrl: pin-119 (5000c00.serial) status -517
[    2.247145] dw-apb-uart 5000c00.serial: Error applying setting, reverse things back
[    2.647327] sun50i-h6-pinctrl 300b000.pinctrl: pin-198 (5000400.serial) status -517
[    2.647364] dw-apb-uart 5000400.serial: Error applying setting, reverse things back
[    2.647856] sun50i-h6-pinctrl 300b000.pinctrl: pin-119 (5000c00.serial) status -517
[    2.647893] dw-apb-uart 5000c00.serial: Error applying setting, reverse things back
[    2.704724] 5000400.serial: ttyS1 at MMIO 0x5000400 (irq = 26, base_baud = 1500000) is a 16550A
[    2.706044] 5000c00.serial: ttyS3 at MMIO 0x5000c00 (irq = 27, base_baud = 1500000) is a 16550A


Ok, I'm targeting my final option, uart3.  I've got the shield hooked to the 3v, Tx->RX(Pin 38), rx->TX(Pin 37), GND->GND(Pin 39).  But nothing!

Just before I threw up my hands in defeat last night, I came across the post for the similar issues with a z-wave shield on the A64+ (https://forum.pine64.org/showthread.php?...3#pid20643).  Their diagram: http://i0.wp.com/blog.etiennebretteville...otique.jpg indicates 100k resistors.  Do those pull the the pins high, serving UART instead of it's primary function?

Can someone explain how I can get this device to talk to uart3 or, preferably, how to do the same on uart2 without the system hanging?

Cheers,
R.]]> <![CDATA[Ethernet Issues on DietPi]]> https://forum.pine64.org/showthread.php?tid=11886 Tue, 20 Oct 2020 18:25:27 +0000 rgreen]]> https://forum.pine64.org/showthread.php?tid=11886
I was really looking forward to moving our self-hosted services to a more capable SBC.  I need a solid ethernet connection that the H64b doesn't seem to want to provide.  I'm going to check with Manjaro build, but arch isn't my flavour and I'm not looking to manage a single non-debian based distro.

Am I sending this thing back to Pine?  What was the purpose of the h64 if it's barely supported by anything?]]>
I was really looking forward to moving our self-hosted services to a more capable SBC.  I need a solid ethernet connection that the H64b doesn't seem to want to provide.  I'm going to check with Manjaro build, but arch isn't my flavour and I'm not looking to manage a single non-debian based distro.

Am I sending this thing back to Pine?  What was the purpose of the h64 if it's barely supported by anything?]]> <![CDATA[Correct setup for u-boot and fstab ? Device not booting]]> https://forum.pine64.org/showthread.php?tid=11703 Fri, 02 Oct 2020 15:11:54 +0000 as365n4]]> https://forum.pine64.org/showthread.php?tid=11703
I have build Arm-Trusted-Firmware and U-Boot from git/source and got the u-boot-sunxi-with-spl.bin file which I copied with "sudo dd if=u-boot-sunxi-with-spl.bin of=/dev/sdX bs=1024 seek=8" to my eMMC-Module.

My fstab is as below, with /boot flagged as bootable by fdisk.

/dev/mmcblk1p1    /boot    ext2    defaults    0    2
/dev/mmcblk1p2    /           ext4    errors=remount-ro    0    1
/dev/mmcblk1p3    swap   swap    defaults    0    0

Then powered up the H64B only shows that he has loaded u-boot and then stops/hangs and does not carry on to load Linux from /boot.

Am I missing something ???
Any adivce would be greatly appreciated.
I am tinkering with this for a while now and can't get past the U-Boot SPL prompt....

Here is that i am doing https://github.com/as365n4/Debian_on_Pin...neH64B.pdf]]>
I have build Arm-Trusted-Firmware and U-Boot from git/source and got the u-boot-sunxi-with-spl.bin file which I copied with "sudo dd if=u-boot-sunxi-with-spl.bin of=/dev/sdX bs=1024 seek=8" to my eMMC-Module.

My fstab is as below, with /boot flagged as bootable by fdisk.

/dev/mmcblk1p1    /boot    ext2    defaults    0    2
/dev/mmcblk1p2    /           ext4    errors=remount-ro    0    1
/dev/mmcblk1p3    swap   swap    defaults    0    0

Then powered up the H64B only shows that he has loaded u-boot and then stops/hangs and does not carry on to load Linux from /boot.

Am I missing something ???
Any adivce would be greatly appreciated.
I am tinkering with this for a while now and can't get past the U-Boot SPL prompt....

Here is that i am doing https://github.com/as365n4/Debian_on_Pin...neH64B.pdf]]> <![CDATA[Mainline Status of the H64]]> https://forum.pine64.org/showthread.php?tid=10645 Sun, 12 Jul 2020 20:19:17 +0000 kuleszdl]]> https://forum.pine64.org/showthread.php?tid=10645
I played around with the H64 on the mainline kernel in Debian unstable (5.7) and the latest uboot (v2020.07). Unfortunately, it seems that neither eMMC storage nor the networking are supported in Linux. They get both detected in uboot and booting from eMMC starts successfully.

I guess this board is not supported yet in mainline, isn't it?]]>
I played around with the H64 on the mainline kernel in Debian unstable (5.7) and the latest uboot (v2020.07). Unfortunately, it seems that neither eMMC storage nor the networking are supported in Linux. They get both detected in uboot and booting from eMMC starts successfully.

I guess this board is not supported yet in mainline, isn't it?]]> <![CDATA[Looking for Linux decoder/encoder API in H6 as well as any transcoding example]]> https://forum.pine64.org/showthread.php?tid=8578 Tue, 17 Dec 2019 08:48:26 +0000 gojustingo]]> https://forum.pine64.org/showthread.php?tid=8578

Dear community,

Please allow me to ask a very basic question here. 

Can anyone help me where to find decoder/encoder Linux API's in H6 as well as any transcoding exemplary code by using those API's?


Justin]]>

Dear community,

Please allow me to ask a very basic question here. 

Can anyone help me where to find decoder/encoder Linux API's in H6 as well as any transcoding exemplary code by using those API's?


Justin]]> <![CDATA[Fedora on aarch64 Architecture]]> https://forum.pine64.org/showthread.php?tid=8354 Sun, 17 Nov 2019 11:54:13 +0000 as365n4]]> https://forum.pine64.org/showthread.php?tid=8354
Download the image here --> https://alt.fedoraproject.org/alt/
Similar to Armbian you can have different flavours like Server, Minimal, Workstation, Cloud etc.

To get the image onto your H64 do the following:

sudo dnf install arm-image-installer uboot-images-armv8
sudo arm-image-installer --image=/home/YOURuser/Downloads/Fedora-Workstation-31-1.9.aarch64.raw.xz --target=pine_h64 --media=/dev/sd? (use lsblk to find media)

It takes about 2min15sec from applying power to fully booted Desktop Environment.
It's a full Gnome 3 Desktop like on x86 with Firefox, LibreOffice and other apps pre-installed.
WiFi and Audio do NOT work at the moment (Fedora-Workstation-31-1.9).
And Video playback speed varies from slideshow on FullHD to acceptable on SVGA resolution.
Also there is NO support for eMMc only SD-Card works.


Other supported boards are: pine64-lts, pine64_plus, pinebook and sopine_baseboard amongst a variety of other makes.]]>
Download the image here --> https://alt.fedoraproject.org/alt/
Similar to Armbian you can have different flavours like Server, Minimal, Workstation, Cloud etc.

To get the image onto your H64 do the following:

sudo dnf install arm-image-installer uboot-images-armv8
sudo arm-image-installer --image=/home/YOURuser/Downloads/Fedora-Workstation-31-1.9.aarch64.raw.xz --target=pine_h64 --media=/dev/sd? (use lsblk to find media)

It takes about 2min15sec from applying power to fully booted Desktop Environment.
It's a full Gnome 3 Desktop like on x86 with Firefox, LibreOffice and other apps pre-installed.
WiFi and Audio do NOT work at the moment (Fedora-Workstation-31-1.9).
And Video playback speed varies from slideshow on FullHD to acceptable on SVGA resolution.
Also there is NO support for eMMc only SD-Card works.


Other supported boards are: pine64-lts, pine64_plus, pinebook and sopine_baseboard amongst a variety of other makes.]]> <![CDATA[Manjaro Arm on the pineH64]]> https://forum.pine64.org/showthread.php?tid=8323 Thu, 14 Nov 2019 11:03:15 +0000 roel]]> https://forum.pine64.org/showthread.php?tid=8323