usual user

You followed the link in the first post about tmon and looked around the directory where the README is located?

The tool is part of the kernel source tree. I don't know how it's packed in your environment but following the README it can be built very easily in the appropriate directory. If not packed for Armbian perhaps a good opportunity to contribute by PR to Armbian.

Use "tmon -dl".

Error prone HW design with floating IO. Proper design with fixed IO states: VCC --------> Pullup Resistor ---| GND --------> Push Button -------+------> PA19 The pullup is already in place. Pressing the button will flip the IO from 1 to 0.

According to your log, which I quoted in my previous post, it was not. Hence my request for the version verify. The wifi kernel driver loads any code that is in the outlined location, and as long as you have not "ln --symbolic /lib/firmware/ap6210/fw_bcm40181a2.bin /lib/firmware/brcm/brcmfmac43362-sdio.bin" and "ln --symbolic /lib/firmware/ap6210/nvram.txt /lib/firmware/brcm/brcmfmac43362-sdio.cubietech,cubietruck.txt" in place, it won't use the desired ones. You can also copy over the code, but I prefer the symlink method if I have to differ from the mainline linux-firmware code. If a mainline linux-firmware update breaks in an incompatible way, I only lose the symlinks and recreating them again restores the functionality. Since these are firmwares for USB host interface attached chips, we are dealing with the UART host interface.

Because "strings ap6210/fw_bcm40181a2.bin | grep 43362" gives me "43362a2-roml/sdio-g-pno-pktfilter-keepalive-wapi-wme-p2p-*unknown* Version: 5.90.195.0 CRC: b99a439d Date: Mon 2014-03-10 15:00:57 CST", I wonder if you have another one or do not use it. The kernel driver is expecting it as /lib/firmware/brcm/brcmfmac43362-sdio.bin for loading. And its companion nvram as brcmfmac43362-sdio.cubietech,cubietruck.txt. If not available it will fall back to brcmfmac43362-sdio.txt. Wifi and bluetooth have to cooperate because they share at least the same antenna in your design. Where user space tools expect and name their resources is a completely different story.

The dtb change was to test if there was some issue with the shutdown gpio. Without that it is relying on the power on reset, i.e. a non working warm boot is expected. It looks like as soon as the BT firmware got loaded, the BT chip stops working. My research has shown that the files in ap6210/ are the ones that were also used with the old user space load method. Therefore, they should be right and work. Maybe it is worth to revert back to the old method and try if this still works. To do this, remove the entire bluetooth {...}; node from the dtb. This way the kernel driver will no longer touch bluetooth and the old method (brcm_patchram_plus, hciattach, ...) should be usable again. What me puzzles is with which hardware we are here really dealing. The referenced cubietruck documentation claims it has an AP6210 with a BCM20710. But the initial firmware announces it as BCM20702A and despite the name ap6210/bcm20710a1.hcd, it contains this string: "BCM20702A1 Generic UART Class 1 @ 26 MHz".

Studying the provided logs gives some clues. After a fresh install I guess there are /lib/firmware/brcm/brcmfmac43362-sdio.bin and /lib/firmware/brcm/brcmfmac43362-sdio.bin.txt in place. With this, the wifi driver get loaded and with no /lib/firmware/brcm/BCM20702A1.hcd no BT firmware upload does take place. The embedded BT firmware in brcmfmac43362-sdio.bin get used and the BT host interface via uart is working. Because the embedded firmware most probably does not match the BT hardware it has to be updated by BCM20702A1.hcd for proper operation. So we are back to find out why this is failing. The only relevant binding in the DT is this line: shutdown-gpios = <&pio 7 18 GPIO_ACTIVE_HIGH>; /* PH18 */ For a test let us remove it from the dtb. Copy the original sun7i-a20-cubietruck.dtb to sun7i-a20-cubietruck.dtb.orig at your workbench. Disassemble the dtb (dtc -I dtb sun7i-a20-cubietruck.dtb.orig > sun7i-a20-cubietruck.dts). Use your preferred text editor to remove the "shutdown-gpios = ..." line at the bluetooth node in the sun7i-a20-cubietruck.dts. Compile the dtb again (dtc -I dts sun7i-a20-cubietruck.dts > sun7i-a20-cubietruck.dts) Now replace sun7i-a20-cubietruck.dtb at the boot location with this one and reboot. This should now be able to upload BCM20702A1.hcd and make BT working to some extent. Since there is no longer any way to reset the BT, this only works after a power cycle, a warm reboot fails. Can you also try the wifi firmware in /lib/firmware/ap6210/ as described above? Because the version has a newer time stamp (date: Mon 2014-03-10 15:00:57 CST) than the firmware you are using. Now that I know the board specific nvram name I just discovered linux-firmware is already carrying a brcmfmac43362-sdio.cubietech,cubietruck.txt. It is identical to the nvram_ap6210.txt except the "macaddr=" parameter. But also the brcmfmac43362-sdio.bin has a newer time stamp (Date: Wed 2018-05-16 23:44:07 CDT). Maybe this one is worth a try also.

