usual user

Members
  • Content Count

    55
  • Joined

  • Last visited

About usual user

  • Rank
    Advanced Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. You have proper hardware acceleration from the kernel already. What you are probably missing is the xorg driver to make use of it.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. 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.
  14. 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.
  15. 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.