Jump to content

usual user

Members
  • Posts

    408
  • Joined

  • Last visited

1 Follower

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. For me, unfortunately, only OpenCL 3.0. clinfo.log
  2. Looks like I'm already equipped with it by upgrading behind my back.
  3. Quite possible, because due to my migration to bootstd, this entire code block no longer exists for me.
  4. OK, then you're now on this version and it's not a general issue, it's about how Armbian's firmware is built.
  5. 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".
  6. Out of curiosity, does it boot when you drop in my firmware build? dd bs=512 seek=1 conv=notrunc,fsync if=odroid-n2-plus/u-boot-meson.bin of=/dev/${entire-device-to-be-used}
  7. Read what the original author posted. 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.
  8. 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? In the case of such NOOBs, further engagement is usually not conducive.
  9. The distribution of my choice offers me ready-made binary packages out-of-the-box. However, I have to install the Python 3 bindings separately. I know that the command line tools are apparently also available out-of-the-box in Armbian, but I don't know if the Python 3 bindings are also packaged separately.
  10. 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.
  11. 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?
  12. A perfectly legitimate method, but not always available: 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. This is a question for the one who came up with the overlay application method. Mainline kernel usually doesn't come with overlays, they are usually added by the Armbian build system. My method should also work in combination. Judging by the failure message, the overlay can't be found. 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 😉
  13. Chances are, you've destroyed the integrity of the resulting DTB and the kernel can't even access the device with the rootfs. 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
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines