usual user

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.

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.

This is quite possible because your uboot is built with other features. E.g. you have no usbkbd support as can be seen from the coninfo output. You could have used nulldev, but bootdelay is even the better solution for your situation. Saved uboot environment is usually not cleared by a firmware update and yours is even maintained in SPI flash as can be seen by: Saving Environment to SPIFlash... Erasing SPI flash...Writing to SPI flash...done To reach the console again, I would use a completely deleted SD card (dd if=/dev/zero of=/dev/${entire-card-device-to-be-used}) and then install a firmware (dd bs=512 seek=64 conv=notrunc,fsync if=u-boot-rockchip.bin of=/dev/${entire-card-device-to-be-used}). If you boot with this prepared SD card and removed eMMC module, you should finally reach the console after all unsuccessful boot attempts. Be patient, there will be some. If you had used nulldev, this would not work, but deleting the SPI flash should definitely let the environment fall back to the uboot built-in default.

And off topic, after reading out of curiosity of u-boot-2022.07/doc/README.iomux, I would do this in my device's uboot console and forget about the build of uboot:

Sure, but mainline "make rock-pi-4-rk3399_defconfig" sets BOOTDELAY=2, so the Armbian build system has to cause this change. Maybe that's what you should be looking for: [ o.k. ] * [l][c] u-boot-rk3399-set-bootdelay.patch Sorry, but we have here reached a point where Armbian knowledge is required, which I do not have. You now need an Armbian maintainer to help you. You now know which uboot modification is necessary to fix your issue and if you do not find a solution to build uboot yourself you still have my firmware. As I can see from your script log, my version is even more up-to-date, but that doesn't really matter.

Not at all, I run fedora on all my SBCs and build on target. I simply built the 2022.07 RPM source version I had already handy. The source references should only serve to let you know what you have received from me. Which specific version is ultimately used is not really important. Not sure, but did you pulled in ATF properly, the BL31=.../bl31.elf clause of your referenced mainline documentation? But since we have proven that the BOOTDELAY setting is all you need, you can also use the Armbian version. From you previous rock-pi-4-rk3399_defconfig sniplet I see this: This is not present in the mainline sources, i.e. it is added by an Armbian patch. So you just have to locate the Armbian patch in the Armbian build system and replace 0 with -2 and you are ready to go.

These are special emmc devices and are read only by default, as can be seen in the RO column of the lsblk output. As far as I know, the rk3399 MASKROM code has no support to use them as a boot device, therefore useless in terms of a firmware location. My provided firmware is a build from this release tar ball. It pulls in the ATF binary build from this release tar ball and has only applied this modification:

Looks like you choose the wrong device name. The firmware area resides between MBR and the first partition. You probably used the boot partition and the original firmware remained intact. Therfor you have corrupted the data in the boot partition which has rewarded your original firmware with a boot failure. The desired device name is the one marked with type "disk" in an lsblk output. That's the entire device or raw device I've called entire-card-device-to-be-used because I don't know how your storage is connected and will show up. Example lsblk output:

Sorry, I'm confused what you're really doing. Before we sort this apart, let's do a quick test. I built a firmware for you and uploaded it here. Please download the archive and copy it unpacked into the firmware area of your SD card as follows: dd bs=512 seek=64 conv=notrunc,fsync if=u-boot-rockchip.bin of=/dev/${entire-card-device-to-be-used} This is doing what nand-sata-installer is doing behind the curtains. Please test and report if the boot process still stalls.

If the goal is to prevent the boot interruption, then maybe adding CONFIG_BOOTDELAY=-2 to rock-pi-4-rk3399_defconfig is what you're looking for.