usual user

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?

Damn, missed the rebase of the  "Draft: v4l2codecs: Implement VP9 v4l2 decoder" patches and the source branch has been deleted.
With gstreamer main branch as of 11.12.2021 I get this video-pipeline-vp9.pdf and everything is working as expected.
Just discovered how to gather some video playback statistics while playing online videos. I still don't know which backend is used, but since I can play e.g. three videos in parallel, I'm pretty sure the VPU will be used.
The eagle  has landed. \o/

I think I have to disappoint you, see here.

I have nothing to decide here, if you want it to be in Armbian you have to convince an Armbian maintainer to pick it up. I also use Armbian only very sporadically for board bring-up and initial tests. Nevertheless, when the release has taken place, I will build a uboot-tools package for me and can, if you wish, upload the firmware.
 
I use it to start my system from SD card or via USB connection. I don't see  any reason why it shouldn't work with eMMC, but you only know for sure if  you've tested it. For me it was the first action to replace Petitboot with  a mainline uboot.
You have to wait a little longer, see here.
Release v2022.07 has taken place and the uboot-tools package has been build. I am running the firmware from SPI flash and it is working flawless for me.
Since distro-boot is supported for free, the use of an extlinux.conf allows to select the current kernel, an previous one and a persistent one with the option to enable SPI flash for ODROID-N2 or ODROID-N2+. See the attached extlinux.conf as an example implementation.
More details can be extracted from this thread, with its distracting posts in between. It is possible to keep as many different kernels installed as persistent space is available. A kernel upgrade will never leave an unbootable system behind as long as a previously working one is still installed.
So if someone wants to experiment with u-boot-meson.bin, you have to let me know and I will upload the file.
extlinux.conf

The firmware (uboot) is loaded by the maskrom code in the safest and slowest mode to use only minimal eMMC requirements. When uboot takes over, an attempt  is made to switch to a more efficient mode. If this does not succeed, it can  lead to the observed behavior. Since I don't know if more recent uboot  versions have already fixed a possible problem, I had offered my v2022.07-rc2  build for a quick test. Unfortunately, in the other thread it looked like the maskrom code couldn't even read the firmware blobs and without console logs  it's not really to analyze. So if you want, try v2022.07-rc2 it's a simple:
dd bs=512 seek=1 conv=notrunc if=u-boot-meson.bin of=/dev/${entire-card-device-to-be-used} ; sync  

128MiB cma is probably not sufficient according to here:
 

The type of remote control does not matter as long as it operates near the 38kHz carrier frequency and a suitable rc_keymap.toml is loaded. The reason I used the RC-100 is because I'm using the SD card I originally set up for my NanoPC-T4, and there this remote was configured for rc-empty. Therefore, it worked out of the box.
Went on to 5.19.0-rc3. And with the Enable-JPEG-Encoder-on-RK3566-RK3568.patch, a JPEG encoder is also available (videoX-infos.log). MGLRU is also pulled in again but only to see if it does not cause regressions with Odroid M1.

@jock - little update: v12 of the patches is out - it is essentially v11 pus the above mentioned fixes and rebased for v5.19:
https://lore.kernel.org/lkml/20220614071650.206064-1-yuzhao@google.com/
https://patchwork.kernel.org/project/linux-mm/list/?series=650073
https://www.phoronix.com/scan.php?page=news_item&px=MGLRU-v12-For-Linux-5.19-rc
https://github.com/hexdump0815/kernel-extra-patches/tree/main/multi-gen-lru/v12
best wishes - hexdump

Ok, I went on to 5.19.0-rc1. I was able to skip a lot of mainline commits from tobetter's tree because they landed, and for the remaining WIP commits, I switched to more recent ones. Some of the WIP commits are already in staging and will land sooner or later.
For those who are interested, I have attached glmark2 logs. The performance is not yet overwhelming, only the basic functionalities have just landed. But the graphical desktop works pretty decently. So the fine-tuning season is open.
And with the hantro decoder wired up, hardware-accelerated video decoding of H.264 and VP8 works up to 1080p. See fluster-run.log for reference.
Went on to 5.19.0-rc2. And with the ir-receiver wired up, my RC-100 works out of the box.
Rant: Why doesn't editing allow spoilers to be created with sections of code?
glmark2-wayland-odroid-m1.logfluster-run.log

Ok here's a new version, 5.18-rc7 from tobetter's tree. Still very early days.
tobetter is doing a fantastic job this time around, keeping his tree rebased properly this time.
 
This version has working NVMe (!), panfrost somewhat works, some hangs when panfrost is used.
eMMC does NOT work in my experience, it hangs the machine if trying to use it. use SD card.
 
unzstd, burn to SD, boot either with or without holding the button. (it should NOT go into or through Petitboot either way, instead the SPL in SPI should find and boot uboot in the SD card, or with button boot all blobs from SD).
 
https://github.com/rpardini/armbian-release/releases/download/20220522c/Armbian_20220522c-rpardini_Odroidm1_jammy_edge_5.18.0.img.zst
 
(4.x stuff still does not have HDMI, I've no idea why, it's otherwise stable, but I won't post it here since most people just assume it does not work at all if HDMI does not work)

Now I would also like to dream:
When commissioning a new system, I imagine that I will be offered a menu at the first boot in which all configurations available for selection are displayed. Since the SBC can't read my mind, at least I hope so, I choose the one I want. The system then starts and performs its first boot routine. At the next start of the system I wish for a dedicated menu of my previously selected boot option.
 
I'll leave it up to you to explore what changes you think are necessary.
 
Nevertheless, let's see how I would approach the matter in my dream. First, I would create a numbered extlinux.conf for each configuration selection with the following naming scheme: extlinux.conf-xx  with xx=01, 02, ...
The initial extlinux.conf contains only the fail save boot options of the available configurations. In addition, I append a boot parameter of the following form to each append line: bootoption=xx with xx=01, 02, ...
Then I write a shell script that searches /proc/cmdline for bootoption= and then copies the corresponding extlinux.conf-xx to extlinux.conf depending on the value found. Now I make sure that the script is executed as part of the first boot routine, and my dream should come true.
Wait, do I have just developed a method how distro-boot can communicate to the running system which boot option for the successful boot has been used. Am I still dreaming now or is all this already really feasible?