usual user

Oh, sorry, I didn't notice the non-existent 6 and read it as Helios64. Of course, my description of the boot method is not limited to Rockchip devices; it works on all for which a mainline U-Boot is available. I have used it on iMX6, LX2160A and S922X devices, but my remaining devices are all based on Rockchip. The solutions are too varied to present a turnkey solution here. However, I am sure that only a corresponding configuration for implementation is required to achieve the desired behavior, but for that, the U-Boot documentation must be consulted to decide which solution should be chosen.

Since the RK3399 U-Boot can use an HDMI display and a USB keyboard, I would simply configure a jumpstart option in the boot flow that mounts a different root filesystem. When booting, you just have to select this option. If interacting with the firmware console is too complicated, the recovery system can be placed on a removable storage device. In this way, in case of need, only the rescue media needs to be connected and the system restarted; no firmware console access is required. A completely firmware-controlled fallback mechanism is also possible, but it requires further special configuration of the firmware. Read this thread to understand what I mean by my statement.

Everything you wish for here is achievable with pure U-Boot technology. A long time ago, I tried to practice how to realize this here in the forum, but my lesson from it was: You can't teach old dogs new tricks, and Armbian users want to celebrate their cargo cult and hope that it will magically fulfill their wishes.

If I have not researched incorrectly, the Rock Pi S0 has microSD, USB, and Ethernet to access external storage, but you have not provided any information about which options are available in your specific case.

To replace an image on the eMMC, the MASKROM mode is not necessary. It is only required when the firmware is so damaged that it no longer works, but the signature is still intact and the MASKROM code still executes it. To replace an image, it is sufficient to boot from a rootfs that is not on the eMMC and replace it from there. And the good thing about it is that no device-specific hacks are necessary, just a properly configured bootflow. Furthermore, it is also self-contained, as no external devices with special software or other dependencies are necessary. It can also be automated in such a way that it runs unattended and the user only has to start the process initially.

Then you know which part you can contribute to mainline support, otherwise you have to use the manufacturer's BSP, because that's what you paid for.

https://lore.kernel.org/lkml/20240220-rk3568-vicap-v9-0-ace1e5cc4a82@collabora.com/

IMHO this is a waste of money. In a device with NVME support, the advantages of an NVME SSD far outweigh those of an eMMC. The proprietary module interface also makes it difficult to use in other devices. And as a boot device for the firmware, it also offers no significant advantages over a microSD card. In any case, I would prefer a microSD card as a boot device, simply because of the easier handling when, for example, experimenting with the firmware. Only when everything works perfectly can one think about using an eMMC, but only if it is already permanently built into the device and the microSD card slot is to be kept free for other tasks. Only as long as there is no valid firmware signature in the SPI flash. Otherwise, firmware components will be loaded from there, and they may be able to load subsequent components (U-Boot) from other devices, but compatibility must be ensured. To avoid this, one must clean the SPI flash or store their own firmware in the SPI flash. However, since there is no way to fully test one's own firmware for functionality in advance, one may find oneself in a situation that requires a MASK-ROM recovery procedure. I prefer to trust the official documentation.

Maybe my firmware build can replace Petitboot?

Exactly Since I don't know the build, I can't make any concrete statements about it. It is also not possible under any circumstances, as the access procedures are far too complex to be meaningfully encoded in the MASK-ROM. As firmware devices, only SPI flash, MMC (eMMC, SD card), and USB with a proprietary protocol are available. This is correct. I just quickly built this version out of curiosity. I was just about to provide the binary artifacts when I quickly took a look at the schematic of your device. If I am not misinterpreting the schematic, your device only allows the fixed SPI-MMC-USB sequence and the forced immediate proprietary USB device. This means that you cannot execute the firmware completely from the microSD card, for example, if there is still a valid firmware signature in a device (SPI, eMMC) that is higher up in the priority list. It is therefore essential that you are familiar with the USB recovery procedure (MASK-ROM-MODE), in case something goes wrong during the firmware experiments with the higher prioritized devices (SPI, eMMC).

You are running with a broken firmware: Your version is also quite outdated: A current firmware log looks like this:

Just out of curiosity, you are trying to play content that is encoded in AV1. Are you sure that your device is equipped with an AV1 decoder IP and that the kernel has the appropriate driver?

FWIW rkvdec will be out of staging in 6.17 Be prepared to forward-port existing out-of-tree patches. cedrus has not seen much movement since a long time It can therefore be assumed that all necessary out-of-tree modifications from the past must be applied even with the latest kernel version. Since no mainline developments have taken place, no forward porting should be necessary.

It leaves the device with an intact file system. The corrupted file system structure has likely been restored by rolling back the journal during the automatic file system check of the unmounted file system at system startup. But the data loss is permanent. There is a reason why UPS systems exist.

I don't know your plans for how things are supposed to proceed. But if you plan to continue using my firmware build, I would suggest transferring it to the SPI flash, provided you are not wanted to use any other firmware in there. - This relieves you from having to pay attention to restoring my firmware build when changing an image. - You have two firmware versions available to you, between which you can switch with the SPI-MMC boot switch. - Even without the eMMC module, you can boot an OS from another connected storage device. - The U-Boot console is also available with an HDMI monitor and a USB keyboard and can be used for analysis in the event of startup problems. Of course, it is also used to select various boot options if autoboot is interrupted.