usual user

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.

I doubt it. To expose a serial port, you probably used g_serial. No, devicetree configures only the USB OTG IP for device mode. As your serial port setup is working, your devicetree is already properly set up. Since it's been years since I was tinkering with the USB gadget framework, I looked at the kernel of balbes150's "Single Armbian image for RK + AML + AW" (the only one I had easily available). I learned that the legacy drivers are gone for good nowadays. There are only wraper modules to expose the legacy gadget configuration interfaces that use the gadget framework as backend. Unfortunately he is only building the wraper modules and left out the configfs components to configure the gadget framework via userspace. I don't know how your kernel is configured, so it may be different for you. As the same configuration parameters have to be determined for legacy and configfs configuration I prefer to use configfs. E.g. this shell script sets up a gadget with a printer interface, an ethernet interface and a storage device simultaneously: This can't be done with legacy, there you have only one function at a time and the configuration is applied at module load.

g_ethernet or g_midi is legacy USB gadget. You should use the USB gadget framework, it is much more flexible. It can run multiple functions simultaneously and be reconfigured at run time. To use the USB gadget framework it is usually not necessary to recreate the entire distribution. The only precondition is that the kernel build has created the required components. If your kernel provides /usr/lib/modules/*/kernel/drivers/usb/gadget/libcomposite.ko and /usr/lib/modules/*/kernel/drivers/usb/gadget/functions/*, you are ready to go. The only missing part is proper configuration. First you need a proper devicetree setup for the hardware support. (your prefered editor and DTC to compile the DTB). Second the USB gadget framework configuration (your prefered editor and your usual file system tools). I doubt that this will be the case, gadget features are much too different and there are probably no generic ones that suit someone's needs. At least vendor and device IDs have to be chosen properly.

If you don't know which chip your device is equipped with, you can climb the wrong tree. The driver you're tinkering with may not match your chip. Before you can start working on the software part of the chip, you have to learn way more about the hardware to select the proper configuration. And choosing the right driver is easiest, there is more difficult information to research, e.g. how the chip is wired up to the SOC. You need this for proper DT setup.

A devicetree is basically a standardized representation of the schematic of a board design. It provides parameters about the components used that drivers need to operate, or tell the kernel which driver to use in the first place. You can only recycle a DT if your device is a exact clone of an original device. Otherwise non matching components won't function properly. This is not the right way to proceed. This is as if you are using a disassembly of a binary program to rewrite the entire program. When compiling the original sources, information has been lost that cannot be reproduced during disassembly. The proper way is: You are the board designer with access to the reference documentation of all used components. You learn the syntax of DTS files. You write a board specific DTS with mainline binding documentation as reference. If your board design is based on e.g. a reference design from an SOC provider, you may be able to use his DTS as a template where you have only to adopt your modifications. When this is done, contribute it to mainline and it will work for all your customers out of the box. Of course, the kernel build must have enabled all required drivers. But I guess you are not in this situation So you have to do reverse engineering: Collect as many board details as possible. Learn the syntax of DTS files. Write a board specific DTS with mainline binding documentation as reference. You can use the original sources of meson-gxl-s905x-khadas-vim.dtb as a template and customize the differences (board model, compatible, Wi-Fi bindings, ...). Android DTs can only be used for hints, the bindings used are most likely proprietary and do not match those of the mainline kernel. Copying them over will not magically insert code into the kernel drivers to make use them. When this is done, contribute it to mainline and it will work for all. Armbian will probably pull it for early adoption if you provide a PR, as bringing it to mainline may take some time.

OK, this confirms at least the wifi devicetree configuration is not proper. I'm not even convinced that a real BCM4330 chip is installed on your board, possibly a compatible AP6330. But this can only be confirmed by optical inspection. I have extracted this from one of your posted log. If you are not using a Kadas board this is also evidence for improper devicetree configuration for your board. It asked for brcmfmac4330-sdio.khadas,vim.txt as calibration parameters in the first attempt, but should have asked for one for your specific board. The kernel has a framework to manage various calibration parameter files (*.txt) in parallel. It is derived from the devicetree. Through your previous efforts you know that the kernel supports your wifi chip, so "only" a correct devivetree configuration for your board is missing. The right solution for everyone without regressions for others is to create a proper device tree configuration for your board and not replace fallback firmware. With this the required firmware and the calibration parameters can stay alongside with the already existing ones and other users can keep using what already worked for them.

Either your device is not equipped with a BCM4430 (maybe AP6330) or you had not the proper calibration parameters (brcmfmac4330-sdio.txt) in place. And yes, they are different for each board and even the location (various regulatory restrictions) where you operate the wifi. Since you now have a calibration set that works for you, restore the current linux-firmware (brcmfmac4330-sdio.bin version 5.90.125.104 ) and report if wifi is still working. Depending on the result it can be decided what the proper fix wold be.

A RTC driver that is created as a module can be loaded late in the startup process and the user area has been running for some time. If you want the system time to be correct from the beginning, you want to set up the battery-powered RTC as early as possible. If the driver is build-in the rtc is available before userspace starts. If you have multiple rtc, the module initialization order is not guaranteed. It may change depending on hardware timing between boots. Having the battery-powered RTC driver as only build-in prevents this. Unfortunately, the mainline kernel does not have a framework to prioritize rtcs. If you can tolerate some time jumps during boot or possibly changing the rtc hardware, using modules only is a valid solution.

Devicetree is setup for BCM4330 so your kernel is pulling brcmfmac4330-sdio.bin, do you have a proper brcmfmac4330-sdio.txt in place? This is the current linux-firmware version, hence a proper one for BCM4330.

The BCM4330 mainline kernel driver is of fairly decent quality. Suitable firmware for the BCM4330 is provided by linux-firmware. Any board need a calibration set for perfect operation. In early days this resides in an EEPROM on the board. Nowadays it is in a file (saves hardware costs) such as brcmfmac43430-sdio.txt. The board designer should know the constrains to provide the perfect calibration parameters. If you don't have it, you can try to use a set of a very similar design, but you will never get the perfect performance.

The proper way to implement a bootsplash is to use the framework in the kernel as referenced here. Max Staudt promised in one of his last posts to implement his work as soon as a framework will be available but he never showed up again. The referenced example hack shows that the framework works, only someone needs to implement the bells and whistles.

You certainly want a two-way connection. But since I don't know what implementation requirements you have at either side of the connection you have to chose what ever fits your needs. A serial function can be enough if you implement the comunication yourself, or you can use a network function with a full network stack above it. The configuration principle from the point of view of USB gadget is the same in any case. You must fill configfs with the appropriate files. The details are described in the companion files in the directory I have already referenced. You can even configure multiple USB functions as long as your USB OTG hardware provides the required endpoints. E.g an Ethernet interface and a mass-storage to serve the suitable Windows Ethernet driver.