usual user

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.

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.

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.

What do you think the one marked with the red circle is? Show me the how the CD ROM is attached to run an ISO.

No reason to regret, I do not expect any significant new development in the legacy firmware and there is therefore no need to rebuild it again and again. That was the reason why I appreciated your work, I could go the lazy way and take what you provided without having to build it myself. You can have it already with 6.0.0 with only a few backport patches. See here for reference. But 6.1.0-rc1 is only round about a week away. Out of curiosity I looked at your rk3568-odroid-m1.dtb. You still carry all the shortcomings and missing improvements that tobetter has not yet backported (like e.g. broken USB, missing SPI flash support, ...). with the posted "Add support for the Hardkernel ODROID-M1 board" series there is nothing left you need from tobetters tree. If you insist on using an outdated kernel version, all necessary backport patches can be inherited from the mainline tree. Generic mainline support is currently already more advanced than what the manufacturer offers.

You've removed the only part I used from your image, but don't worry, if the rumors come true that Rockchip is releasing ATF sources, I'll create my own firmware and replace petitboot completely. For 6.1.0-rc1 you only need this patch set for the board dts, everything else has landed. It also configures the hardkernel SPI flash partition layout, so fw_setenv is working for petitboot to set "skip_spiboot = false".

All outstanding DT patches just landed. Thus, the essential rk3568 SOC support is available out-of-the-box with the release of 6.1.0-rc1. With the exception, of course, of the board DT. The board manufacturer has no plans for mainline support in the near future. There are some efforts by the community to take the initiative, but this is only second-hand support. Only the board developer can be the authoritative source because only he knows all the details of the design. For proper mainline support, it is the obligation of the board designer to deliver a board DT as an absolute minimum requirement. Everything else can then be taken over by the community, because it is no longer board-specific and can benefit from similar development of similar boards. This fact is demonstrated with this SBC, although no mainline SOC support has been contributed by the board manufacturer, my desktop OS deployment works perfectly. For the time being, you have to provide your own board DT, wait for the community support to land in mainline and trickle down into distributions, or underpaid Armbian developers provide it for free.