balbes150

The procedure for finding and using the SPI - SD - eMMC bootloader. If you clear SPI and eMMC, the bootloader from the SD card should work. By the way, if you completely remove u-boot from SPI and eMMC, you can use two bootloader options to run from an SD card (and later install on eMMC) - the old 2017 or the new 2022. Important - The new u-boot-2022 is not compatible with StationOS, i.e. you will not be able to use it with Android (StationOS)

to support all hardware except DTB, it may be necessary to add changes to the kernel. The official versions of Firefly images are built on old kernels, their DTB cannot be directly used in the new (main) kernel, which is used in Armbian, manual porting must be performed. Without real hardware, this is an inefficient activity, so I can't add support for P1pro in Armbian. Solution options - you do all the work yourself and do PR to the build system, or Firefly should send me samples for work.

Version 20221024 kernel 5.19.16 fix analog sound add image kernel 6.0.3

Version 20221021 kernel 5.19.16

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