usual user

Look at "/sys/kernel/debug/gpio", it will tell you wich gpio is in use by which driver.

See here.

Bootstd is scanning for a valid bootflow at the partition where the bootflag is set. If none is set, the first partition is used as a fall-back default.

Mainline U-Boot scans at various locations for valid bootflows. Usually eMMC and microSD are scanned befor NVMe, so as long as an valid bootflow is found there, that one is used.

Looks like some partition format mixup, btrfs vs. ext4.

You are still using legacy firmware, the first step should be to switch to mainline.

Setup mem=16G at kernel cmdline.

The issue is probably due to the fact that rk35xx SoCs have to carve out some memory areas above 16 GB as reserved. Access to those areas leads to crashes. Because no fully open source TF-A is available yet, current mainline U-Boot has mechanisms landed to take the area information from the closed source TPL. Chances are the firmware you're using hasn't backported this yet, because devices larger than 16GB are only now becoming widely available in the open market.

I would run: gpiomon --consumer 433MHz --edges both --format "%S %E" con1-07 | tee 433MHz.log I would let gnuplot chew on the result of the gpiomon run to visualize (433MHz.pdf) it, because I can interpret an image better than any columns of numbers. This is a program that is over thirty years old and works on almost every platform and can be used in any environment, and you can only complain that it is not a special solution and that you don't have to rebuild half the system yourself, but that doesn't bother me. After I have identified the relevant places, I would take the corresponding timeings from the log and thus generate a suitable gpioset command that imitates the original.

No, it's just the spec with which my currently running mesa is built. Already the mesa version with which I started had all the necessary, essential functions. Of course, all bug fixes and improvements that have been incorporated in the meantime are not included there. No, there is not much to see in terms of kernel. As long as the Panfrost driver is built and the Mali GPU is properly wired-up in DT, there is nothing to do. It's about the user space counterpart mesa. It is the component that make use of the GPU the kernel exposes. If you want to check all dependencies, you have to look at all spec files that are pulled by Requires from the mesa package. For me, however, this is done by the package manager during installation. And to build mesa, I install all BuildRequires with: dnf builddep mesa.spec But building Mesa yourself has long since ceased to be necessary, as no modifications are necessary and the standard package works out-of-the-box. Your build configuration options are looking incomplete. Here's an excerpt from the build.log resulting from the spec file: /usr/bin/meson setup --buildtype=plain --prefix=/usr --libdir=/usr/lib64 --libexecdir=/usr/libexec --bindir=/usr/bin --sbindir=/usr/sbin --includedir=/usr/include --datadir=/usr/share --mandir=/usr/share/man --infodir=/usr/share/info --localedir=/usr/share/locale --sysconfdir=/etc --localstatedir=/var --sharedstatedir=/var/lib --wrap-mode=nodownload --auto-features=enabled . redhat-linux-build -Dplatforms=x11,wayland -Ddri3=enabled -Dosmesa=true -Dgallium drivers=swrast,virgl,nouveau,r300,svga,radeonsi,r600,freedreno,etnaviv,tegra,vc4,v3d,kmsro,lima,panfrost,zink -Dgallium-vdpau=enabled -Dgallium-omx=bellagio -Dgallium-va=enabled -Dgallium-xa=enabled -Dgallium-nine=true -Dteflon=true -Dgallium-opencl=icd -Dgallium-rusticl=true -Dvulkan-drivers=swrast,amd,broadcom,freedreno,panfrost,imagination-experimental,nouveau -Dvulkan-layers=device-select -Dshared-glapi=enabled -Dgles1=enabled -Dgles2=enabled -Dopengl=true -Dgbm=enabled -Dglx=dri -Degl=enabled -Dglvnd=enabled -Dintel-rt=disabled -Dmicrosoft-clc=disabled -Dllvm=enabled -Dshared-llvm=enabled -Dvalgrind=enabled -Dbuild-tests=false -Dselinux=true -Dandroid-libbacktrace=disabled

Have you made sure that all BuildRequires have been properly fulfilled and that the build configuration options have been selected correctly? Especially hardware-related ones.

I've started with this, but the logs provided are created with this system: However, the system used is not really important, the Mali support has been very mature in mainline for a long time, so any correspondingly built system should be usable.

Works for me since ages. glmark2-wayland-nanopc-t4.logclinfo-fp-nanopc-t4.log

I guess with such an attitude you certainly can't motivate anyone to find an immediate solution to your problem. Maybe you'll be lucky and it will work with a future release, but until then all you can do is keep trying and waiting. You got what you paid for. The currency here is to contribute to the project (Armbian) and help with problem analysis. The project is community driven and you are a member of the community.

Does it make a difference if you drop in this firmware?

Since userspace cannot sensibly select between two decoder instances of the same type, the H.264 hanto decoder is usually disabled for the rk3399 and the H.264 rkvdec is preferred. videoX-infos-nanopc-t4.log

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.