Just out of curiosity I took a look at the ap6210 directory on my NanoPC-T4 image: ap6210/bcm20710a1.hcd ap6210/bd_addr.txt ap6210/fw_bcm40181a2_apsta.bin ap6210/fw_bcm40181a2.bin ap6210/fw_bcm40181a2_p2p.bin ap6210/nvram_ap6210.txt ap6210/nvram_apxxxx.txt ap6210/nvram.txt I see they are not only carrying the bluetooth firmware but also wifi firmware and its companion nvram. I don't know where your used ones are origination from but to rule out this special versions are required, let's put them in place. Temporarily rename /lib/firmware/brcm/brcmfmac43362-sdio.bin and create a symlink (ln --symbolic /lib/firmware/ap6210/fw_bcm40181a2.bin /lib/firmware/brcm/brcmfmac43362-sdio.bin). I don't know if you're using only the generic name (brcmfmac43362-sdio.bin.txt) for nvram. If so, let's do it the proper way. 1. Temporarily rename /lib/firmware/brcm/brcmfmac43362-sdio.bin.txt 2. Reboot and check dmesg for which <nvram>.txt is being searched. First attempt will try a board specific one, second attempt will try brcmfmac43362-sdio.bin.txt. We are interested in the name of the board specific one. Copy over ap6210/nvram.txt to /lib/firmware/brcm/brcmfmac4356-sdio.<specific name>.txt With board specific name at least one <nvram>.txt for each board can coexist in the searched directory. And yes, in theory, every board needs a specific one. Falling back to the generic can work, but can break as soon as the generic one changes. One doesn't fit them all. Now reboot and check if this has changed anything regarding Bluetooth.

I agree with your analysis, something goes wrong with the hci initialization. What worries me are these lines: Since the driver already works in many other situations, my suspicion is again focused on the board-specific configuration. Just to rule this out, there are no more user space services (with brcm_patchram_plus, hciattach, ...) that might conflict (e.g do some reset) with kernel-mode hci initialization? They are no longer needed with the new mode. Because the user space tools did not rely on the bluetooth DT node (they did there own thing) maybe there is still something not set up properly. Oh, one more idea, can you boot without any overlays. To rule out they make bluetooth non working by pull conflicting configuration. With "strings bcm20710a1.hcd | grep BCM" you can check which version string to expect.

The firmware is probably for your device. If it is wrong for you, it may be missing a feature that you expect. Anyway, the basic functionality should be present so bluetooth starts working. Because the wifi and the bluetooth component share some hardware resources on the module both kernel drivers have to be loaded properly. User space does not need to use the WiFi component, but the WiFi kernel driver must be ready to let Bluetooth work. The Wifi component is attached via sdio and the driver will request the firmware and the nvram like the bluetooth driver. Look at the output of "dmesg" after boot up to see if something is missing.

This post uses the outdated method of uploading the firmware via an user space tool. To have access to the bluetooth device it needs /dev/ttyS# for the communication. Further the firmware file name is given as a parameter so you can throw in any arbitrary name. The new method of uploading the firmware via the kernel driver has no way to use an arbitrary name. Because the driver is used for several BCM chips it can only use some generic name (brcm/BCM20702A1.hcd). Since the previously used bcm20710a1.hcd was apparently the right one, a symbolic link (ln --symbolic /lib/firmware/ap6210/bcm20710a1.hcd /lib/firmware/brcm/BCM20702A1.hcd) would be sufficient to continue using it. Having no /dev/ttyS# is ok, the kernel driver is now dealing with the uart2 and making it accessible to the user via /dev/ttyS# can even be dangerous as it can affect driver operation.

All permanently equipped components on a device should be represented in the base dtb. Overlays are for optional components. Think of something connected via gpio-connector or a camara module via csi-connector. Because the configuration may clash or if an option is not applied, it is not desirable to have them in the base dtb. So if no addons are used the base dtb should suffice. If you are interested in mainline, https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree should suffice. And don't look too closely, it already has the Bluetooth node since a while I see no vbat-supply and vddio-supply bindings in there. But I don't know if they are required for your device. I see this: in the logs. It may be normal but the real regulators may be not enabled by power management (no consumers). Maybe adding the bindings is the missing part, but I don't really know.

