Jump to content

usual user

Members
  • Posts

    416
  • Joined

  • Last visited

Everything posted by usual user

  1. 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. 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. If there is already firmware with U-Boot as a payload on the device, the UMS functionality is a possibility. In the meantime, all my firmware builds have easy access to this functionality, as long as the support requirements are met. I don't know the support status of the Allwinner H616 SoC, hence YMMV.
  4. 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. 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: 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.
  5. I'm currently running this: since Debian based systems are for my taste way to stable - outdated. 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. 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
  6. 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. Mainline firmware for ODROID-N2/N2+
  7. 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.
  8. 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.
  9. For me, unfortunately, only OpenCL 3.0. clinfo.log
  10. Looks like I'm already equipped with it by upgrading behind my back.
  11. Quite possible, because due to my migration to bootstd, this entire code block no longer exists for me.
  12. OK, then you're now on this version and it's not a general issue, it's about how Armbian's firmware is built.
  13. 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".
  14. 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}
  15. 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.
  16. 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.
  17. 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.
  18. 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.
  19. 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?
  20. 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 😉
  21. 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
  22. Out of curiosity and for my own education, I wrote the attached overlay. If you apply this to the base DTB of the orangepi 3 lts, the GPIO code of @robertoj should be able to run unchanged on this device as well. sun50i-h6-orangepi-3-lts-con1.dtso
  23. 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