usual user

  • Posts

    196
  • Joined

  • Last visited

Reputation Activity

  1. Like
    usual user got a reaction from TRS-80 in Setting CMA in armbian   
    https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/admin-guide/kernel-parameters.txt
  2. Like
    usual user reacted to jock in CSC Armbian for RK322X TV Boxes   
    This demonstrates that you know very little about Armbian. Official support is granted for boards which have official specs and whose manufacturers provide datasheets. Hopefully those manufacturers also provide fundings, sponsorship or any kind of support. There is no reverse engineering with officially supported boards: manufacturers provide specs, in form of openly available electrical diagrams and general documentation.
     
    Tv boxes don't provide any datasheet about board specs, often chinese manufacturers even provide fake specs to buyers to sell their crap. They definitely does not sponsor the project in any form, thus Armbian does not endorse any tv box, nor do I: you need something for a serious project? Buy serious hardware, not chinese cheap and unsupported crap.
     
    If you think Armbian purpose is to tell you how to understand boards and their chips, understand datasheets, write proper device trees, configure and compile the linux kernel, and whatever it requires to properly support a board, you're out of context.
    I spent time doing all of these things above, so everyone else can do that. If you don't have enough skills to do that, that's not a fault of the project. You can still build up those skills, if you have enough time and will to sacrifice for the purpose.
     
    There is a donation and help providing page, not just money, but whatever people can do is appreciated, even writing documentation.
    Plus the community does not need to be funded with money, it is funded by will of people who wants to do something useful for others.
     
    Armbian is not a company that does things on people request and I don't think you can "hire" someone from inside the project for your particular needs.
    But again I repeat: you can still contact and pay developers - ANY developer, not necessarily an Armbian developer - for your needs.
  3. Like
    usual user reacted to jock in CSC Armbian for RK322X TV Boxes   
    Sorry but I have to be sincere about this: I don't like the reasoning, I found it unethical.
     
    Believe it or not, I don't receive any kind of money from anyone; Armbian team also does not receive anything from these no-name boards, instead has to pay electricity, bandwidth to host images and forums.
    It is just courtesy of Armbian guys if all of this is possible, they ask nothing in charge; although Armbian does not officially support any TV Box - as clearly and boldly stated in the first posts of all my threads.
     
    My role in all of this is just driven by passion and learning, not money. I decided to share my work and studies with others because I think that if other people does the same, the world will become a better and funnier place.
    As you see, the learning curve is pretty steep, and trying to build an out-of-the-box working solution for boards whose specifications and datasheets are kept secret is a huge time wasting job.
    What I expect in change is usually a "Thank you": most of the time it suffices.
     
    Here I read, and I really hope I misunderstood the post, that someone is going to make business around this.
    That's pretty ok to me: I do support tv boxes for passion. I also use Linux which is free and made by others for passion and work and I pay nothing to anyone; nonetheless I contribute to opensource the way I can.
     
    Now if your concern is missed support, don't ask community what can do for you and point out what community is not doing for your business; start thinking about what you can do for community that helps both community and your business.
    In all of this long thread I don't know how many people donated to Armbian project - I'm not part of the official team.
    But I'm totally sure that, except for the very generous board donations from @fabiobassa to whom all people here should as well be very grateful, I never ever received a penny or one board from anyone. And note that I don't ask boards as gratification - I already have several of them taking dust - but to study them. Nonetheless I am still here available for free support and for fun.
     
    Asking me, or anyone else, to spend money to buy cheap crap and spend time reverse engineering that crap for your business is just unethical. It's parasitizing.
    You need good Linux support for your tv boxes? Ask the manufacturers of those boxes, and see what they answer to you.
    The problem about the "right price" is that the price can't be right if you don't include software developing and maintaining costs. Chinese tv boxes manufacturers are fetching "just working" Android distro into their products. If they would want to support a full linux environment, the price would be three or four times the actual price.
     
    Want to talk about business?
    Send a precise request to the developer of your choice (me included) and wait for a proper price quotation.
     
    Want to do everything by yourself? You can.
    Armbian developers spent hours to write proper documentation, available on docs.armbian.com. Source code is publicly available on github repository.
    If you find it difficult navigate into, spend hundreds of hours lo learn things, as me and several others did, to raise your skills to keep up with your business.
  4. Like
    usual user got a reaction from pista in Trying to learn more about u-boot for amlogic devices.   
    https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/admin-guide/kernel-parameters.txt
     
    https://source.denx.de/u-boot/u-boot/-/blob/master/doc/README.distro
  5. Like
    usual user got a reaction from RetroFan90 in CSC Armbian for RK3318/RK3328 TV box boards   
    I don't know what requirements Kivy places on the graphics stack, but since Panfrost achieves OpenGL ES 3.1 conformance on Mali-G52, it certainly makes sense to read this to understand what to expect from a lima-driven GPU. I still remember very well times when my GPU only reached almost 2.0 and the performance was quite moderate. With now 3.1 it's a big difference for daily desktop use, although my GPU isn't yet declared fully compliant. But since this is bleeding edge development, at least the current mesa mainline release is required in any case. If not even the main branch to use just implemented extentions. Kernel driver wise everything necessary should already be available and therefor mesa is where you are looking for GPU support improvements.
  6. Like
    usual user got a reaction from fabiobassa in CSC Armbian for RK3318/RK3328 TV box boards   
    Then why not start, @jock has announced new versions and the links on the first page are already up?
  7. Like
    usual user got a reaction from fabiobassa in CSC Armbian for RK3318/RK3328 TV box boards   
    Then why not start, @jock has announced new versions and the links on the first page are already up?
  8. Like
    usual user got a reaction from RetroFan90 in CSC Armbian for RK3318/RK3328 TV box boards   
    I don't know what requirements Kivy places on the graphics stack, but since Panfrost achieves OpenGL ES 3.1 conformance on Mali-G52, it certainly makes sense to read this to understand what to expect from a lima-driven GPU. I still remember very well times when my GPU only reached almost 2.0 and the performance was quite moderate. With now 3.1 it's a big difference for daily desktop use, although my GPU isn't yet declared fully compliant. But since this is bleeding edge development, at least the current mesa mainline release is required in any case. If not even the main branch to use just implemented extentions. Kernel driver wise everything necessary should already be available and therefor mesa is where you are looking for GPU support improvements.
  9. Like
    usual user got a reaction from gounthar in Mainline VPU   
    A few days ago I also tried to build a ffmpeg with v4l2-request-hwaccel. Because my distribution already uses 4.4, I used these patches. Initially, I got similar error messages as @kprasadvnsi, but the 5.14 kernel header hint was the missing link. I also have a flawlessly compiled ffmpeg package now, but I also don't know if additional patches are needed for other mainline components or how to check the v4l2-request-hwaccel functionality.
  10. Like
    usual user reacted to JMCC in Testing Fedora on ARM   
    Moved from the RK3399 multimedia integration thread to here, since the post is not related to the MM integration, and not even to Armbian.
  11. Like
    usual user reacted to RussianNeuroMancer in USB C to display   
    Pull request mention HDMI specifically:https://github.com/armbian/build/pull/2302 
     
    Although I not sure about what DWC3 driver limitation he is talking about. (HDMI+hub combo working fine for me on ROCKPro64 with legacy kernel.)
  12. Like
    usual user got a reaction from TRS-80 in Tried upgrading from slightly older (4.19.62) kernel on Cubietruck, now won't boot   
    You referenced the raw device by "/dev/mmcblk1" where MBR , u-boot and partitions reside.
    You need to reference a partition by "/dev/mmcblk1pX" where a suitable filesystem resides.
    Replace "X" with the number of the partition you want to check.
  13. Like
    usual user got a reaction from soerenderfor in How to control FAN on Rockpro64?   
    ftdoverlay is a convenient way to apply an overlay staticly to a base dtb. You spare the DTC decompile - manually edit - DTC compile dance. Usually you write overlays with label refernces, but to be able to apply such an overlay, the base dtb has to be compiled with the @-option. This has significant impact on the size and distributions usually don't do this. When you write the overlay with full paths, it contains all the information to be applied to a base dtb that was not created with the @-option. The mainline ftdoverlay need the patch to be able to apply it.
     
    Edit the pwms property to any value you like as shown in the provided rk3399-rockpro64-tz.dts (50000 default changed to 10000).
  14. Like
    usual user got a reaction from nokirunner in CSC Armbian for RK322X TV Boxes   
    Out of curiosity I built the armsoc driver for my rk3399. I can confirm your observation of the faster display output. Of course, there is no 3D acceleration because the driver has no way to delegate 3D requests to the 3D render node. The armada driver (you want the unstable-devel branch) I use for my imx6 has such an ability and surpasses the rk3399 with modesetting despite the lower specification for now.
    IMHO armsoc is a dead end until it gets a similar ability. And using glamor with its unnecessary scanout indirection via 3d is also a bad idea. We are all in the same boot, no xorg driver to glue all IPs in an efficient manner together available.
    xorg-rockchip-modesetting.logxorg-rockchip-armsoc.logxorg-imx-armada.log
  15. Like
    usual user got a reaction from gounthar in Orange Pi Zero PA19 goes HIGH when reading input   
    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.
  16. Like
    usual user got a reaction from lgranie in Single Armbian image for RK + AML + AW (aarch64 ARMv8)   
    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.
  17. Like
    usual user got a reaction from gounthar in USB gadget as a video sink   
    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.
  18. 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).
  19. 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.
  20. 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.
  21. 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.
  22. 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
  23. 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.