usual user

https://github.com/robertojguerra/orangepi-zero-full-setup/blob/main/README2.md

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

This thread inspired me to tinker with GPIO again. I was curious to see how I would realize the example for myself. Since python is not my strong point, I chose a poor man's solution with "dnf install libgpiod-utils".
I then ran this command:
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 wondering now what the flashing code could say, but I think a ham radio operator would know for sure what it means 😉
Recreating the python example wasn't really challenging with:
gpioset -t1000 -Cblink-example con1-08=1 And besides, I find my flashing pattern much more interesting. I would be interested to know how something like this would be implemented with sysfs. Certainly not with a one-liner.
These commands work the same way on all my different devices, i.e. it is used for all pin 8 of the first expansion connector. I find it more pleasant to address the pins with con1-xx than to deal with some device-specific gpio-lines again and again. Generated code is therefore portable and can be used on any device without modification, provided that the device can provide GPIO functionality on the corresponding pins.
The only requirement is that the same gpio-line-name is used for the corresponding GPIO of the extension port. But this can be ensured by a simple DTB overlay. Creating such an overlay is a one-time effort for any device and the first thing I do for a device that I care off.

FWIW, I've moved to 6.7.0.rc2 and the mainline USB regression can no longer be observed:
/: Bus 08.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M /: Bus 07.Port 1: Dev 1, Class=root_hub, Driver=ohci-platform/1p, 12M |__ Port 1: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M |__ Port 1: Dev 2, If 1, Class=Human Interface Device, Driver=usbhid, 1.5M /: Bus 06.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 5000M |__ Port 4: Dev 3, If 0, Class=Mass Storage, Driver=usb-storage, 5000M /: Bus 05.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M |__ Port 1: Dev 5, If 0, Class=Vendor Specific Class, Driver=ftdi_sio, 12M |__ Port 2: Dev 6, If 0, Class=Vendor Specific Class, Driver=ftdi_sio, 12M /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=ohci-platform/1p, 12M /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=uas, 5000M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M But new toys in town to play with:
 

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.

Out of curiosity, are you interested in a little experiment? If so,
- prepare an entire cleared SD card (dd if=/dev/zero of=/dev/${entire-SD-card})
- dd the unpacked firmware (tar -xzf uboot-meson.tgz) that is uploaded here in place with:
dd bs=512 seek=1 conv=notrunc,fsync if=u-boot-meson.bin of=/dev/${entire-SD-card} - dd the unmodified Armbian_23.02.2_Odroidc4_jammy_current_6.1.11 image onto your USB 3.0 storage
- plug in the prepared SD card and your USB 3.0 storage into your odroid c4
- boot the odroid c4 and post the serial console log

You ignored the organization, a byte is 8 bit hence 512Mx4 x 4 chips = 1 Giga Byte. 

What does tmon tell about your thermal subsystem?

Not a missing package, it is the lack of basic support for V4L2-M2M hardware-accelerated video decode  in the application in the first place. The next showstopper would be the lack of V4L2-M2M support in the ffmpeg framework. There are some hack patches in the wild, but no out-of-the-box solution. The next showstopper would be the lack of kernel support for the SOC video decoder IP.
The lack of support in the application is a general problem for all devices that provide their decoders via V4L2-M2M. The lack of support in the ffmpeg framework is a problem for all applications that base on it. Gstreamer-based applications, on the other hand, offer out-of-the-box solutions, as the necessary support is already integrated into the mainline gstreamer framework.

Mainline DTB has proper thermal zone configuration. The kernel can manage its temperature management on its own, there is no need for an error-prone userspace component to be involved. As long as the kernel binary has build all the necessary drivers, it works out-of-the-box.

My first u-boot build:
 

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.

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.

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

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.

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.

I just used tobetter's tree at the beginning to learn what components are needed for the M1. But then very quickly I started to get the patches directly from the mailing lists (patchwork) to have the last improvements. I just made preparations to build my 6.1.0-rc1 kernel package with these out-of-tree patches next week:
If I'm not completely wrong, Armbinan also applies these patches in one way or another. But they are not M1 specific either. Now add this set and that's it. I didn't check it, but with "linux-0001-rockchip-from-6.1.patch" it should also work with 6.0.0 sources. There's a lot of unnecessary stuff in it, but with 6.1.0-rc1, the set is no longer necessary anyway.
When it comes to the .config, it becomes difficult, my kernel package is built as a generic kernel, i.e. one build for all supported devices of the same architecture. I'm happy to provide my .config, but it fluctuates a lot and is therefore a snapshot. For the M1 support I only changed four config options from "m" to "y" to get my personal preferences and additionally built the module for the SPI controller. Everything else is like I use it for all my other devices.
Board DTS is in flight.
With ATF and DT rebase mainline firmware gets closer.

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.

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.

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.

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.

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

I don't know Android and can't therefor help here, but I'm sure an experienced Android user can also use it to transfer an image to an sd card. However, if you are able to write an image to a USB flash drive, use a micro SD to USB adapter with a device whose system you are familiar with to write to an SD card. It is then the same procedure that you already know.

Mainline kernel has fairly compliant decoder support for rk3399, see fluster-run-nanopc-t4.log for reference. Only this patch set is yet missing for HEVC decoder support. Current gstreamer framework provides out-of-the-box support, FFMPEG framework still requires several pending patches that need to be applied for v4l2-request support.

YES!!  Boots just fine, resizes the partition, asks all the questions and I can log in and get root.  No failed systemd services and top is the top process in top.  Did an update and upgrade, rebooted, and it's fine.
 
Only thing is no blue light, at all.
 
Do I have to do all of this forever?