usual user

The supplied logs prove that the kernel causes a "synchronous external abort" when the pcie sybsystem is initializing. The fact that both logs look similar is because both images use the same kernel and user space doesn't even come into play when the issue occurs. Since a rather old kernel is used, I would first switch to a more recent one to further identify the issue. With my rk3399 device I have been using NVME flawless for a long time. I therefore assume that there is no fundamental code problem. However, I am currently running 6.1.0, which contains improvements that were certainly not back-ported to 5.15.80. The rk3399 mainline kernel support is very advanced, so it doesn't make much sense to waste time analyzing a behaved kernel. Maybe the issue no longer exists with a kernel upgrade and that's all that's necessary.

TF-A is progressing slowly, but there seem to be still open questions. The DT rebase of u-boot has taken place. It still takes a rebase to be up to date, but this is only a small thing, because the basic structure conversion has already taken place. But I haven't seen any movement in uboot WIP trees that I'm aware of. IMHO they are waiting to see how the TF-A development turns out in the end to develop u-boot accordingly further. I will report when I get news. But the most important thing is that for the kernel only the rkvdec2 support is missing, and for the userspace only the FFmpeg v4l2-request support is missing to be usable out-of-the-box with pure mainline support for standard applications. It is thus available for all distributions without special effort for the Odroid-M1. They only have to maintain the distribution-specific modifications that they apply for other devices anyway. I'm currently playing with jernej's FFmpeg patches for v4l2-request support and VP8 acceleration seems to work. H.264 fails with this error: [h264_v4l2m2m @ 0xaaaabfc5ae10] Could not find a valid device [h264_v4l2m2m @ 0xaaaabfc5ae10] can't configure decoder But I don't know if the 5.1.2 paches basically work or how I can inspect the FFmpeg framework appropriately. With the gstreamer framework, however, everything works as expected.

Odroid-M1 support has just landed so will be available with 6.2.0-rc1 out-of-the-box. RGA support can be wired on top (v4l2-compliance.log), but the DMA deficiency for 32-bit addresses needs to be addressed for devices with more than 4GB of RAM.

For out-of-the-box mainline kernel support you need at least 6.1.0-rc1 because that's where all currently available code for the rk3568 SOC has landed. GPU support has been available for a long time, see glmark2-wayland-odroid-m1.log for reference. And Mali-G52 is official conformant for OpenGL ES 3.1. VPU support is only available for the hantro IP. So hardware-accelerated video decoding of H.264 and VP8 works up to 1080p. See fluster-run-odroid-m1.log for reference. The available drivers are in quite good shape, see v4l2-compliance.log for reference. The support for the rkvdec2 IP is not yet available, so no 4K resolution and no VP9 and HEVC hardware decoding for now. Hardware encoding is only available for JPEG in poor quality. But missing mainline encoder support applies almost for all SOCs. If you need 4K resolution, VP9 or HEVC codecs, you have to currently rely on the vendor's legacy kernel with proprietary interfaces.

Because the sysfs interface is only a wrapper for the character device interface to provide users with the legacy interface if they insist, this is to be expected. Since you did not say how the base DTB wired the pins, and I am too lazy to pick it out myself because I do not own this device, this is a very expected result. For example, I see from the information here that pin 32, 33 are occupied by default with the serial console (UART functionality). Applying overlays can reconfigure the default functionality, but not all pins are configured with GPIO functionality by default. Good vendors offer appropriate documentation for their provided software, but since the configuration depends on the active DTB, it is at best to be interpreted as a guide. Any other provider may have changed the configuration according to their ideas.

The method used to transfer an image byte by byte to a target device is not important. It does not change the function of the transferred code as long as no transmission errors occur. Due to the detailed description of the procedure and the confirmation that the system is working, it is proven that nothing has been done wrong so far. The problem only arises when the NVME device comes into play. The use of different images also proves that there seems to be a fundamental issue that seems worth investigating further. But a basic prerequisite are meaningful logs, and without them it is hopeless from the beginning. The excuse of not having a suitable USB serial adapter available to provide logs is mood. Every reasonably assorted electronics shop offers these for little money. Choose whatever your host system with which you want to use the adapter supports, make sure that the operating voltage of the RX/TX lines matches that of the SBC and the adapter supports a baud rate of 1500000 and you are ready to go. Tinkering with SBCs sooner or later requires access to the serial console for one reason or another. If you don't want that and have a turnkey system, an SBC isn't the right choice.

Providing the serial console logs of the boot process helps with error analysis and greatly increases the likelihood that the issue can be fixed.

gpioset --help

I doubt it, if mainline development continues at the same rate as before, the next WIP patches for the pending drivers will certainly be available at this time.

