Jump to content

joaofl

Members
  • Posts

    62
  • Joined

  • Last visited

Posts posted by joaofl

  1. On 4/30/2021 at 6:39 PM, jstefanop said:

     

     stock kernel works, issue is with orange pi 4 has badly designed FPC connector for PCIE lanes. They didn't group the diff pairs so transmission over FPC cable sucks. We had to make a flex ribbon board to correct this and route as diff pairs so Gen 2 2x works great. Might make some extra and release the board if there is enough interest. 

    IMG_9477.jpg

     

    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?

  2. 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.

  3. 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.

  4. 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.

     

  5. 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)
    

     

  6. 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

     

  7. 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:

    Quote

     

    AMPAK

    From Linux 5.2, there's nice clean upstream support for broadcom bluetooth. See http://lists.infradead.org/pipermail/linux-arm-kernel/2018-November/610954.html for the full details. If you're adding bluetooth nodes to existing hardware, the quick traps are:

    missing the clocks/clock-names nodes on the wifi_pwrseq node.

    thinking that the "bt-reset-n" signal should be flagged as active low.

    Remember, you need kernel config option CONFIG_SERIAL_DEV_BUS to be able to select CONFIG_BT_HCIUART_BCM If you have these wrong, your kernel will keep reporting lines like ```Bluetooth: hci0: command 0x0c03 tx timeout``` 0x0c03 is the standard HCI request to reset the part, so this means your device is not (yet) responsive. Once this is all correct, your next trap will be finding suitable firmware, and getting it named correctly, though fortunately at this point, the kernel will simply tell you. linux-firmware repo has very few of the bluetooth files, your best bet is armbian's repo, though they will all need renaming, because armbian patched all that too.

     

     

  8. 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!

  9. 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!

  10. On 4/15/2018 at 9:03 AM, Maurice Vroegop said:

     

    Will test it later this day.

     

    It looks and feels the same as the v.12 rom except it has GAPPS installed.

     

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

  11.  

    On 3/19/2018 at 8:41 PM, tkaiser said:

    'Then to repack them simply type cat *.dtb > boot_package.fex'

     

    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.

     

  12. Compiled and tested, but it seems more buggy than the image they provide. Haven't tested much, but Ive noticed for example that it doesnt go Idle. Should test a bit more, but it seems that they dont include their tunning on the image they distribute.

  13. 7 minutes ago, Noah E. Koeppel said:

    before you make you have to 

    I missed that :wacko:

     

    Now its compiling... Lets see how it goes... Ill test the output image as well to check if there is any improvement compared to the previous one.

  14. 14 minutes ago, Noah E. Koeppel said:

    yes, run from the android root directory

    
    $ source build/envsetup.sh
    or
    $ . build/envsetup.sh

    and lunch should work

     

    That worked. But now when I type make -j 6 (which I guess is missing in your tutorial), I get another error:
     

    ninja: Entering directory `.'
    ninja: error: 'device/softwinner/petrel-p1/kernel', needed by 'out/target/product/petrel-p1/kernel', missing and no known rule to make it
    build/core/ninja.mk:148: recipe for target 'ninja_wrapper' failed
    make: *** [ninja_wrapper] Error 1

     

    But notice that I'm trying to compile the PineH64 android.

     

    I've tried with all options from 22 to 26 (the petrel ones).

  15. 16 hours ago, Noah E. Koeppel said:

    lunch

     this command requires python-lunch to work, but still, after typing it it gives the error:

     

    No such file: /home/joao/.lunchrc

     

    Should I compile from an specific absolute directory? Wont make do the job?

  16. There is another tip I found on the PineH6 forums to get GooglePlay working on it.

     

    Consists of replacing /system/priv-app/GmsCore with the /system/priv-app/PrebuiltGmsCore from the Zidoo OTA. After that play services is said to work fine.

  17. But then in the end there is only one dtb file inside /lichee/out/sun50iw6p1/android/common/sunxi.dtb

    On that folder there are hundreds of dts files, for different platforms, chips and boards. Its somehow related to the compiling options you provide "sun50iw6p1" but not sure how..

     

    But we can always do the dirty job of simply replacing the the dtb file before compiling android

  18. @tkaiser

     

    I'm looking at PineH64 kernel DTS files, and there are lots of them. More specifically to the h6 chip, there seems to have these ones:

     

    joao@machina ~/Repositorios/pineh64/lichee $ find -name sun50iw6*.dts
    ./linux-3.10/arch/arm64/boot/dts/sun50iw6p1-soc.dts
    ./linux-3.10/arch/arm64/boot/dts/sun50iw6p1-pro_v1_0.dts
    ./linux-3.10/arch/arm64/boot/dts/sun50iw6p1-perf1_v1_0.dts
    ./linux-3.10/arch/arm64/boot/dts/sun50iw6p1-petrel-p1.dts
    ./linux-3.10/arch/arm64/boot/dts/sun50iw6p1-qc.dts
    ./linux-3.10/arch/arm64/boot/dts/sun50iw6p1-perf2_v1_0.dts
    ./linux-3.10/arch/arm64/boot/dts/sun50iw6p1-fpga.dts

     Do you have any idea where this files are referenced from? Where in the kernel source can we chose which dts to be converted into dtb, and loaded to boot? And also, how to figure out which one is being loaded?

    That would be the first step to make PineH64 image also compatible with the OPi

     

    @Noah E. Koeppel

     

    So far the its working. The kernel have compiled successfully. Lets see the rest. Maybe its part of the android-sdk package...

×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines