usual user

meson-g12b-odroid-n2-plus.dtb is a base DTB with a static applied overlay. In your mentioned thread at post 23 is a reference to a parallel thread where the overlay source is provided. So prepare a PR so that the overlay can be included in Armbian. You'll probably reap tons of grateful users who have been waiting for someone to make the effort.

Some settings that were set at build time can't be modified at runtime. This requires a new firmware build, e.g. to set the boot delay to 0, the build configuration has to be set to "CONFIG_BOOTDELAY=0". This is due to the build configuration. The build configuration determines the properties of a binary created from a certain source. These can be detail settings, or even decisive for which hardware it is usable. Finally, U-Boot can be built for all devices from the same source of a given release version. E.g. "make libretech-cc_defconfig" prepares a default configuration for LePotato. You can use "make menuconfig" to fine tune it afterwards. I don't know the details of Armbian's build framework, but I'm sure you can inject a patch that implements your desired change.

This is not correct. Due to its size, U-Boot must be run from RAM. The RAM must therefore already be initialized before U-Boot can be loaded at all. This is usually done by Trusted Firmware-A (TF-A). U-Boot is only the payload (in TF-A terminology: BL33). You might want to read TF-A's documentation to understand the boot flow, I think here is a good place to start. You're lucky if TF-A is open source for your SoC, but often only a binary BLOOB for BL2 and BL31 is provided by the SoC manufacturers.

Your firmware is build without persistent Environment. Only the compiled-in Environment is used, which can only be modified before build.

I'm glad you were able to solve your issue. However, I will still stick with my firmware in SPI flash, because it gives me slightly more control over the boot process:

Since you're still using a nine-year-old firmware that was built almost three years ago, I'm assuming that you haven't transferred the firmware that came with the linux-u-boot-odroidn2-current package to the firmware area. As far as I know, this is a process to be initiated manually in Armbian. The firmware used obviously can't handle the bootflow of the more advanced OS or maybe some old bootflow artifacts weren't cleaned up properly.

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.

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.

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.

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.

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

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+

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.

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.

For me, unfortunately, only OpenCL 3.0. clinfo.log

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

Quite possible, because due to my migration to bootstd, this entire code block no longer exists for me.

OK, then you're now on this version and it's not a general issue, it's about how Armbian's firmware is built.

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

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}

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.

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.

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.

What's wrong with libgpiod?

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.