Jump to content

usual user

Members
  • Posts

    468
  • Joined

  • Last visited

Posts posted by usual user

  1. 1 hour ago, jumbo125 said:

    i want to use a push button on my orange pi.

     

    How to wait for a button press is outlined here.

    If you want to be able to write code that is device-agnostic, you'll need to set up generic gpio-line-names.
    See here for reference.

    With that in place e.g.:

    gpiomon --num-events=1 con1-08 && my-script

    will be able to run on any device that has the gpio-line-names set up in the same way.
    I.e. will wait at pin 8 of the first extention connector for an event.

  2. Ok, everything is as expected.
    So attached is the overlay source as promised and here is how to use it:
    To avoid path information in the commands, I use

    cd /boot/dtb/allwinner/

    as the working directory.
    To compile the overlay, execute:

    dtc --in-format dts sun50i-h618-orangepi-zero3-con1.dtso --out sun50i-h618-orangepi-zero3-con1.dtbo

    This is an one-off action that has only to be repeated when the overlay source changes.
    To apply the overlay statically, execute:

    mv sun50i-h618-orangepi-zero3.dtb sun50i-h618-orangepi-zero3-native.dtb
    fdtoverlay --input sun50i-h618-orangepi-zero3-native.dtb --output sun50i-h618-orangepi-zero3-con1.dtb sun50i-h618-orangepi-zero3-con1.dtbo
    ln -s sun50i-h618-orangepi-zero3-con1.dtb sun50i-h618-orangepi-zero3.dtb

    By modifying the symlink, you can now easily switch between both or possibly multiple pre-build variants of DTBs, regardless of which overlay application method your system provides or not.
    If you don't want pre-built variant support, an in-place application is also possible with:

    fdtoverlay --input sun50i-h618-orangepi-zero3.dtb --output sun50i-h618-orangepi-zero3.dtb sun50i-h618-orangepi-zero3-con1.dtbo

    The application of the overlay must always be repeated if the base DTB changes (update). I've attached this feature to my kernel build process so I don't have to worry about it. The kernel install process is also an option to apply local overlays permanently.

    Of course, you can also use your OS's overlay application system.
    If you want to modify the label names, use my *.dtso as a template and choose a new overlay filename. In this way, both variants can exist at the same time and you can choose as you wish.
    Since this overlay only modifies one property value, it can even be applied repeatedly. I.e. with:

    fdtoverlay --input sun50i-h618-orangepi-zero3.dtb --output sun50i-h618-orangepi-zero3.dtb sun50i-h618-orangepi-zero3-my-labels.dtbo

    you can simply rewrite the property without any further necessary actions.
    I'm sorry that my method doesn't require patches or even rebuilding the entire OS and works in every system from userspace that has the DTC software package installed and the firmware get the DTB provided from the userspace (filesystem) for loading.
    Any system administrator should be able to execute the commands (either symlink adjustment or overlay application) from a running system and activate the changes by rebooting.

    sun50i-h618-orangepi-zero3-con1.dtso

  3. 11 hours ago, robertoj said:

    sun50i-h618-orangepi-zero3.dtb 31.64 kB · 1 download

    I've written an overlay that I think is correct. Since I don't have a Orange Pi Zero 3 I need your help to verify my work. Therefore I have applied my overlay staticly to your provided DTB. Please replace your existing DTB with the attached one. Reboot and post the "cat /sys/kernel/debug/gpio" output again.
    If everything works as expected, I will post the overlay source and explain how to use it.

    sun50i-h618-orangepi-zero3.dtb

  4. 7 hours ago, robertoj said:

    What would be needed to have my orangepi zero 3 show this?

    As allredy stated, a quite simple DTB overlay. See this thread as an entry point for discussions that have already taken place on this topic.
    More on gpio-line-names assignment can also be found in other posts of mine in this forum.
    But after the last posts in this thread I have doubts whether I should continue to participate here. IMHO the basic knowledge seems to be lacking, but they think to know exactly what the solution should look like and don't accept any other implementation. Something like this has repeatedly led to inconclusive discussions, which I am no longer prepared to engage in.
    If you'd like, I can try to walk you through creating a suitable overlay.
    For a first step, I need the output of

    cat /sys/kernel/debug/gpio

     from your running system and the DTB that is currently being used for your system. And last but not least, I need an online link to the DTB source of your device or is this already correct.

  5. This thread inspired me to tinker with GPIO again. I was curious to see how I would realize the example for myself. Since python is not my strong point, I chose a poor man's solution with "dnf install libgpiod-utils".

    I then ran this command:

    gpioset --toggle 100ms,100ms,100ms,100ms,100ms,300ms,300ms,100ms,300ms,100ms,300ms,300ms,100ms,100ms,100ms,100ms,100ms,700ms --consumer panic con1-08=active

    I'm wondering now what the flashing code could say, but I think a ham radio operator would know for sure what it means 😉
    Recreating the python example wasn't really challenging with:

    gpioset -t1000 -Cblink-example con1-08=1

    And besides, I find my flashing pattern much more interesting. I would be interested to know how something like this would be implemented with sysfs. Certainly not with a one-liner.
    These commands work the same way on all my different devices, i.e. it is used for all pin 8 of the first expansion connector. I find it more pleasant to address the pins with con1-xx than to deal with some device-specific gpio-lines again and again. Generated code is therefore portable and can be used on any device without modification, provided that the device can provide GPIO functionality on the corresponding pins.
    The only requirement is that the same gpio-line-name is used for the corresponding GPIO of the extension port. But this can be ensured by a simple DTB overlay. Creating such an overlay is a one-time effort for any device and the first thing I do for a device that I care off.

  6. 8 hours ago, jock said:

    There is a suggestion on how to modify /etc/mpv/mpv.conf in a proper way

    FWIW
    I'm keep puzzled about the options you still throw at mpv. In my Wayland environment, I only have "hwdec=auto" and "hwdec-codecs=all" to automatically enforce video hardware decoding (v4l2 via drm KMS) and take into account all possible hardware decoders. This is necessary because otherwise SW decoding is preferred by default.
    I also don't understand why you insist on involving the GPU, it doesn't have any business in a video pipeline, as I just demonstrated here. The GPU is only used by the GUI and is therefore secondary. Video playback works perfectly even when no GPU driver is loaded at all.

  7. On 12/13/2023 at 1:20 PM, Alexander Buzin said:

    To be able to play something in your browser it is needed kernel support (which is partly present) and the effort from browser developers to implement such feature (this part is missing).

    The output of Code "MOZ_GFX_DEBUG=1 MOZ_LOG="PlatformDecoderModule:5" firefox" tells me a different story, see firefox-nanopc-t4.txt for reference.
    If you don't perform any actions with the graphical UI, nvtop confirms very nicely how the GPU and CPU are idle while Firefox plays a video using the VPU:

    Spoiler

    nvtop-NanoPC-T4-firefox.png.8134f7d9bae517c8ace309a37e6fbd7e.png

    And this is also nice to have:

    Spoiler

    Firefox-plugins.png.ab08f6da2ae411eacb194c8519b20772.png

    The VPU support of rk356x still lacks rkvdec2 support, but the Hantro decoder is already quite compliant, while the support of gstreamer and FFmpeg decoders is on pair. See fluster-run-odroid-m1-summary.txt for reference. So a lot is already happening.

    And all this despite the fact that the distribution of my choice doesn't support any of my devices (not even unofficially). It's all pure mainline, with the exception of the FFmpeg package, which I had to rebuild because the request API support isn't available out-of-the-box there yet.

     

    firefox-nanopc-t4.txt fluster-run-odroid-m1-summary.txt

  8. FWIW, I've moved to 6.7.0.rc2 and the mainline USB regression can no longer be observed:

    /:  Bus 08.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M
    /:  Bus 07.Port 1: Dev 1, Class=root_hub, Driver=ohci-platform/1p, 12M
        |__ Port 1: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
        |__ Port 1: Dev 2, If 1, Class=Human Interface Device, Driver=usbhid, 1.5M
    /:  Bus 06.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M
        |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 5000M
            |__ Port 4: Dev 3, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
    /:  Bus 05.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M
        |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
            |__ Port 1: Dev 5, If 0, Class=Vendor Specific Class, Driver=ftdi_sio, 12M
            |__ Port 2: Dev 6, If 0, Class=Vendor Specific Class, Driver=ftdi_sio, 12M
    /:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=ohci-platform/1p, 12M
    /:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M
    /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M
        |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=uas, 5000M
    /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M

    But new toys in town to play with:

    Spoiler
    fluster-run
    ***********************************************************************************************
    FriendlyElec NanoPC-T4
    CPU 0-3: schedutil 408 MHz - 1416 MHz
    CPU 4-5: schedutil 408 MHz - 1800 MHz
    6.7.0-0.rc2.22.fc37.aarch64+ #1 SMP PREEMPT_DYNAMIC Sat Nov 25 19:54:14 CET 2023
    GStreamer-H.264-V4L2SL-Gst1.0
    GStreamer-H.265-V4L2SL-Gst1.0
    GStreamer-VP8-V4L2SL-Gst1.0
    GStreamer-VP9-V4L2SL-Gst1.0
    ***********************************************************************************************
    Running test suite JCT-VC-HEVC_V1 with decoder GStreamer-H.265-V4L2SL-Gst1.0
    
    [TEST SUITE    ] (DECODER                      ) TEST VECTOR                     ... RESULT
    ----------------------------------------------------------------------
    [JCT-VC-HEVC_V1] (GStreamer-H.265-V4L2SL-Gst1.0) AMP_A_Samsung_7                 ... Success
    ...
    [JCT-VC-HEVC_V1] (GStreamer-H.265-V4L2SL-Gst1.0) WPP_F_ericsson_MAIN_2           ... Success
    
    Ran 116/147 tests successfully               in 278.760 secs
    ***********************************************************************************************
    Running test suite JVT-FR-EXT with decoder GStreamer-H.264-V4L2SL-Gst1.0
    
    [TEST SUITE] (DECODER                      ) TEST VECTOR                         ... RESULT
    ----------------------------------------------------------------------
    [JVT-FR-EXT] (GStreamer-H.264-V4L2SL-Gst1.0) alphaconformanceG                   ... Success
    ...
    [JVT-FR-EXT] (GStreamer-H.264-V4L2SL-Gst1.0) HVLCPFF0_Sony_B                     ... Success
    
    Ran 44/69 tests successfully               in 52.795 secs
    ***********************************************************************************************
    Running test suite JVT-AVC_V1 with decoder GStreamer-H.264-V4L2SL-Gst1.0
    
    [TEST SUITE] (DECODER                      ) TEST VECTOR                         ... RESULT
    ----------------------------------------------------------------------
    [JVT-AVC_V1] (GStreamer-H.264-V4L2SL-Gst1.0) AUD_MW_E                            ... Success
    ...
    [JVT-AVC_V1] (GStreamer-H.264-V4L2SL-Gst1.0) SVA_NL2_E                           ... Success
    
    Ran 129/135 tests successfully               in 110.934 secs
    ***********************************************************************************************
    Running test suite VP9-TEST-VECTORS with decoder GStreamer-VP9-V4L2SL-Gst1.0
    
    [TEST SUITE      ] (DECODER                    ) TEST VECTOR                     ... RESULT
    ----------------------------------------------------------------------
    [VP9-TEST-VECTORS] (GStreamer-VP9-V4L2SL-Gst1.0) vp90-2-00-quantizer-00.webm     ... Success
    ...
    [VP9-TEST-VECTORS] (GStreamer-VP9-V4L2SL-Gst1.0) vp91-2-04-yuv444.webm           ... Error
    
    Ran 228/305 tests successfully               in 329.996 secs
    ***********************************************************************************************
    Running test suite VP8-TEST-VECTORS with decoder GStreamer-VP8-V4L2SL-Gst1.0
    
    [TEST SUITE      ] (DECODER                    ) TEST VECTOR                     ... RESULT
    ----------------------------------------------------------------------
    [VP8-TEST-VECTORS] (GStreamer-VP8-V4L2SL-Gst1.0) vp80-00-comprehensive-001       ... Success
    ...
    [VP8-TEST-VECTORS] (GStreamer-VP8-V4L2SL-Gst1.0) vp80-05-sharpness-1443          ... Success
    
    Ran 59/61 tests successfully               in 14.547 secs

     

     

  9. 4 hours ago, j0ta said:

    hopefully this u-boot will fix the nvme boot problem I have.

    Just out of curiosity, does this firmware build work?

    For a test it is sufficient to put it on an otherwise empty microSD card and old the SPI recovery button (RCY) while powering up. No modifications are necessary to the existing system.

  10. 8 hours ago, Sebastien Motala said:

    I change my distribution from debian bookworm to ubuntu jammy.

    This is also a valid way to confirm that the problem is a matter of configuration in the boot process.

     

    8 hours ago, Sebastien Motala said:

    I solve my problem

    While this solution does not provide insight into the true cause, it is legitimate. Since Armbian doesn't change the basic structure of the base distribution used, but only improves the device support, the root cause isn't even Armbian's fault.
    The developed solution for the operation of the OLED, on the other hand, is exactly within the core competence of Armbian and should be integrated into the build system for general out-of-the-box use.
    This is exactly the contribution you can make to give something back for the contributions that other community members have contributed and that you can use for free.
    This is the only way the Armbian project can grow, there are already enough users who just take and expect that their special requests will be implemented without their involvement free of charge. In a community driven project, you pay through your own contributions. Contributing nothing is a good prerequisite for being ignored in the future if you ask for support again.

  11. I still have an idea for an experiment with your problem:

    - Blacklist the OLED display driver module so it get not autoloaded at system start
      I do it e.g. this way:

    echo blacklist ssd130x-i2c  > /etc/modprobe.d/ssd130x-i2c-blacklist.conf

      But I don't know if it works the same way in an Armbian system.

    - Boot the system without the HDMI monitor connected

    - When the boot process is complete, i.e. all automatic graphical console device mappings are complete, modprobe explicit the OLED display driver module

    - Report if fbcon is no longer binding to the framebuffer device provided by the OLED driver

     

    If this works, it might serve as a workaround, because I'm not sure if the Armbian configuration framework can handle two separate graphic cards. But I'm happy to be taught better by an Armbian insider.

     

    Oh, by the way, this is not a specific ODROID-M1 problem nor is it special because the display driver uses the i2c interface.
    It is a general matter to support several grahic cards at the same time, it doesn't matter which interface they use to communicate. The same would happen, for example, if an additional graphics card is used, which is connected via USB adapter.
    This allows you to find solutions from anywhere and then learn how to configure them in Armbian for its automatisms.

  12. On 10/29/2023 at 11:05 AM, Sebastien Motala said:

    Thank you, your DTB file works.

    Nice to hear, then I can issue my invoice now 😉

    It is now your task to make my contributed knowledge easily available to all Armbian users. Prepare a PR so that my used overlay (which was applied to my provided DTB) will be included in the Armbian build system.
    And while you're at it, include this one (also applied to my provided DTB by default) as well. It simplifies GPIO handling and connector pinout identification immensely.
    If I am correctly informed, they have even simplified the overlay integration into the build system. All you have to do is make the overlay source available in an appropriate directory. To do this, I have attached the sources of both overlays to this post.
    Repairing the pinctrl in the base DTB is not that easy, for this you have to apply the attached patch to the board DTS and rebuild the base DTB. This is necessary so that the correct code artifacts can be integrated into the DTB, this cannot be corrected in a reasonable way with an overlay.
    And don't forget, you'll reap a lot of Armbian users who will be grateful for your contribution. Not to mention the fact that your desired functionality will be available out-of-the-box to everyone in the future.

    On 10/29/2023 at 11:05 AM, Sebastien Motala said:

    I have another problem the tty1 display on the oled screen.

    I'm guessing you only have the OLED display driver loaded in your system and no additional other. This then provides /dev/fb0, which in turn is assigned /dev/tty1 by the system. Usually, the console is also assigned to /dev/tty1 by default.

     

    On 10/29/2023 at 11:05 AM, Sebastien Motala said:

    Where can i disabled this ?

    I don't know the system you're using, but I always configure the console mapping with the kernel command line (/proc/cmdline).

    rk3568-odroid-m1-con1.dtsork3568-odroid-m1-lk-oled1.dtsospecify-pinctrl-for-i2c3-adapter-on-ODROID-M1.patch

  13. 11 hours ago, Sebastien Motala said:

    What pins are activated  on the GPIO  for i2c0  ?

    That was a good question. While researching the answer, I noticed that the basic DTB wires the i2c functionality to pads that are inaccessible on this device. After appropriate correction, the i2c functionality is now available on the documented pins of the board.
     I plugged in my LK-OLED1 display and it works as expected:

    # i2cdetect -y 0
         0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
    00:                         -- -- -- -- -- -- -- --
    10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
    20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
    30: -- -- -- -- -- -- -- -- -- -- -- -- UU -- -- --
    40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
    50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
    60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
    70: -- -- -- -- -- -- -- --

    I re-uploaded the corrected DTB in the previous post. Please download the DTB again to replace the wrong one.

  14. 1 hour ago, winnt5 said:

    Do you test it on NanoPC T4?

    Not only with the NanoPC T4, I'm running the same generic kernel build on all devices with aarch64 architecture. The only thing that is device-specific is the DTB, which informs the kernel about device-specific components.
    There is no Armbian build system involved for me, hence my claim about the build configuration.

  15. 2 hours ago, winnt5 said:

    I found this issue in NanoPC T4

    FWIW, I've been running 6.3.0-0.rc1 for 154 days, just rebooted to switch to 6.5.0-0.rc2.
    USB will continue to work as before:

    /:  Bus 08.Port 1: Dev 1, Class=root_hub, Driver=ohci-platform/1p, 12M
        |__ Port 1: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
        |__ Port 1: Dev 2, If 1, Class=Human Interface Device, Driver=usbhid, 1.5M
    /:  Bus 07.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M
    /:  Bus 06.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M
        |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 5000M
            |__ Port 4: Dev 3, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
    /:  Bus 05.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M
        |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
            |__ Port 1: Dev 4, If 0, Class=Vendor Specific Class, Driver=ftdi_sio, 12M
    /:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=ohci-platform/1p, 12M
    /:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M
    /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M
        |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 5000M
            |__ Port 1: Dev 3, If 0, Class=Mass Storage, Driver=uas, 5000M
            |__ Port 4: Dev 4, If 0, Class=Vendor Specific Class, Driver=ax88179_178a, 5000M
    /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M
        |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
            |__ Port 2: Dev 3, If 0, Class=Vendor Specific Class, Driver=ftdi_sio, 12M

    Issue must be blamed on the build configuration, the kernel source code does not seem to introduce regression.

  16. I'm guessing you're configuring the rc only after XWindow is already started, that way the input event device can't be added as an XWindow input device at times.
    Load the rc keymap during the boot process by adding it to /etc/rc_maps.cfg.

    E.g.:

    *       rc-empty                 your-config-name.toml

    as last line added.

     

×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines