usual user

Members
  • Content Count

    51
  • Joined

  • Last visited


Reputation Activity

  1. Like
    usual user reacted to SteeMan in X96 Air (4/32 Go) and Wireless driver for RTL8822cs   
    I don't see anything in the links you have provided that this would be a solution to your problem.  Are you sure that you have the that chip on your board?  (i.e. have you opened the case and inspected?).  In order to get things working, you need to have your dtb, driver and hardware all in sync.  The dtb is the mapping between the hardware and the kernel, I would expect that this is the real source of your problems that your dtb is referencing different hardware than what you have installed on your board.  The problem with armbian for android tv boxes is that while there are only a few different reference dtbs available, but there are hundreds of different boards with different components from all the manufacturers.  So most of the boards will not work in some way because of the mismatch between their hardware and the dtbs that are available (sometimes you get lucky and everything you need works, but rarely does everything work).  As I have said in other threads, no one should approach armbian for these tv boxes expecting that everything will work (especially wifi and bluetooth - none of my boxes have working wifi or bluetooth) because that is not a reasonable expectation, unless the board manufacturer is supporting their boards by getting code into the mainline kernel.
     
    Having said all of that, it wouldn't hurt to try what you reference in the links above, and I suspect it is likely that the 5.6.1 based code would still work on a 5.7 kernel.
     
    You should also consider the long term support issues even if you do finally get something working.  You will likely find yourself in the position that at some future point in time when a new kernel update with important security fixes gets pushed out that it is no longer compatible with your custom built driver and then you will need to choose between security of your system or breaking your wifi support.  If you need wifi, I would recommend getting a cheap usb wifi adapter that has mainline kernel support as over the long run that will be best.
     
    However if your goal in all of this is to get your solution into future armbian builds (which really means getting it into mainline kernel) then keep hacking away.  But I would suspect that because you have already found a git repository that contains driver code that isn't in the mainline kernel (I am assuming this, but haven't verified), that that path has already been tried by others and rejected (lack of support of the code, poor code quality, or any number of other reasons).
  2. Like
    usual user got a reaction from SteeMan in Single Armbian image for RK + AML + AW (aarch64 ARMv8)   
    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.
  3. Like
    usual user got a reaction from gounthar in Orange Pi RK3399 status LEDs   
    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.
  4. Like
    usual user got a reaction from Tido in Problem configuring CUPS   
    OK, now that you described your network topology in more detail it is obvious what is going on.
    Your router does not connect the WiFi and Ethernet segment in bridged mode but handles them as two separate segments where routing takes place and firewall rules get applied. Ports for service discovery (mdns) and LPR (printer) seem to be enabled already but for ipp-everywere or aiprint (ipp) are not.
    With all properly setup and cups-browsed from the cups-filters package running there should be no user intervention be required to add the printer. cups-browsed will discover it, setup a suitable queue and in applications it will show up as printer to use.
  5. Like
    usual user got a reaction from gounthar in SoCs for multiple streams transcoding   
    If I looked this up correctly from the i.MX 6Solo/6DualLite Applications Processor Reference Manual the VPU has this specs:
    HW Decoder: H.264 Profile: BP/CBP/MP/HP Resolution: 1080 i/p, 30 fps Bitrate: 50 Mbps
    HW Encoder: H.264 Profile: BP/CBP       Resolution: 1080p, 30 fps    Bitrate: 14 Mbps
    As the VPU is a dedicated IP the number of CPU cores does not matter for the codec performance and 1gb should suffice to provide the required buffer allocations for the intermediate frames.
     
    Just composed my first transcode pipeline, see transcode-pipeline.pdf for reference. I do not really know what I am doing (google was my friend) and there are so much knobs for configuration and fine tuning so YMMV.
    transcode-pipeline.pdf
  6. Like
    usual user got a reaction from gounthar in SoCs for multiple streams transcoding   
    On imx6q SoC there is:
    v4l2-ctl --device=/dev/video0 --all
     v4l2-ctl --device=/dev/video1 --all
    v4l2-ctl --device=/dev/video10 --all
    /dev/video10 requires at least kernel 5.4.0-rc1 to work out of the box.
                      
    gst-inspect-1.0 exposes:
    So hardware accelerated video pipelines can be composed in all flavors.