PINE64 does an excellent job documenting the state of development for mainline development. Although it is for the rk3566 SoC, it is one to one transferable for the rk3568 SoC. Except for the rkvdec2 support, the support is pretty much on par with the rk3399 SoC. And the good thing, everything has already landed in mainline and all userspace software that have support for the rk3399 SoC also work unmodified for the rk3568 SoC. So except for the 4K decoder support, devices with the rk3568 SoC are already quite suitable for everyday use. I am very confident that the rkvdec2 support is only a matter of time and then 4K media can be enjoyed impeccably. I would now only wish that all board manufacturers provide equivalent documentation for there devices, as PINE64 has shown here. This would simplify mainline usability immensely and one wouldn't have to deal with legacy forks, but I think that remains a pious wish.

4.19 legacy makes sense if you want to use functionalities for which there is no support in mainline for the rk3568 SoC yet. But this also requires special userspace software that can use these proprietary interfaces. 5.19 doesn't make much sense, because it requires backporting everything that has already landed in 6.1.0-rc. Especially if you use the tobetter tree to pull from because it is based on very early WIP patches that contain bugs that are already fixed in mainline. As far as I know, 6.1.0-rc contains all mainline code available for the rk3568 SoC. So there is currently nothing relevant to add. For the ODROID M1 support only the source for the rk3568-odroid-m1.dts is missing. This can be easily added by cherrypicking the relevant commits from the maintainer tree. Or you build from linux-next and have the full preview on 6.2.0-rc1. But from the point of view of the ODROID M1, this only adds the rk3568-odroid-m1.dts out-of-the-box. IMHO you should start with 6.1.0-rc for the ODROID M1 and mainline kernel support. Everything else is unnecessary work that does not provide any advantages over 6.1.0-rc. Of course, all distribution dependent additions can still be applied, but from the point of view of the ODROID M1 they are not absolutely necessary.

This error message indicates to me that the module does not support a certain functionality. Mainline releases tend to be more advanced than outdated forks with out-of-tree hacks that have never been ported to mainline. Now, if Mainline uses new eMMC features that are not supported by a module and even the recovery attempt fails, the legacy firmware may work better in this case. It does not trigger this circumstance. Since mainline development does not rely on the support of a special module, it can lead to such failures to the advantage of other modules that support these functions. You can now try to determine the cause and then have a fix incorporated into mainline if necessary, but that's out of my interest, since I don't have any eMMC modules. I provided my firmware builds just to be able to do a quick test to see if a fix has already been added to mainline, saving you the hassle of building it yourself or waiting for it to become available in Armbian. I build the firmware for me for other reasons anyway. This also saves Armbian the effort of quickly integrating a new version if there is no improvement anyway. But I think a prepared PR is still welcome to keep Armbian up to date if this does not lead to regressions. This is not entirely true. The dd command is the same for microSD and eMMC except for the "of=" parameter. Both are MMC devices and the block device data structure (MBR) is identical, only the hardware interface used is different. But this is handled by the corresponding drivers and is not important from the user's point of view. For SPI flash, that's a different story. SPI Flash does not necessarily use block device data structures and therefore the firmware range starts at offset zero. Therefore, the dd command for SPI flash looks like this: dd conv=notrunc,fsync if=u-boot-meson.bin of=/dev/mtdblock0 Alternatively, you can also use "flashcp".

I just looked at this page. To me it looks as if the colors are used to distinguish which devices they are intended for and with which OS system they are supplied. For the N2 I see only two colors to distinguish between Linux and Android. All eMMCs marked in orange appear to be intended for other devices. Could it be that this is the reason why they do not work reliably with the N2?

Since I have already uploaded 2022.10 GA at the request of someone else, it can be downloaded here if there is still a need. The u-boot GitLab is here. But I am building from the release tar ball with a fedora toolchain. In any case, you only get the u-boot.bin, which still has to be signed with the binary-only tools from the vendor u-boot tree and combined with the binary-blob artefacts to the FIP. In the case of Armbian, surely the better solution is for someone to adjust the Armbian building system to a more recent version and issue a pull request so that the change can be integrated into Armbian. He will certainly reap the thanks of many happy Armbian users. By the way, for another occasion I just verified that UEFI boot also works. See console.log for reference.

There is also 2022.07 GA available and if you insist I can also upload 2022.10 GA.

The necessary command has already been given before: ir-keytable -s rc1 -tp all It can be used to collect the scancodes to create the MXQ-PRO-4K.toml. The link has been provided to look up the meaning of the specified parameters and to obtain further background information. This command shows what the contents of the MXQ-PRO-4K.toml should look like: man rc_keymap For reference see the *.toml files that come with v4l-utils. With your provided information, the /etc/rc_maps.cfg entry must look like this: * rc-rktvbox MXQ-PRO-4K.toml

