joaofl

Nice job! Have you released the design files, or any means to buy your adapter? Do you have any tips on booting from the external SSD?

It seems that there is luck involved. If you read on that patch available you see that: https://github.com/phelum/CT_Bluetooth

Nice that you got it working, at least once. I actually also got it working a couple of time, but it would go fail to reset again after a reboot. I still did not find the time to look deeper into it. Ill see if I find the time this week. I also manged to get the firmware loaded, but it almost always will fail to reset. I still believe it has to do with some additional pins that have to be toggled to reset the bt module. Have to look at the schematics in one hand, and device trees in the other to see if things are mapped properly. Looking back at the legacy device tree (in which it use to work), may also give us a hint.

So if I understood correctly, the idea is to detach the ttyS1 from the bluetooth device, so that it can be used as a normal tty device, so that the operations can be carried by the hack done in https://github.com/phelum/CT_Bluetooth. Right? Thing is that with the device tree he provides there, the overlays wont work, and the board wont even boot up. So I guess we need to patch the serial port overlays and give another try.

Yes, I do have the serial port in place. Still the same issue when reseting `hci0` ls /sys/devices/platform/soc/1c28800.serial/ driver driver_override modalias of_node power serial0 subsystem uevent dmesg | grep ttyS [ 0.000000] Kernel command line: root=UUID=69f5d75b-1ab7-4ffd-80a6-17d11e5447e2 rootwait rootfstype=ext4 console=ttyS0,115200 console=tty1 hdmi.audio=EDID:0 disp.screen0_output_mode=1920x1080p60 consoleblank=0 loglevel=1 ubootpart=0e31188e-01 ubootsource=mmc usb-storage.quirks=0x2537:0x1066:u,0x2537:0x1068:u sunxi_ve_mem_reserve=0 sunxi_g2d_mem_reserve=0 sunxi_fb_mem_reserve=16 cgroup_enable=memory swapaccount=1 [ 2.450365] printk: console [ttyS0] disabled [ 2.470572] 1c28000.serial: ttyS0 at MMIO 0x1c28000 (irq = 51, base_baud = 1500000) is a U6_16550A [ 2.470642] printk: console [ttyS0] enabled [ 2.491835] 1c28800.serial: ttyS1 at MMIO 0x1c28800 (irq = 52, base_baud = 1500000) is a U6_16550A [ 2.492030] serial serial0: tty port ttyS1 registered [ 2.515067] 1c28c00.serial: ttyS2 at MMIO 0x1c28c00 (irq = 53, base_baud = 1500000) is a U6_16550A [ 2.538141] 1c29000.serial: ttyS3 at MMIO 0x1c29000 (irq = 54, base_baud = 1500000) is a U6_16550A [ 2.561222] 1c29400.serial: ttyS4 at MMIO 0x1c29400 (irq = 55, base_baud = 1500000) is a U6_16550A [ 2.584406] 1c29c00.serial: ttyS5 at MMIO 0x1c29c00 (irq = 57, base_baud = 1500000) is a U6_16550A [ 10.676268] systemd[1]: Found device /dev/ttyS0. EDIT: But indeed, `/dev/ttyS1` is not there... Not sure what this means.

Actually I have realized that because u-boot fails to load the first overlay: Applying kernel provided DT overlay sun7i-a20-can.dtbo failed on fdt_overlay_apply(): FDT_ERR_NOTFOUND 500 bytes read in 4 ms (122.1 KiB/s) Then the following ones will also fail. Cant tell why. So after removing the faulty ones from `/boot/armbianEnv.txt` list, I got the overlays loaded successfully. So I though that once the serial and spi ports got their overlay loaded, that the device would work and consequently the Bluetooth. But still, no bluetooth... [ 11.422077] Bluetooth: Core ver 2.22 [ 11.422216] Bluetooth: HCI device and connection manager initialized [ 11.422242] Bluetooth: HCI socket layer initialized [ 11.422254] Bluetooth: L2CAP socket layer initialized [ 11.422283] Bluetooth: SCO socket layer initialized [ 11.735777] Bluetooth: HCI UART driver ver 2.3 [ 11.735791] Bluetooth: HCI UART protocol H4 registered [ 11.735796] Bluetooth: HCI UART protocol BCSP registered [ 11.735901] Bluetooth: HCI UART protocol LL registered [ 11.735906] Bluetooth: HCI UART protocol ATH3K registered [ 11.735963] Bluetooth: HCI UART protocol Three-wire (H5) registered [ 11.736254] Bluetooth: HCI UART protocol Intel registered [ 11.736524] Bluetooth: HCI UART protocol Broadcom registered [ 11.736589] Bluetooth: HCI UART protocol QCA registered [ 11.736594] Bluetooth: HCI UART protocol AG6XX registered [ 11.736676] Bluetooth: HCI UART protocol Marvell registered [ 14.055469] Bluetooth: hci0: command 0xfc18 tx timeout [ 21.468312] Bluetooth: BNEP (Ethernet Emulation) ver 1.3 [ 21.468325] Bluetooth: BNEP filters: protocol multicast [ 21.468351] Bluetooth: BNEP socket layer initialized [ 22.247521] Bluetooth: hci0: BCM: failed to write update baudrate (-110) [ 22.247534] Bluetooth: hci0: Failed to set baudrate [ 24.263479] Bluetooth: hci0: command 0x0c03 tx timeout [ 32.487473] Bluetooth: hci0: BCM: Reset failed (-110)