Because the driver searches for the Bluetooth node, simply check that your device tree has such a node. This is the one of my device: &uart0 { pinctrl-names = "default"; pinctrl-0 = <&uart0_xfer &uart0_rts &uart0_cts>; status = "okay"; bluetooth { compatible = "brcm,bcm43438-bt"; clocks = <&rk808 1>; clock-names = "lpo"; device-wakeup-gpios = <&gpio2 RK_PD2 GPIO_ACTIVE_HIGH>; host-wakeup-gpios = <&gpio0 RK_PA4 GPIO_ACTIVE_HIGH>; shutdown-gpios = <&gpio0 RK_PB1 GPIO_ACTIVE_HIGH>; max-speed = <4000000>; pinctrl-names = "default"; pinctrl-0 = <&bt_reg_on_h &bt_host_wake_l &bt_wake_l>; vbat-supply = <&vcc3v3_sys>; vddio-supply = <&vcc_1v8>; }; }; It showcase only what you are looking for. Because I have a completely different board and different BCM chip the values don't match for your board. Even the required bindings may vary (see the already referenced binding doc). But it will use the same driver in the end. The only task of uboot is to initialize the system so that the boot device can be accessed. Then it loads the kernel and its companion data (dtb, initramfs, ...) and transfers control to the kernel. Since this already works, you don't have to worry about it. By the way, mainline uboot is using the same DT files while its build as the kernel uses, but requires only few DT nodes for its operation. And bluetooth isn't one of it, uboot has no business in bluetooth

Device tree is describing the hardware design of a device that can't be auto detected. You probably missing a proper bluetooth DT node. It will tell the kernel which driver to load and the driver will know how the chip is wired and which firmware to load to operate the device. This is used to use the same driver for a particular chip, regardless of how it is wired and what possible configuration parameters it needs. Figuring the proper values for your specific board is the hard part if no DT node is already provided. But once it's done, it won't change unless you change your hardware design.

For my NanoPC-T4, I want to be able to install multiple kernel versions at the same time and boot a specific one by default. In addition, I would like to be able to select which kernel to start if necessary: Armbian_20.07_Arm-64_focal_dev Boot Options. 1: linux-default 2: 5.8.0-rc4-arm-64 3: 5.8.0-rc3-arm-64 4: 5.8.0-rc2-arm-64 5: 5.8.0-rc1-arm-64 6: linux-test To present my solution, I have used "Armbian_20.07_Arm-64_focal_dev_5.8.0-rc4.img.xz" and "u-boot-rk3399-nanopc-t4.img 07/10/2020 8:50am" on a microSD: With this scheme in place I am able to pull in a new kernel without the need to port over my local image configuration to a new image. If the new kernel is not working as expected all previous available ones are just a reboot away. If the new kernel version is suitable for boot on demand just a new boot stanza in extlinux.conf is nessesary. The mainline uboot for NanoPC-T4 has not yet enabled USB keyboard support. Therefor the on demand selection of a boot option will only work via the serial console keyboard. The build of uboot with the same options in nanopc-t4-rk3399_defconfig as it was done for Pinebook Pro and rockpro64, should probably enable it in a similar way. This means that only HDMI display and USB keyboard are required.

Perhaps checking the output of "dmesg" that was recorded on both devices after a fresh reboot can gain more insight. As you said you had copied everything in /boot, you also copied the kernel companion dtb files, did you?

Just a shot into the dark. When you copied the kernel binary, you also copied its companion modules from /usr/lib/modules/<kernel-version> to your rootfs? Perhaps the initrd lacks an essential module that is later loaded from rootfs. You must use the same <kernel-version>directory label in your rootfs.

Verify the full verbose boot log of both devices. Best obtained by serial console as it will most probably also preserve the uboot messages.

You have proper hardware acceleration from the kernel already. What you are probably missing is the xorg driver to make use of it.

For these modules to work, at least the correct Devicetree configuration must be available. This way they know how to operate the tx led and how it is wired up.

If I picked it out correctly, the USB IP of your h5 SOC will be driven by the musb driver. So check if your kernel config has all components for OTG support enabled and the DT is configured for peripheral mode. This is usually not the case with a default configuration because host mode is used more frequently.

USB Gadget is a device-independent kernel subsystem. For its operation it needs device specific UDC (USB Device Controller) support. E.g.: You at least missing proper hardware (DT) configuration and may be missing kernel UDC support.

An USB video sink is a standard USB host port consuming the video via UVC function. I.e. you plug in a USB webcam in your USB port and you get a /dev/videoX device. This will not work quite well due to the bandwidth requirement for the raw video. Using native Ethernet would already be a challenge. The proper way is to use hardware encoders at the host and forward the processed stream. With zero copy (dma_buf) video pipeline this puts little strain on the CPU.

As you have chosen the legacy g_midi configuration interface, you have to do configuration while module-load. "modinfo g_midi" will tell all available configurable parameters.