usual user

Allready landed in mainline, you get the fix out-of-the-box since v6.11-rc3.

This says that the necessary short circuit was not present when the MaskRom code scanned for boot devices. The short circuit must be ensured before the power supply is switched on, and must be maintained until a few seconds later. The procedure is a three-handed job. One hand fixes the PCB, one hand holds the tweezers, and one hand switches on the power supply. This can only be reliably ensured with a shelf holder who uses Pogo pinns. IMHO a bad board design for a tinker device. A push button or at least holes for a plug contact to connect a proper switch if necessary would be the better solution. Be grateful to your board designer.

Since the "upgrade button" is only software readable, and the firmware (U-Boot) that does it is corrupt, only this method remains. In MaskRom_mode I would first delete the corrupt firmware in the eMMC, so that the firmware loading falls back to the microSD card. This allows different firmware variants to be tested without having to use the clunky method to get into the MaskRom_mode. Then I would prepare a microSD card with supposedly suitable firmware and boot the device with it. The function can be verified looking at the serial console output. Once a suitable firmware has been identified, I would add an OS image to the microSD card to evaluate the full functionality. It may be possible to speed up the procedure if a complete image with suitable integrated firmware is already available. Finally, if necessary, the firmware can be placed in the eMMC again.

Since I don't even know which system component the supposed GPIO line is connected to, I could only speculate wildly. The appearance is certainly due to the wiring in the DT, but this is also a speculation to which I do not want to comment further, but leave it to qualified people. Alternatively, you could look in the exact DT sources from which the DTBs used at runtime were assembled, but I don't have access to that. You could also add the line to the output with: gpioset --consumer=reset -c0 234=on but it certainly won't give the same functionality as in the original case, as it's a completely different use case.

Your device stalls in early firmware not even the payload (U-Boot) is reached. Which OS is used is anything but important at this point. Make sure that a suitable firmware is used before you worry about the userspace. Devices with Rockchip SOCs are unbrickable, you can recover at any time by restoring a suitable firmware.

Since there is no public link to the result, I suspect it. Since a single false character in a DTS(O) can already lead to a malfunction in its consuming code, this is completely unsuitable for debugging. If the DTB's build framework is added as a source of error, be my guest, but please don't expect any help from me in this case. It's the same as asking an application developer to identify a bug in the compilation toolchain by disassembling their binary application code without having access to the exact sources from which the particular binay was built.

IMHO it is much more likely that the DT description is incorrect, but with the Armbian DT workflow there is not the slightest possibility to verify it automatically with the binding documentation. But since not even the original DT sources are readily available, you can't even validate them manually. And once sources are available, they are usually written in disassembler syntax, which does not make them easier to read. In addition, there is the fact that many attempts are made to merge snippets of DTS from different devices by "copy & paste" in the hope of magically getting a working device. This is just as doomed to failure as the attempt to use arbitrary schematic snippets of various devices to describe a certain PCB for a specific device. In the DT world it is even more challenging, because the DT layout is even use case dependent and runtime changeable.

Ok, you have confirmed that the GPIO line can be properly acquired by a suitable process and the GPIO subsystem is working as expected. The SPI subsystem does not seem to do this as desired for the CS line. Whether this is due to a bug patched out of tree in the 5.15.88 kernel, or just a configuration error in the DT, I can't say, since you haven't published any DT sources on how your SPI controller is wired. I'm interested in the original sources from which the DTB was created, and not any from some disassembled DTB, as this has lost valuable information that was striped out during the assembly of the DTB. But I also know that it is very difficult to acquire them with an Armbian build system since they most probably only exist as build artifacts which get composed from various patches.

"/sys/kernel/debug/gpio" represents what the kernel has instantiated. Its accuracy depends on the exact description (DT), as the layout cannot be probed. But many people think they can copy DT fragments of similar devices together to get an exact description of a particular device without verification. But it's just like a device schematic, it will never accurately replicate the layout design of another device. DT is just one step further, as it can change the layout itself at runtime. The test was intended to verify that the GPIO subsystem is correctly configured and that the GPIO line can be acquired from a native GPIO process. This is because the line cannot be operated as a native CS line by the SPI IP but only emulated with the cooperation of the GPIO Subsystem. Mine does:

Of course, I don't know which patches Armbian has applied at times, but what looks suspicious is the fact that the gpio line numbers used in the "/sys/kernel/debug/gpio" logs for the gpiochip1 differ. This shouldn't be caused by the DT, and if it is, it should be the same as using the 5.15.88 variant again. To test the basic function of the GPIO subsystem in 6.6.16, post the state of "/sys/kernel/debug/gpio" while gpioset -c0 34=on is running at the same time with root permissions.

/boot/dtb/ is probably a symlink to the real /boot/dtb-5.15.88 dirctory with the version number in the name to hint the source version the DTBs are build from. I usually have plenty of kernels installed at the same time, so that it only takes to adjust the symlink to refer to a different DTB set. But this doesn't work so easily in Armbian with its single kernel layout strategy, because it results in name and directory conflicts there. But in your case, it should be sufficient to copy the /boot/dtb-5.15.88 directory alongside to the /boot/dtb-6.6.16 directory and adjust the symlink accordingly. Oh, just to be clear, they're both mainline kernel builds and there's no legacy kernel fork involved, because in this case it won't work, because most likely incompatible out of tree hacks are involved. You can't mix binaries of kernel components of different versions, not even different builds of the same version, because you can't make sure that the ABI hasn't changed. For DTBs intermixing is possible because they describe hardware and are agnostic of the consumer binary code. The mainline kernel with its "no regression" policy ensures that earlier releases remain functional. For a given userspace, you can use any kernel as long as it's build is configured with the same components, because it exposes a stable userspace-kernel API.

To rule out that with the error prone Armbian DT workflow something got messed up, run the 6.6.16 kernel with the DTB and its related DTBOs created with the 5.15.88 build.

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