I believe I found the reason why. The device tree overlays of the the board-specific peripherals are not being loaded correctly by u-boot. Not sure how to fix it. Any ideas @Werner? Find below the u-boot logs: U-Boot 2020.04-armbian (Jul 15 2020 - 13:11:40 +0200) Allwinner Technology CPU: Allwinner A20 (SUN7I) Model: Cubietech Cubietruck I2C: ready DRAM: 2 GiB MMC: mmc@1c0f000: 0, mmc@1c12000: 1 Loading Environment from FAT... Card did not respond to voltage select! Setting up a 1024x768 vga console (overscan 0x0) In: serial Out: vga Err: vga Allwinner mUSB OTG (Peripheral) Net: eth0: ethernet@1c50000 Warning: usb_ether using MAC address from ROM , eth1: usb_ether 230454 bytes read in 15 ms (14.7 MiB/s) starting USB... Bus usb@1c14000: USB EHCI 1.00 Bus usb@1c14400: USB OHCI 1.0 Bus usb@1c1c000: USB EHCI 1.00 Bus usb@1c1c400: USB OHCI 1.0 scanning bus usb@1c14000 for devices... 1 USB Device(s) found scanning bus usb@1c14400 for devices... 1 USB Device(s) found scanning bus usb@1c1c000 for devices... 1 USB Device(s) found scanning bus usb@1c1c400 for devices... 2 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Autoboot in 1 seconds, press <Space> to stop switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found U-Boot script /boot/boot.scr 3967 bytes read in 2 ms (1.9 MiB/s) ## Executing script at 43100000 U-boot loaded from SD Boot script loaded from mmc 350 bytes read in 2 ms (170.9 KiB/s) 10965901 bytes read in 605 ms (17.3 MiB/s) 7172168 bytes read in 397 ms (17.2 MiB/s) Found mainline kernel configuration 42521 bytes read in 8 ms (5.1 MiB/s) 386 bytes read in 4 ms (93.8 KiB/s) Applying kernel provided DT overlay sun7i-a20-can.dtbo failed on fdt_overlay_apply(): FDT_ERR_NOTFOUND 500 bytes read in 4 ms (122.1 KiB/s) Applying kernel provided DT overlay sun7i-a20-i2c1.dtbo failed on fdt_overlay_apply(): FDT_ERR_BADMAGIC base fdt does did not have a /__symbols__ node make sure you've compiled with -@ 500 bytes read in 4 ms (122.1 KiB/s) Applying kernel provided DT overlay sun7i-a20-i2c2.dtbo failed on fdt_overlay_apply(): FDT_ERR_BADMAGIC base fdt does did not have a /__symbols__ node make sure you've compiled with -@ 500 bytes read in 4 ms (122.1 KiB/s) Applying kernel provided DT overlay sun7i-a20-i2c3.dtbo failed on fdt_overlay_apply(): FDT_ERR_BADMAGIC base fdt does did not have a /__symbols__ node make sure you've compiled with -@ 766 bytes read in 4 ms (186.5 KiB/s) Applying kernel provided DT overlay sun7i-a20-i2c4.dtbo failed on fdt_overlay_apply(): FDT_ERR_BADMAGIC base fdt does did not have a /__symbols__ node make sure you've compiled with -@ 590 bytes read in 5 ms (115.2 KiB/s) Applying kernel provided DT overlay sun7i-a20-mmc2.dtbo failed on fdt_overlay_apply(): FDT_ERR_BADMAGIC base fdt does did not have a /__symbols__ node make sure you've compiled with -@ 2301 bytes read in 4 ms (561.5 KiB/s) Applying kernel provided DT overlay sun7i-a20-nand.dtbo failed on fdt_overlay_apply(): FDT_ERR_BADMAGIC base fdt does did not have a /__symbols__ node make sure you've compiled with -@ 778 bytes read in 5 ms (151.4 KiB/s) Applying kernel provided DT overlay sun7i-a20-pps-gpio.dtbo failed on fdt_overlay_apply(): FDT_ERR_BADMAGIC base fdt does did not have a /__symbols__ node make sure you've compiled with -@ 443 bytes read in 4 ms (107.4 KiB/s) Applying kernel provided DT overlay sun7i-a20-pwm.dtbo failed on fdt_overlay_apply(): FDT_ERR_BADMAGIC base fdt does did not have a /__symbols__ node make sure you've compiled with -@ 1040 bytes read in 4 ms (253.9 KiB/s) Applying kernel provided DT overlay sun7i-a20-spdif-out.dtbo failed on fdt_overlay_apply(): FDT_ERR_BADMAGIC base fdt does did not have a /__symbols__ node make sure you've compiled with -@ 556 bytes read in 4 ms (135.7 KiB/s) Applying kernel provided DT overlay sun7i-a20-spi-add-cs1.dtbo failed on fdt_overlay_apply(): FDT_ERR_BADMAGIC base fdt does did not have a /__symbols__ node make sure you've compiled with -@ 1093 bytes read in 5 ms (212.9 KiB/s) Applying kernel provided DT overlay sun7i-a20-spi-jedec-nor.dtbo failed on fdt_overlay_apply(): FDT_ERR_BADMAGIC base fdt does did not have a /__symbols__ node make sure you've compiled with -@ 1069 bytes read in 5 ms (208 KiB/s) Applying kernel provided DT overlay sun7i-a20-spi-spidev.dtbo failed on fdt_overlay_apply(): FDT_ERR_BADMAGIC base fdt does did not have a /__symbols__ node make sure you've compiled with -@ 808 bytes read in 5 ms (157.2 KiB/s) Applying kernel provided DT overlay sun7i-a20-uart2.dtbo failed on fdt_overlay_apply(): FDT_ERR_BADMAGIC base fdt does did not have a /__symbols__ node make sure you've compiled with -@ 1078 bytes read in 5 ms (210 KiB/s) Applying kernel provided DT overlay sun7i-a20-uart3.dtbo failed on fdt_overlay_apply(): FDT_ERR_BADMAGIC base fdt does did not have a /__symbols__ node make sure you've compiled with -@ 513 bytes read in 5 ms (99.6 KiB/s) Applying kernel provided DT overlay sun7i-a20-uart4.dtbo failed on fdt_overlay_apply(): FDT_ERR_BADMAGIC base fdt does did not have a /__symbols__ node make sure you've compiled with -@ 513 bytes read in 5 ms (99.6 KiB/s) Applying kernel provided DT overlay sun7i-a20-uart5.dtbo failed on fdt_overlay_apply(): FDT_ERR_BADMAGIC base fdt does did not have a /__symbols__ node make sure you've compiled with -@ 513 bytes read in 5 ms (99.6 KiB/s) Applying kernel provided DT overlay sun7i-a20-uart6.dtbo failed on fdt_overlay_apply(): FDT_ERR_BADMAGIC base fdt does did not have a /__symbols__ node make sure you've compiled with -@ 513 bytes read in 5 ms (99.6 KiB/s) Applying kernel provided DT overlay sun7i-a20-uart7.dtbo failed on fdt_overlay_apply(): FDT_ERR_BADMAGIC base fdt does did not have a /__symbols__ node make sure you've compiled with -@ 777 bytes read in 5 ms (151.4 KiB/s) Applying kernel provided DT overlay sun7i-a20-w1-gpio.dtbo failed on fdt_overlay_apply(): FDT_ERR_BADMAGIC base fdt does did not have a /__symbols__ node make sure you've compiled with -@ Error applying DT overlays, restoring original DT 42521 bytes read in 8 ms (5.1 MiB/s) ## Loading init Ramdisk from Legacy Image at 43300000 ... Image Name: uInitrd Image Type: ARM Linux RAMDisk Image (gzip compressed) Data Size: 10965837 Bytes = 10.5 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 43000000 Booting using the fdt blob at 0x43000000 EHCI failed to shut down host controller. Loading Ramdisk to 4958a000, end 49fff34d ... OK Loading Device Tree to 4957c000, end 49589618 ... OK

Same here... Have tried many option, including compiling my own armbian. Nothing really works. Except if I plug an USB Bluetooth dongle, that work fine after getting the right broadcom drivers in place. Here are the logs for the hci0 device (onboard bluetooth device): Short log: dmesg | grep toot [ 11.011248] Bluetooth: Core ver 2.22 [ 11.011395] Bluetooth: HCI device and connection manager initialized [ 11.011421] Bluetooth: HCI socket layer initialized [ 11.011434] Bluetooth: L2CAP socket layer initialized [ 11.011469] Bluetooth: SCO socket layer initialized [ 11.398268] Bluetooth: HCI UART driver ver 2.3 [ 11.398283] Bluetooth: HCI UART protocol H4 registered [ 11.398288] Bluetooth: HCI UART protocol BCSP registered [ 11.398392] Bluetooth: HCI UART protocol LL registered [ 11.398397] Bluetooth: HCI UART protocol ATH3K registered [ 11.398453] Bluetooth: HCI UART protocol Three-wire (H5) registered [ 11.398883] Bluetooth: HCI UART protocol Intel registered [ 11.399221] Bluetooth: HCI UART protocol Broadcom registered [ 11.399287] Bluetooth: HCI UART protocol QCA registered [ 11.399292] Bluetooth: HCI UART protocol AG6XX registered [ 11.399343] Bluetooth: HCI UART protocol Marvell registered [ 11.820070] Bluetooth: hci0: Frame reassembly failed (-84) [ 13.830695] Bluetooth: hci0: command 0xfc79 tx timeout [ 21.990700] Bluetooth: hci0: BCM: Read verbose config info failed (-110) [ 24.663143] Bluetooth: BNEP (Ethernet Emulation) ver 1.3 [ 24.663157] Bluetooth: BNEP filters: protocol multicast [ 24.663184] Bluetooth: BNEP socket layer initialized Complete logs here: http://ix.io/2rHa And some additional info from sunxi:

