balbes150

I'll think about what I can do.

I don't understand, what is there to explain? See the error, make corrections (makes a patch) and check in the work.

Version 20221019 works VGA HDMI video output, LAN, Wi Fi, analog sound, HDMI sound.

It can be fixed, but the question is, who will check the result?

Alpha version of Armbian images for OrangePi 800. https://disk.yandex.ru/d/3Xta87KhFem-Bw

NVMe support is only available in legacy, SATA all image

Tnx

As ROOT

Run gparted (in a running Armbian on P2), create an MBR partition table and create a partition for the entire NVMe with ext4. And after that - reboot the system and launch nan-sata-install.

Exactly the opposite. This is the universal image, it is used without changes or additional settings. i.e. we do not change the image itself in any way. Adding a loader is not always required and does not change the "universal essence" of the image. If the device already has (from the factory or a one-time bootloader update/replacement procedure was performed to bring it to the standard procedure for launching universal images), then the universal image is used "as is" immediately after writing to the media, this is clearly visible when using USB media. I can use the same media without reconfiguration on dozens of different models with the same architecture (RK+AW+etc). The main thing is that the kernel has everything necessary for specific models (DTB drivers, etc.) You're wrong. EFI code is architecture-bound. The binary files for each architecture are different. But the settings files can be shared. https://github.com/150balbes/build/blob/armbian-tv/extensions/grub.sh#L37 https://github.com/150balbes/build/blob/risc-v/extensions/grub-riscv64.sh#L25 There is. More precisely, earlier I used a universal core (RK+AW+AML+ NVIDIA and other platforms can be added) and if desired, you can return to this option again. I just removed the "versatility" and limited myself to two platforms - RK+NVIDIA, because it makes no sense to spend resources on maintaining \assembling such an option if it is not used by additional platforms.

Before using (installing using nand-sata-install) the system, the NVMe module must be prepared, create a partition table and one partition on it.

How do you imagine writing a lot of different data into the same sectors\bits? no, the desired loader option is recorded (immediately after recording the image), specific for a specific model. To launch from USB, it is assumed that any system has already been installed on the device (or u-boot update), with support for the necessary changes in u-boot for direct launch from USB, or there is a factory u-boot with support for direct launch from USB. The option that you describe (an attempt to place and USE many loaders on the same media at once) is basically impossible. Initially (during assembly), the universal image does not have any loaders at all in the sectors where they are usually placed. Adding the desired version (for a specific model) is already performed by users, when preparing \ recording the image to the media (sequential recording - the universal image is recorded first and the loader is recorded immediately on top of it). By the way, I understand that you have not tried to run the images to which I gave a link in this topic for Helios64? (it's better to run it once and see how it works) This is the main thing that interested me in this image. I have no task to provide full support for all functions with the new kernel (this is not possible without hardware, I do not have Helios64 for such procedures). The reason is the lack of patches for Helios 64 in my EDGE kernel (I do not know what is needed there).

You have to create these patches yourself (study the design, drivers, DTS and create the necessary fixes).

Version 20221013 with kernel 6.0.1. First of all, I am interested in how the UART console works in EFI mode. On my models (Firefly\Station) - it works well and I can control the selection of the system\core both on the TV screen (via USB keyboard) and via the UART console (if there is nothing connected to HDMI). By the way, I am also interested in installing multiple cores and the ability to choose (only the cores of the media-curren and media-edge versions are suitable for this)

Add the necessary patches and build a new kernel.

at this stage, I am interested in a conceptual check of the general possibility of using the resulting images (including on marvel equipment) in order to work out the basic parameters \ principles that need to be used for a universal image. in the future, you can use any installation/ startup algorithms and optimize them for any tasks (installation and easy use of different cores or systems, with an easy choice of what you need at startup, as on a regular PC, etc.). I'll tell you the "secret" for a long time (several years) I have been using several systems on different devices at the same time (Ubuntu\Debian\Altlinux\Libreelec), which still have several kernel variants installed, and I choose the right system banally, through the keyboard, as on a regular PC or from the UART console. By the way, many years ago I released multi-system (eMMC hosted several Android\Linux\Libreelec systems at once) versions for khadassevitch with AML chips and users could easily choose which system to run. And for Rk and AW, this is a simple task. You're wrong Even in this case, you can have one universal image, but you need to change the algorithm of its use by users somewhat (another step is added when writing the image to the SD card), after recording the image, the bootloader image file for a specific model is also recorded on the same medium. I've been using this option for a long time and it works great.

judging by the log, there may not be enough files \ settings for network cards to work. without access to real hardware, it is not possible to search for and fix these problems. if desired, you can use my GIT and create new versions of images yourself (add the necessary components\files to the reset system settings) and solve this problem. you can use Helios64 itself to build the system from an SD card or USB drive, so as not to interfere with the system on eMMC. and according to the results (when you get the solution), send the PR to the official GIT Armbian.

This is an easily solved problem. Which device model (chip) do you want to use to test different kernel ? Not anymore. When using extlinux.conf or efi\grub, you can install and use an unlimited number of cores (limited only by free space for placement). The choice of which kernel (or even a completely different system) can be made in two ways, either on the screen via the keyboard (if u-boot has support for this), or via the UART console (this works on any model).

I have no idea how the users did it. I have already killed one instance of M2 (no P2) by experimenting with the u-boot loader. Firefly sent me a replacement, but I don't think they will regularly replace equipment that I may break during experiments. You can ask the manufacturer for recommendations (instructions) on how to completely erase u-boot from SPI. Or for them to fix their version of u-boot SPI for p2 and it immediately had support for launching from external media of any system. On the new m2 instance, a new u-boot is already in use, which does not require an update. Therefore, the manufacturer has fixed u-boot for M2 and similarly it can fix u-boot for P2. Or you send me an additional sample of P2, on which I will experiment and create a new u-boot for SPI on P2.

At the moment, nand-sata-install (absolutely in all versions of Armbian) is not designed to work (update\clean, etc.) SPI content on Station models. I don't test this function (I don't want to risk killing my instance with such experiments). You can contact the manufacturer to give recommendations on how to do this and check which version of u-boot from Armbian images can be used to write to SPI.

You cannot use nand-sata-install to update SPI (this mode has never been tested and is potentially very dangerous. You risk getting a big problem, because u-boot in Armbian is not designed for SPI (this possibility has not been tested).

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).