The hard work is already done, the kernel enumerates your IR device. Basically, only a suitable keymap is missing to emit the key codes you want. Each IR remote control sends different scan codes and each user expects different keycodes that are triggered at the touch of a button, so it is up to each user to create a corresponding keymap. Use ir-keytable -s rc1 -tp all from the v4l-utils ackage to determine the scan codes and assign them a keycode in e.g. a MXQ-PRO-4K.toml (man rc_keymap). If the MXQ-PRO-4K.toml located in the /etc/rc_keymaps directory is also registered in /etc/rc_maps.cfg, it will be loaded at system startup and the remote control will work out-of-the-box, e.g.: * rc-empty MXQ-PRO-4K.toml

When I am asked about Debian and its derivatives, I usually jokingly answer "IMHO Debian is stable ... outdated". I say this because Debian targets x86 as the main architecture. Because the x86 architecture has been feature complete for decades, you can also use older stable program releases with full functionality and it takes time till new releases trickle in. But we play with the ARM architecture and there the development is still at the bleeding edge. Program releases can therefore not be up-to-date enough, and usually still require pending patches. Fedora is tracking mainline quite close. To check what the current status is, I recently conducted a small experiment. My current system is based on fedora FC34 and is due to WIP patches and current release versions on a well-functioning state. Many of the components I added manually have recently landed in recent mainline versions. I have now copied a rootfs with the content from the upcoming fedora FC37 KDE Plasma Desktop Spin into a free partition of my NVME and added my current kernel build. After I also added a boot stanza to the extlinux.conf to start this new system, I restarted my device. After the obligatory first start configuration, I then had an equally functioning system as with my old FC34 but without further modifications to any userspace component. Hence my claim: with current pure mainline userspace releases you can have out-of-the-box support. Unfortunately, I can't say to what extent this experience can be transferred to Debian and its derivatives. It depends on the releases it currently carries. The firmware and kernel will still need some out of tree components for a while, but this is easy to handle. And I am sure that one or the other userspace program sooner or later will also be rebuilt with some patches for early adaptation of new features. Development will never end.

Maybe this approach can serve as a poorman solution until a real solution is available: Create your kernel packages of the same variant in separate directories. In any case, the directory name must be different from the ${kernelversion} component. Now create a sym link whose name corresponds to the ${kernelversion} component and which points to a kernel package directory. With a single boot stanza in extlinux.conf for the ${kernelversion}, the kernel can now be booted and the kernel can find its associated modules to load. With a simple change of the sym link you can now change the kernel package used. Although you lose the possibility to decide at boot which kernel package is used, this should not play a role in the planned access with ssh anyway.

This is a boot stanza that is set up for use with my kernel builds. They are generic mainline builds, i.e. they are suitable for all devices with aarch architecture for which sufficient mainline support is available. It is called "default" because a symbolic link (linux) pointing to ${kernelversion} controls which kernel is currently in use, and therefore no explicit name can be specified. Label naming has no functional consequences. If you had followed the instructions of the second important post (First step: prepare kernel package (copy files around)), you would have everything. This is necessary because the same file names cannot be hosted multiple times in /boot and would overwrite each other. Without uboot console access, you won't have a way to choose which kernel to boot with when booting. You will get always the one of the first bootable stanza. This will not work, you cannot change the ${kernelversion} component arbitrarily, because it is compiled into the kernel binary and is used, for example, for the localization of the modules to be loaded. Sorry, but here is a point reached where Armbian knowledge is required, which I do not have. Here you need to read the Armbian documentation or motivate an Armbian maintainer to help you.

Even better, 6.1.0. Browsers that are using the qt5-qtwebengine backend in a wayland environment (e.g. Falkon) are working flawless. The Qt Multimedia module uses the gstreamer framework and wayland uses proper KMS/DRM support.

The main problem with kernel.deb packages is that not all noteworthy kernel artifacts are included, but are generated by the installation routine. E.g. the initramfs or depmod results. If the system installation routine also removes other installed kernels from the system, this is not helpful. I therefore prefer the method of extracting the installed kernel artifacts from a full image. To do this, I loop-mount the image and then copy the components over to /usr/lib/modules/${kernelversion}. This procedure applies to all kernels that you want to install. With my method, a kernel installation consists of instantiating the /usr/lib/modules/${kernelversion} directory branch. To be able to make distro-boot aware of a new kernel, dublicate a boot stanza in extlinux.conf and adjust the ${kernelversion} part. The same concept as with grub. With this information, a boot stanza should look something like this:

It are basically two posts that matter. This to collect the necessary information for the implementation, and this to make the preparations on the basis of the collected information and to compile an extlinux.conf. Of course, you have to adjust the deviations from your system accordingly. The commands for the command-line are already given there.

Or convert to distro-boot with slightly customized kernel packages, as exercised here.

Multi-Gen LRU has just landed. In 6.1.0, the support can therefore be used out-of-the-box.