Im running the image of the orange pi 4 almost error-free on the 4b (to my server usecase requirements). Few relevant issues I observed so far: - On kernel 4.x the board looses Ethernet connectivity when on heavy load: The scenario in which I observed it, was while running Syncthing, syncing 500GB on LAN = high CPU utilization, high USB-3 IO count to hard drive on USB-C, and Ethernet at around 25Mb/s. Apart from that, the board was up for many days with no problem. - On kernel 5.x, Ethernet seemed stable (after running iperf3 and transferring 50Gb at ~950Mbps smoothly). However, USB-C does not recognize my hard-drive. Strangely, another block device is recognized and installed as sda, but fails to initialize. I'm pretty sure the NPU unit is not installed nor supported yet, given that even the oficial images from orange-pi are starting to support it. (did not do the Syncthing test yet since I do not have USB-3 working). I'm powering the 4B with the official 4A power supply over the jack connector. Assuming this is enough... Any tips on getting the USB-C (USB-3) working? Thanks in advance!

Fortunately, to this date, the image of the orange pi 4 works almost error-free on the 4b. Few relevant issues I observed so far: - On kernel 4.x the board looses Ethernet connectivity when on heavy load: The scenario in which I observed it, was while running Syncthing, syncing 500GB on LAN = high CPU utilization, high USB-3 IO count to hard drive on USB-C, and Ethernet at around 25Mb/s. Apart from that, the board was up for many days with no problem. - On kernel 5.x, Ethernet seemed stable (after running iperf3 and transferring 50Gb at ~950Mbps smoothly). However, USB-C does not recognize my hard-drive. Strangely, another block device is recognized and installed as sda, but fails to initialize. I'm pretty sure the NPU unit is not installed nor supported yet, given that even the oficial images from orange-pi are starting to support it. (did not do the Syncthing test yet since I do not have USB-3 working). I'm powering the 4B with the official 4A power supply over the jack connector. Assuming this is enough... @Igor, any tips on getting the USB-C to "see" my USB-3 drive? I could give it a try here. Thanks in advance!

True... As buggy as the previous.. development seems to be stagnant

Xunlong have released a new android image (v1.3) with Google Play working. Have anybody tested it? Any other improvement expected? Here is the link: https://mega.nz/#F!wbRFwYyA!a-xbNcCcBQl8UlvTdwNj-g!9TBmCJAL

Video drivers were added to the H6 GPU at Allinner's git repository: https://github.com/Allwinner-Homlet/H6-CedarC Is there any progress with Armbian for the H6 boards?

@tkaiser let us know if it works

To get the OrangePi image with the Pine H64 image, replace the whole boot_package.fex file from one to another. If you wanna hack the dtb files, then you have to unpack the .fex file into this 3 dtb files. The first 2 can not get converted from dtb to dts. The third one does seem to be the one we are interested.. Another important point is that, when I've tried to repack the fex file with dtb files mixed from one Orange to Pine, I got an unbootable image. So there is some dependencies among these 2 first dtb files and the main one. The first bytes seem to play a role on on getting the whole thing working, dont know which. Maybe it is simply because the main dtb file is referenced somewhere else by its byte position in the files. Maybe simply by changing the files size can mess it up (only guessing). @tkaiser follows the link to the dtb and dts files extracted from android image of the PineH64: https://mega.nz/#F!4MMQjbbC!gonZ69Vbx4rp3F5x9Y1Cig @Noah E. Koeppel I followed the steps from this post here on linux. If you cant get it right let my know.