Jump to content

usual user

Members
  • Posts

    416
  • Joined

  • Last visited

Posts posted by usual user

  1. 12 hours ago, Jojo said:

    What could be the next steps?

    Since you have access to all the necessary components, grab an ODROID-M1 OS image of your choice, copy the components into it, and test.
    If you install the OS image in the eMMC, be prepared to reinstall the original firmware. The ODROID-M1S does not have SPI flash and expects the firmware in the first instance in the eMMC. This means that the original firmware will be overwritten.
    Alternatively, you can test with a microSD card, but you have to shortcircuit the MASK ROM pads each time at boot so that the firmware is loaded from there.
    If you only transfer the firmware into the eMMC, you can also start the OS image of micrSD without MASK ROM intervention, this simplifies testing, because in  the OS image only the DTB has to be added and the OS image can be transferred to a microSD card more easily.

    17 minutes ago, Jojo said:

    I think I will try to make a build for the OrangePi 3b

    Nothing has to be build in the first step by yourself, try testing the already availabe components.

  2. Just to demonstrate what such a concern would mean for the distribution of my choice:

    The only thing in OS space that is really device-specific is the devicetree, which describes how the device is wired. For the linux kernel, it is only relevant that the corresponding drivers for the components listed in the devicetree are also built using the necessary options. Since the drivers for the rk3568 SoC are the same as for the rk3566 SoC (they are wired differently only through the devicetree), there is no need for any special action in this case.
    So all I'm missing is a mainline binding compliant devicetree, and I'm done.
    Now all that's missing is a firmware that can start the OS of choice. And this contains device-specific code that can't be copied from another device, and must be built specifically for this device.
    Fortunately, everything necessary has already been posted on the U-Boot mailing list. The devicetree used still has shortcomings, but it is a start.
    In order to verify the handling of different binary bloobs with my build system, I already build the firmware regularly. It's also included in my provided firmware uploads, but I haven't communicated it as I don't own an ODROID-M1S and therefore can't verify its functionality.
    For me, the conlusion means:
    - Install the firmware

    dd bs=512 seek=64 conv=notrunc,fsync if=odroid-m1s-rk3566/u-boot-rockchip.bin of=/dev/${entire-device-to-be-used}

    - run the ODROID-M1S in UMS mode and tranfer my current image to a NVME
    - Since there is no proper mainline devietree, I would use the one that falls off  during the firmware build and copy it in

    cp /somewhere/rk3566-odroid-m1s.dtb /usr/lib/modules/linux/dtb/rockchip/rk3566-odroid-m1s.dtb

    And I'm ready to rumble.
    The same should be able to work with an Armbian ODROID-M1 image.

  3. 10 hours ago, Jojo said:

    your workflow regarding creating an own OS image is definitely beyond my knowledge

    Normally, I would have said: "With suitable firmware in SPI flash, a raw image  on any storage device is sufficient". This is still true for FC38, but further development of the kernel has revealed a flaw in the support of the S922X SoC. This results in a kernel exception for operation with an ODROID N2/N2+. Of course, this means that it no longer works out-of-the-box for newer releases.
    As far as I know, no one has yet provided a mainline acceptable solution, it is just a revert of the advancement. Of course, this is not a long-term solution and is not accepted in mainline.

     

    10 hours ago, Jojo said:

    I can not get clinfo to detect my GPU

    Rusticl doesn't seem to be able to use the Mali GPU in your setup. I can't tell if the kernel doesn't make it available via the panfrost driver or if Mesa 22.3.6 doesn't even provide rusticl panfrost driver support yet.
    For a quick test, I started FC38 again:

    Info-Center-ODROID-N2.png.30770c057a7fea3756c30c2f6d69bd53.png

    As you can see from the clinfo-02.log, Mesa 23.1.9 still lacks basic extensions for rusticl. So it's quite possible that mesa 22.3.6 isn't enough.
    But it may also be that it is messed up by your additionally installed CL platforms.

  4. 22 hours ago, Jojo said:

    My system is Armbian bookworm on an ODROID N2+ (Mali-G52).

    I'm currently running this:

    Info-Center-ODROID-N2.thumb.png.9b10c6ed8274c2519eed85d2c72ef689.png

    since Debian based systems are for my taste way to stable - outdated.

    22 hours ago, Jojo said:

    Do you have any idea about a workflow how to get OpenCL running properly?

    At times, I grab a nightly image, rearrange it to my liking, drop in my personal configuration preferences and use it till the cycle restarts.

     

    22 hours ago, Jojo said:

    What driver (ARM, HK...), what to copy, what to compile, where to copy...

    Nothing special, the key is current mainline releases.
    Panfrost has been very mature for a long time, so the kernel version may be a bit older.
    But of course, the latest version comes with the latest fixes and improvements.
    The same goes for Mesa, and that's where the current release is important, as the development of Rusticl is still quite vivid.

    To use a version that is more than a year old, and thus to forego any improvements that have taken place during this time, is quite courageous.
    But nevertheless, I would be interested in the output result of this command:

    RUSTICL_ENABLE=panfrost clinfo

     

  5. 1 hour ago, hjheins said:

    do you mean the spi boot/petitboot on teh Odroid N2?

    The device firmware is the only truly device-specific code that initializes the SoC and loads the OS. In the x86 architecture world, this is called BIOS. It often uses U-Boot as payload, but there are other ones as well. With its proprietary implementation, Petitboot can't even use the most common standard bootflows and will be therefore usually replaced by mainline firmware versions.

     

    1 hour ago, hjheins said:

    How can I find more info on your firmware build please?

    Mainline firmware for ODROID-N2/N2+

  6. 7 hours ago, Jojo said:

    I tried a lot of thing like the default panfrost driver, self-compiled ARM driver, ARM userspace driver...

    I haven't tried any of that. I only used the distribution of my choice. It is in no way designed specifically for a specific device. The only requirement to use it is a firmware that is capable of booting the system. But since there's mainline firmware support for many devices, and I've learned to build it from the sources according to my needs, the same OS image works the same way for me for every device.
    To create the previously attached log file, I only had to use an environment variable to reveal the backend to be used with rusticl and was ready to go. The user space doesn't use anything device-specific, but is only built from current mainline releases. That's what the OS developers did for me, and they don't even know what devices I'm using it on.

  7. 8 hours ago, hjheins said:

    Does anyone know this behaviour

    Something like this has happened in the past. The firmware is flaky to some eMMC variants. If you search the forum, you will find relevant posts. Some users have used my firmware build and been successful, but I don't think the true cause has really been figured out.

  8. 3 hours ago, Celona said:

    At this moment fails on ARM Cortex-A53 and Cortex-A55

    Looks like I'm already equipped with it by upgrading behind my back.

    Spoiler
    # dnf provides */libopus.so.0
    
    Last metadata expiration check: 0:25:05 ago on Sun Mar 17 20:37:08 2024.
    opus-1.5.1-1.fc41.aarch64 : An audio codec for use in low-delay speech and audio communication
    Repo        : @System
    Matched from:
    Filename    : /usr/lib64/libopus.so.0
    
    opus-1.5.1-1.fc41.aarch64 : An audio codec for use in low-delay speech and audio communication
    Repo        : rawhide
    Matched from:
    Filename    : /usr/lib64/libopus.so.0

     

  9. 49 minutes ago, Christian Willemsen said:

    What device ${entire-device-to-be-used}. Do i put here

    If the microSD card in the microSD card slot is the one with the Armbian_24.2.1_Odroidn2_bookworm_current_6.6.16_cinnamon_desktop.img.xz then it is:

    dd bs=512 seek=1 conv=notrunc,fsync if=odroid-n2-plus/u-boot-meson.bin of=/dev/mmcblk1

    It is always the NAME that lsblk enumerates with the TYPE "disk".

  10. 8 hours ago, Maverick said:

    I require assistance in utilizing WiringPi for  Banana Pi CM4.

    Read what the original author posted.

     

    8 hours ago, Maverick said:

    Limited GPIO support on Banana Pi CM4

    Banana Pi CM4 has full generic GPIO support in mainline kernel ready to use. With libgpiod, all the necessary Python 3 bindings are available, so start writing your planned application. Since you have even developed the board yourself, you also have the necessary knowledge of which of the approximately 100 GPIO-capable pins you have wired where.

  11. 10 hours ago, Igor said:

    Should we install this by default?

    I'm not sure who really needs the python bindings.
    Users keep talking about WiringPi not working for their device, but they don't say what functionality they want to use with it. In the isolated cases where they do, it is such trivial applications that can be conveniently operated with the available command line tools. So no need to involve any programming activities.

     

    And the same is true for the Sysfs API fraction. The existing command line tools cover the entire Sysfs spectrum and even go beyond.

     

    For example, I would like to see how someone implements this one-liner with the sysfs:

    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 curious about the precise timing to generate such a blinking pattern.

     

    Or retrieving a pin for three keystrokes and resulting script execution:

    gpiomon --num-events=3 --edges=rising con1-08 && bash-script

     

    For the users who actually need more complex implementations and have the necessary coding skills, I think they should also be able to install the bindings with:

    sudo apt install python3-libgpiod

    And maybe someone wants to use C++ or Rust.

     

    But first and foremost, people seeking help should learn to describe the basic problem they are trying to solve, rather than asking for help as they think it can be solved.
    I don't usually respond to requests that don't match this, because nothing is more annoying than realizing that you have wasted unnecessary time on a solution when it could otherwise have been solved more appropriately.

     

    And look, what was the immediate response to my given reference in response to a direct question?

    On 3/4/2024 at 10:50 AM, Maverick said:

    will it work with python?

    In the case of such NOOBs, further engagement is usually not conducive.

  12. You have provided far too little context, and I do not understand what you are talking about. But if it's just the output of a pattern waveform via a GPIO, you can do it with a one-liner from the command line:

    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

    This is just an example and the emitted pattern doesn't meet your needs, but with adjusted timings it does exactly what you want.
    Of course, you can also write your application with program code. Libgpiod provides bindings for C++, python3 and Rust therefor.

  13. 7 hours ago, SteeMan said:

    the overlays are currently being shared between the h616 and h618.

    Overlays are always device-specific, and in most cases, even use-case-specific.
    Trying to share between different devices takes a huge amount of maintenance as opposed to a simple copy of a similar overlay. All possible interactions have to be taken into account and expecting NOOB users to understand their dependencies is asking for trouble. And if they do have to be different later, it is even more difficult to sort them apart.
    And besides, what advantage does it bring to the user, since all Armbian images only address one specific device at a time?

  14. 7 hours ago, robertoj said:

    I didn't integrate it in the whole SBC dtb. I left it as a dtbo and copied it to the user overlays

    A perfectly legitimate method, but not always available:

     

    7 hours ago, robertoj said:

    https://docs.armbian.com/User-Guide_Allwinner_overlays/#armbian-specific-notes
    Armbian specific notes
    DT overlays are a Work-in-Progress (WIP) feature, present only in certain images.
    Please note that different SoCs will have different sets of available overlays.

     

    7 hours ago, robertoj said:
    {check that the GPIO pins are not named}

    This is not necessary, an overlay is just an overlay that overlays what already exists. Run the command "fdtoverlay..." three times in a row, keep DTB backups each time and compare them at last.

     

    7 hours ago, robertoj said:

    I was expecting it that the user overlays appear in the armbian-config utility... but my dtbo didnt show in the system>hardware selection options... is this normal?

    This is a question for the one who came up with the overlay application method.

     

    7 hours ago, robertoj said:

    be careful of conflicts in activating a kernel-provided overlay and a user overlay at the same time

    Mainline kernel usually doesn't come with overlays, they are usually added by the Armbian build system. My method should also work in combination.

     

    7 hours ago, robertoj said:

    Failed to load '/boot/overlay-user/sun50i-h618-orangepi-zero3-con1.dtbo'

    Judging by the failure message, the overlay can't be found.

     

    7 hours ago, robertoj said:

    HOWEVER: the DTSO works when applying it in the DTB, as you suggested. It is only when trying to apply the DTBO with uboot, it fails.

    You have thus proven that there is nothing wrong with the base DTB and the DTBO. It is to blame the tool (method) that is used to apply the overlay.
    Dynamic application of overlays at boot time is only necessary if the firmare can automatically detect the need to apply an overlay by reading hardware identifiers. This is a method inherited from the Raspberry Pi and has its justification with its expansion modules with hardware identifier.
    Using a configuration file (armbianEnv.txt) is just another way of statically selecting overlays and basically the same procedure as my method. I understand that overpaid Armbian developers implement something like this method out of boredom for devices that don't need it and then dynamically apply the statically selected overlays. But I prefer to rely on tools (fdtoverlay) that are more mature. After all, it's used in every kernel build (it's part of the kernel sources)  and maintained by the mainline Devicetree developers. And if something didn't work with it, it would immediately stand out and also be repaired. Because kernels are very rarely built 😉

  15. 6 hours ago, Brendow said:

    It kept showing "UUID does not exist" (and I don't know why, so if anybody knows, please tell me).

    Chances are, you've destroyed the integrity of the resulting DTB and the kernel can't even access the device with the rootfs.

     

    6 hours ago, Brendow said:

    really appreciate your efforts @usual user for providing the .dts

    That dtso was more ment in @robertoj's direction to showcase gpio-line-names setup for this device.

     

    From the rest of your post, I don't really know what you're talking about. Nevertheless, I have written an overlay from scratch according to your recipe.
    For a first test, please disable any overlay application using the Armbian method in armbianEnv.txt and apply the overlay with my method.
    With an copy of your base DTB execute this command:

    fdtoverlay --input sun50i-h6-orangepi-3-lts.dtb --output sun50i-h6-orangepi-3-lts.dtb sun50i-h6-orangepi-3-lts-spi1.dtbo

    Now swap the currently used DTB with this one, reboot and test if it works as expected. After a successful test, you can try out the application with the Armbian method.

    sun50i-h6-orangepi-3-lts-spi1.dtso

  16. 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.

×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines