usual user

  • Posts

  • Joined

  • Last visited

Everything posted by usual user

  1. Verify the full verbose boot log of both devices. Best obtained by serial console as it will most probably also preserve the uboot messages.
  2. You have proper hardware acceleration from the kernel already. What you are probably missing is the xorg driver to make use of it.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. 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 ) and report if wifi is still working. Depending on the result it can be decided what the proper fix wold be.
  14. 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.
  15. 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.
  16. 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.
  17. 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.
  18. 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.
  19. The Nanopi Neo Air seems to support an OTG USB port. So you are looking for the USB gadget framework. Because you are too inaccurate which peripheral protocol you want to use, you may start here.
  20. U-boot and its components usually reside in the not allocated space of the partition table between MBR and the 1th partition. What tool you use to put it in the proper location does not really matter. I prefer to learn what the specific parameters of the desired device are and use dd. It always works the same way and I don't have to rely on tools where I don't know what they're really doing. But perhaps someone who knows Armbian better can tell you what is the preferred way in your environment.
  21. You don't say anything about the used u-boot and its configuration. U-boot performs the basic system initialization, so a different u-boot setup can lead to such behavior. The Kernel initialization is based on the initial u-boot setup.
  22. If I interpret the schematics correctly, all LEDs are hardwired to power rails or SATA controller. So there is no way to change the functionality via software. The only way to get your desired functionality is to add an additional LED via GPIO pin and apply proper DT configuration.
  23. As you are rebuilding the kernel anyway, set the DS1307 option to "build in" (y) and the onboard RTC option to "module" (m). This way the DS1307 gets initialized as early as possible (rtc0) and the onbord RTC is still available as rtc1 if the module is loaded. No further modification for rootfs is required.
  24. Oh, this reminds me uboot has a support problem with keyboard on the OTG USB port. Try the other one, should be the lower one. The timeout is in 1/10sec, i.e. timeout 100 == 10 seconds. It is not really good news. It confirms my initial suspicion that the boot.scr magic is the culprit. Looking in the boot.src shows even a hard coded quadcore DTB name without counterpart for Solo/DualLite. I don't have much interest at legacy boot.scr, so I've reached a point where I can't help much anymore. The armbian boot.scr maintainer has now to jump in to find out how to fix this. If this doesn't happen, you are already an advanced distro-boot user and can keep using it. At least we have narrowed down what has to be fixed.
  25. OK, this confirms the boot.src magic is really not working. To rule out my kernel command line modification did the trick, fire up your favorite editor and modify the parameters in extlinux.conf. Or alternatively replace your extlinux.conf by the attached one. There I added a second boot stanza that boots with the same kernel command line parameters as boot.scr. Additionally in the first stanza I have reset the kernel loglevel like the one it is used by boot.scr. This will present the black screen a little longer as no kernel logging will be presented but the boot time should stay the same. No one wants log output cause it could help identifying issues . Last but not least I increased the "Enter choice:"-timeout to give you some more time for your reaction. After the timeout the first stanza is chosen automatically. Boot the image and at the "Enter choice:"-prompt type the "2" and "ENTER" keys to select the boot stanza with the boot.src kernel command-line parameters. If this boots for you then the influence of kernel command line parameters can be excluded. If the boot.scr method had worked, the boot behavior would have been the exact same as with distro-boot now. It is due to the boot scheme that armbian uses. Generic Fedora uses a similar one, you can see it if you choose the second boot stanza when booting. But you need to be fast because the "Enter Choice:" timeout is only two seconds there. For a little more background start reading here. This is because the existence of /boot/extlinux/extlinux.conf changes the boot method to distro-boot and boot.scr is no longer taken into account. For distro-boot only the kernel, the DTB and an optional initramfs is required. Only your Preferred Editor is required for administration, as extlinux.conf is just a plain text file. No tinkering with special uboot tools. This isn't a workaround it is simply a different boot method with uboot. extlinux.conf