vlad59

You'll see, you won't regret it comparing to DHT11

Are you sure that DHT11 is really one wire .... As far as I remember I had to use a specific program to access it. And the reliability of this sensor is so low that they went directly to the bin.

almost agree with you... I'll be keeping emmc. About USB, If I remember correctly H6 only has 1USB2 and 1USB3 so just those too would be good (no need for internal usb hubs).

There is a workaround and even when run at 100% CPU for several hours without any heatsink a Banana Pi does not heat that much and is very stable .... At least I'm not interested to spend time searching a fix for that

I build this Dockerfile which allow me to install all the plugins I want : https://github.com/seblucas/alpine-homeassistant/blob/master/Dockerfile But I'm using an external MQTT server, ... I'm sure I don't have all the bells and whistles of hassio but I don't need them.

I'm using home-assistant. never tried hassio.

I'm using Home Assistant for more than one year and if you follow the armbian installation : use a Virtualenv !!!!! or you'll be facing very painful upgrades. I switched to docker images but that's the same spirit.

Just did right now, thanks for the reminder

It won't help a lot but every kernel I tried starting with 4.14 had this problem (I can't remember every single one). Removing the module fixes it for me with no problems.

I can confirm that running theses lines make bluetooth work even after a reboot : root@pine64:~# echo 356 > /sys/class/gpio/export root@pine64:~# echo high > /sys/class/gpio/gpio356/direction root@pine64:~# echo 0 > /sys/class/gpio/gpio356/value && sleep 1 root@pine64:~# echo 1 > /sys/class/gpio/gpio356/value I'll clean that up and do a PR

Thanks all, indeed I was not clear at all. I'll update the script to use gpio356 and try to provide a patch soon

Think I found it : https://github.com/Miouyouyou/MyyQi/issues/7#issuecomment-388589883 The script is there : https://github.com/Miouyouyou/tinkerboard_rtl8723bs/blob/master/reset_bt_through_gpio.sh I'll try that monday after lunch, I forgot my Pine64 at work

@TonyMac32 Thanks will look for that then, thanks a lot

@Raffa As I said your method works fine on my Pine64 but only after the first poweron -> if I reboot (typing reboot on the console) then rtk_hciattach fail after 99 tries. Do you have the same problem with your Orange Pi Prime ?

Rebuild this morning and it now works ! Thanks a lot to you two for that. I'll give a look to what's done for Tinkerboard to see if we can have a proper service doing that.

I does not seem to work. I'll try again with HCIUART_SERDEV=y and HCIUART_3WIRE=y instead of modules and see how it goes. Or my ttyS1 is not the good one.

I'm building an image now will test after lunch

I have three of those (5110 screens), don't know if it was the product / the soldering / .... but only one of those is working with spec (PCD 8544) SPI speed. For the other two I had to lower the bus speed and play with LCD bias / contrast to make them work and they finally worked. I don't know your use case but those 5110 display use less power comparing to small OLED. Certainly due to my laziness I prefer the small i2c OLED (only 4 cables). I still use the 5110 for an arduino running on LIPO.

Si I've tried to make Bluetooth work, but I've failed I saw Igor added Arnarsoul's patch : https://github.com/armbian/build/blob/master/patch/kernel/sunxi-dev/0145-arm64-allwinner-a64-enable-Bluetooth-On-Pine64.patch So I simply update the kernel and rebooted and I thought the uart would magically appear in the boot log but no : root@pine64:~# dmesg | grep -i "serial\|uart\|bt\|blue\|tty" [ 0.000000] Kernel command line: root=UUID=790ebccd-7548-41d1-8134-b625a5df2f4f rootwait rootfstype=ext4 console=ttyS0,115200 console=tty1 panic=10 consoleblank=0 loglevel=1 ubootpart=84ade46c-01 usb-storage.quirks=0x2537:0x1066:u,0x2537:0x1068:u cgroup_enable=memory swapaccount=1 [ 0.000288] console [tty1] enabled [ 0.181520] Serial: AMBA PL011 UART driver [ 1.836148] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled [ 1.861452] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 1.861468] usb usb1: SerialNumber: 1c1a000.usb [ 1.925443] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 1.925460] usb usb2: SerialNumber: 1c1a400.usb [ 1.948103] Btrfs loaded, crc32c=crc32c-arm64-ce [ 1.994198] console [ttyS0] disabled [ 2.014733] 1c28000.serial: ttyS0 at MMIO 0x1c28000 (irq = 23, base_baud = 1500000) is a U6_16550A [ 2.014790] console [ttyS0] enabled [ 2.035888] 1c28400.serial: ttyS1 at MMIO 0x1c28400 (irq = 24, base_baud = 1500000) is a U6_16550A [ 2.057410] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 2.057427] usb usb3: SerialNumber: 1c1b000.usb [ 2.121469] usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 2.121486] usb usb4: SerialNumber: 1c1b400.usb [ 2.123135] usb usb5: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 2.123152] usb usb5: SerialNumber: musb-hdrc.1.auto [ 5.491663] RTL8723BS: rtl8723bs v4.3.5.5_12290.20140916_BTCOEX20140507-4E40 [ 5.491666] RTL8723BS: rtl8723bs BT-Coex version = BTCOEX20140507-4E40 I can see ttys1, is that the bluetooth UART ? I see there's also a patch to enhance rtl8723 driver to become DT-aware : https://github.com/armbian/build/blob/master/patch/kernel/sunxi-dev/0142-Bluetooth-hci_h5-Add-support-for-binding-RTL8723BS-w.patch.disabled But it's currently disabled, I checked git history but did not find a good reason for that. I'll start by enabling this patch and rebuild a kernel but that's starting to become black magic to me I'll be happy to hear advices from other with more knowledge than me

Rockchip need to release the source, Armbian may use it afterwards

IIRC 10bits HEVC is not supported on H3, or am I misinformed ?

So as promised I did some more thorough test with latest Dev on a Banana pi. There's indeed a difference with what I have with 4.14.X. After removing the module I still see a `kworker/1:0-eve` process with ~ 16% CPU for 1 second every 5~6 seconds. I checked again and this does not happen with 4.14.X I'm also letting it run idly for a while to check cpufreq-info I think it will still spend a lot of time at 960MHz (again it does not with 4.14).

@guidol Ok, for the dev kernel, I only tested it for a couple of minutes so I'm not perfectly sure about it. I'll test it later today when back from work. With kernel 4.14, I have two other Banana Pi that are running without this module for months 24/7 without any problems and without any weird kworker CPU usage. I noticed that your hostname is pihole, do you have Pihole running ? Or any other process ?

In my case removing the module completely fixes the problem. rmmod sun4i_gpadc Do you still have the problem without this module ?

Added report for Banana Pi with Dev image. Everything seems to work fine (did not test sata for now). The kworker CPU problem (use search for more information) is still there but removing the module still works (I never managed to stress the CPU enough to go above 55°C so I think removing the module won't cause any problem)