balbes150

NO !!!!!

Added version 20221012 with the current 5.19 kernel. I wonder how it will work on Helios 64.

After updating the bootloader from the image (legacy_4.19.193) . Check again the launch with this SD card, without changing anything on it (you do NOT need to start the update procedure). If after updating the bootloader, the system continues to start normally from the SD card with the image (legacy_4.19.193), then you have u-boot in SPI and the update will not help you in any way, you need to completely erase SPI at the beginning (disable startup from SPI). Only after that, the processor will switch to using the bootloader from eMMC and you will be able to update it and use the launch of any systems from external media (SD\USB).

1. I wrote about the "first fat section" - because I know for SURE (as the author of this image) that it is him (and why it is needed). 2. When creating an image, this section has the "boot" and "esp" flags, when removing the "boot" flag, the "esp" flag is automatically removed and "msftdata" is installed. At the moment, a bundle of u-boot + efi + grub is the best option for a universal image. As far as I know, only u-boot can provide global support for all devices (which we use), all other variants of startup systems, at best, have fragmentary support (on some type of hardware\platforms).

In the current state, the installation does not work correctly (there is no proper partition creation, there is no u-boot installation, etc.). I am currently working on a fix and will create a PR as testing progresses.

You have installed the old u-boot (which does not know how to work with other systems) in SPI. The fact that this u-boot is called "new" does not mean anything, in fact it is an old u-boot without support for launching other systems (except Firefly images, which use an outdated startup scheme). The solution of how to get rid of the old u-boot in SPI was described in this topic. https://forum.armbian.com/topic/18852-board-bring-up-station-p2-rk3568-m2-rk3566/?do=findComment&comment=136734

Tnx. Now I was only interested in the general launch of the system using EFI, you confirmed its operation. I am not checking the operation of the system (kernel) yet, perhaps additional patches \ settings for the kernel are needed, but this requires access to the hardware. By the way, you can disable UEFI mode and switch to using extlinux.conf, with which full output and control via UART should work. Remove the "boot" flags from the first FAT partition and the bootloader will stop using EFI. Or you can remove all files from the FAT partition.

What is connected to the HDMI output, is there a picture there? Judging by the log, the system is up and running.

Write in detail all the steps, the exact name of the image and what is displayed on the screen.

@ManoftheSeaCan you test running this image on your Helios 64 and Espressobin ? To run on Helios 64 - write the image to the SD card and try to run. For Espresso bin, you will need to make a small edit and use a USB flash drive for recording. This is an image with EFI\GRUB support. On rk3399 there should be a picture with a menu at startup with the option to select the system\kernel. If the output to the screen in u-boot works on the Espresso bar, there should also be a corresponding picture there. https://disk.yandex.ru/d/-8s9ffTWG6i1nw

Everything works fine in EFI mode. Do I understand correctly, you have Helios64 (rk3399) and Espressobin (marvel 370)?

Kernel (system) selection management has been working for rk3399 for a long time. including automatic installation (updating) of the kernel by standard and simple means (apt\synaptic), as on ordinary PCs Which version of u-boot is used on Helios 64 ?

placing boot files (kernel\initrd\dtb\config, etc.) in the root system itself is very bad advice. all startup-critical files\config must be placed outside the root file system. what will you do when using an unsupported u-boot file system (not ext4\fat) , encrypted file sharing, or network hosting of a root system?

There is no access to the SD card in the log. Either the image was recorded incorrectly, or there are problems with the Sd card\card reader. Try to write the image to a USB flash drive and try starting from it (there is an appeal to USB in the logs).

I would formulate it differently, "optimization is performed as far as possible, but is not a top priority (due to lack of qualifications\time)" (this is my personal opinion)

Kernel 6.0 (mainline + patches) the details https://bbs.stationpc.com/forum.php?mod=redirect&goto=findpost&ptid=323&pid=1190&fromuid=636914

ok

OK, I'll take a look at it myself and try to combine them and check how it will work. it lacks u-boot, so by default it will not be able to work on devices with "factory" firmware (where there is no SPI with an already built-in EFI-enabled bootloader) Jetson nano has SPI with EFI support, so it's easy to experiment with it, for the vast majority of RK - you need an additional u-boot when writing to the media (earlier I wrote to you how to implement it as a separate bootloader file to overlay on the image) There are several problems related to this. There are several solutions, I checked different ones and came to the conclusion that the optimal solution is to bind the name of the DTB used to u-boot, the current implementations of the EFI startup bundle are able to use this for ARM.

What kind of core are we talking about ? is it about the general arm-efi image? I do not propose to transfer everything at once, the process can go slowly, with detailed testing. I have outlined the prospects only for my models it also plays a very significant role there is no DTB on x86, there is no u-boot, but there are specifics of installing several systems together (Windows + several Linux, etc.), this significantly changes the logic of the installation process and mixing their analysis into one script creates unnecessary problems that are easily solved when splitting. Even the logic of GRUB is different on x86 and ARM. By the way, for proper operation (image assembly) with EFI support for ARM, the grub extension is available.sh is not suitable, I am using a modified version. I suggest going smoothly, slowly, debugging and testing individual steps. Therefore, the best option is to leave the existing nand-sata-install installation script and create a separate version of armbian-install (with separate installation scripts for different architectures), this will make it much easier to conduct the development process when you do not need to track and test the changes being made on two platforms at once (there may be mutually exclusive fixes). And only after everything is working, it will be possible to smoothly start the process of unification.

I propose to divide the installer into several independent scripts that are optimized by architecture. An attempt to combine very different principles (x86 and ARM) in one nand-sata-install script will require the addition and maintenance of complex analysis algorithms. It's better to simplify it. In the main script, a primary analysis will be performed on which architecture the installation procedure is running, according to the result, one of the necessary scripts is selected (x86-install arm-install, etc.). And these scripts will describe only the necessary procedures for these architectures, taking into account their features. For example, on ARM, in principle, there can be no partitions with Windows, and other differences. https://github.com/armbian/build/pull/4227

jetson Nano does not require installation, I tested it in EFI\Grub mode - everything works (with EFI fixes to build the image), in the near future I plan to send a PR with the transfer of jetson Nano to EFI mode. also, almost all my supported devices work well in EFI mode, they only lacked the installation mode with EFI, if you finalize the installation, all images can be transferred to one universal image (by drastically reducing the count. image variants collected and posted on the site).

I am interested to look at this utility (is it a copy of our DDBR utility, which they give out for their development). As part of Armbian, the DDBR utility has been used for a long time, which performs the creation of a full backup (and recovery) of the entire eMMC "as is".

You have several solutions. 1. do everything you need yourself (add\fix support for b00 in the kernel). 2. Contact NVIDIA representatives so that they do everything necessary. 3. Provide yourself or negotiate with NVIDIA so that they provide the necessary equipment\finance to Armbian developers.

if there is a financial opportunity, it is reasonable.

if everything works, debugging is no longer needed, then the patch has fixed the startup problem.