balbes150

What model are we talking about ?

Alpha version 20230122-EDK-EFI Armbian for SOQuartz + SOQuartz Model-A Baseboard. Kernel 6.2-rc4. https://disk.yandex.ru/d/Oq5yvBkuIK4R3A

In all my versions, output to the UART console is enabled, so if there are any problems with startup, you will be able to see at what stage the problem is. If you did not write anything to SPI and there are no radxa loaders (in which the UART output is disabled), then you have a power problem. The right steps : - boot the latest Armbian image from SD then use it program select a menu item SPI + NVMe as provided for in the install procedure. - then shut down, remove the SD card, and power cycle, No manual DD operations to write the image to NVMe - UNNECESSARY. The installation script itself will write everything correctly on NVMe (the only condition is that a partition must be created on NVMe) It means that you already have an old version of the loader in SPI, which contains a number of errors.

Running u-boot-EFI uses DTBS, which are described in grub.cfg. There is an EDK2-EFI variant, it uses two variants - DTB or ACPI.

There is no longer support for OPI 800 in the media core. In theory, yes, but I don't have this equipment and I have no idea what it takes.

What do you want to update ?

The latest versions using EDK2 can now be downloaded from the link. https://users.armbian.com/balbes150/edk2/

The latest versions using EDK2 can now be downloaded from the link. https://users.armbian.com/balbes150/edk2/

The latest versions using EDK2 can now be downloaded from the link. https://users.armbian.com/balbes150/edk2/

Please check the launch of the latest versions 20230112-current (6.1.4) and 20230112-edge (6.2-rc3) on jetson Nano. I am interested in the general launch of the system from an SD card or USB flash drive.

+1 IMHO it is better to discuss general issues on the forum. Specifics on PR - on Github

This is for attaching the device itself to the wall or to the body of a large device (for example, a monitor, via a VESA mount) I think the rubber bands are glued and they can be carefully peeled off (I peeled off such rubber bands and nothing happened to them). If there is not enough regular glue when re-gluing, you can lubricate them with another glue and glue them with an offset from the attachment points, so that you can then easily have access to the fastening screws.

I have an M3 without a housing, but from experience from other Station M\ P - screws under elastic bands. Possibly under a hexagon.

You don't believe anyone. Only your personal experience and your own verification. IMHO during assembly, patches should not be processed in any way at all, only "dumb application as is".

If I understood your thought correctly. Creating source packages doesn't make sense. The build system itself is "the sources for all packages, the kernel, the loader, and so on." Therefore, it makes no sense to duplicate this work. Our task is to prepare the source code (get the right version of the source code, apply patches, form a configuration, etc.) and assemble a ready-made binary package. If use a classic scheme with a source package, it will require the user to come to the same set of complex steps (installing the necessary packages for build, configuring them correctly, etc.), which will kill the main trump card of the Armbioan assembly system - ease of use for the average user. I performed a few simple steps and got the result (my kernel, bootloader, etc.).

We are talking about the kernel (DEB package with the kernel), which is installed in the image during build. Or do you propose to build only ROOTFS in this system ? IMHO this is the wrong approach. We are not building a source package, we are building a ready-made kernel and packaging it correctly in DEB. Sorry, I can't get into jira, if it suits me, I can create a question in GIT. It suits me (joke). Again, forget about my messages, I no longer comment on my tests with NEXT, I will solve everything necessary myself.

I decided to look at the log, on the subject of how patches were applied, how the kernel assembly went. Wow ... I haven't seen such shit yet, an absolutely useless log. By the way, one file, the size of megabytes, and to find something in it, you need to spend a lot of time. At the same time, some of the patches did not even apply, but the build system reported to me with cheerful green lines that everything was fine, the core was assembled as needed.

I suggest by default (without manual activation) - direct all the activity of the build system to the screen (to the build console \ SSH) . Only the basic steps should be recorded in the log (approximately as it is done now to control the overall assembly process). This will significantly relieve the input/output system from useless resource consumption (recording time, media resources, etc.). I compared the assembly process of the same on the Master and NEXT versions. The device is the same (4OZU\32eMMC), the system is the same clean installation). The difference reaches 20-30% in time. I think the reason is that NEXT devours a lot of resources for logging (with small RAM, intensive swap of all operations). The funny thing is that the user does not see any progress on the screen (by the way, this may cause a feeling that the system is frozen), but there is an active write / read inside. Logs should be included as a separate option and preferably with a depth level setting (approximately, as it is set at the start of the kernel, the degree of intensity of data output to the log). It's about the correct setup, what to install (which tools) and not to clog the system with junk unrelated to this option assembly. Now this is implemented in MASTER, do not load cross compilers if the native assembly is running. Install compiler packages strictly for the architecture on which the process is running for the version that is being built. For example, I have now started building only the kernel for P2. The system is 3.3 GB, a clean system, only cloned GIT NEXT, before starting the build process. After completion, 16 GB is occupied. Even taking into account the source code of the kernel and u-boot (and compiled objects) - too much for the simplest build system, almost 12 GB only for "servicing" libraries and compilers.

I'm shocked at what the build system is turning into. Due to the very poor work of logging, the load on the input/output system jumped by 40% (this is an idiotic recording of useless information in a bunch of files), while important information was no longer displayed on the screen (the process of applying kernel patches, u-boot, etc.). If you don't know how best to keep logs, completely disable them in the default state (when the system is cloned by a regular user and runs a simple build). Logs are enabled exclusively and only through a variable that needs to be changed manually or added to the build command line. Again , a bunch of useless junk is being dragged - a compiler for riscv . cross compilers (with native build), shit with pete (DEV stuff that is not needed at all for the build system, standard BASH is enough).

Version 20230103-edge with kernel 6.2. LAN works and you can control the system via SSH. and version 20230103-EDK2-edge. kernel 6.2. the order of launching the EDK2 version is the same - you need to write the image to two media (SD card and USB flash drive) and use them simultaneously.

A test version of Armbian images to run from NVMe without having to write the curve of the official u-boot version to SPI (which breaks the launch of other systems from SD cards and other media). The whole system works completely with NVMe . https://disk.yandex.ru/d/V5AxXNN2yJnOfg The installation of the system on NVMe and u-boot in SPI was checked using the standard tools of the armbian-config utility. Everything works correctly. Also in this new u-boot, the ability to start the system in EFI mode is available. To install a system with EFI\grub on NVMe. Install a new bootloader in SPI. Start the system from the SD card and burn the system image with the EFI\grub DD utility to NVMe. images with EFI\grub support are located in directories with the extension "EFI"

Test version of the Armbian+EDK2 system (UEFI\grub) is available. The system startup control is performed as on a regular PC - through the menu on the monitor screen, therefore, to fully use all the features of selective startup, you need to have a connected monitor and keyboard To use this option. Download the EDK2 image. https://users.armbian.com/balbes150/edk2/ https://disk.yandex.ru/d/kK6KIqHShRHLyw Unpack and burn to SD card. Download the Armbian image (kernel 6.1.0-rc7), For Station M2 https://disk.yandex.ru/d/C4Ql9v0BvhKPjQ For Station P2 https://disk.yandex.ru/d/5XuGz9WgF7FGCg unpack and burn it to a USB drive (8-16GB flash drives are recommended, I haven't checked other options). Connect the SD card and USB drive. Turn on the power. If the system does not start immediately, go to settings and select the device to start. On the EDK2 boot screen, select "Maintaining Manager boot" in the menu item and configure the device used for startup in it (change "none" to "UEFI ...."). Select Reset. If you did everything correctly, after restarting EDK2, you will receive a GRUB menu with a choice of system\kernel. If you do not select anything, the default system will be started in 5 seconds, and in 10-20 seconds (depending on the type of USB flash drive) there will be a standard Armbian customizer for the first launch. If desired, you can place the entire system on an SD card, but additional steps will be required at startup. At startup, the kernel switches the UART console to the correct value for RK (1500000) and you can monitor the kernel startup process and control the system through the UART console. That is, the parameters 115200 can only be useful for viewing the primary output from EDK2 itself, but this is only necessary for developers, for ordinary users, kernel output and system management are more useful, so I recommend using the standard value for Rockchip of 150000. https://github.com/150balbes/edk2_uefi

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

The first version of Armbian images for Station M3 rk3588s (rk3588s-roc-pc) is available. the launch is very simple - download, unpack, burn to an SD card, connect to the device and turn on the power. The system starts automatically. At the first launch, perform the initial setup in the same way as all Armbian-enabled devices. https://disk.yandex.ru/d/-zSW21XKN0pfIA

Added alpha version of image build support for RISC-V. So far, this is an early version and some of the functions do not work in it. Currently, support has been added for the StarFive model. https://rvspace.org/ Details can be seen in this topic. https://forum.rvspace.org/t/armbian-for-starfive-build-system-ubuntu-debian/468 Added support for Nezha D1 and Lichee RV (Dock) with Allwinner D1 RISC-V chip. To start the system. Download the image, unpack it, burn it to the SD card. Connect the SD card to the device and turn on the power. Further steps for initial setup are similar for all Armbian systems. For the Nezha D1 model, HDMI, LAN, USB, analog audio via 3.5 jack works. For Lichee RV Dock works HDMI WiFi USB USB-LAN Link to download images. https://disk.yandex.ru/d/da8qJ8wyE1hhcQ https://www.cnx-software.com/2021/12/30/sipeed-lichee-rv-risc-v-module-gets-5-carrier-board-with-hdmi-and-usb-ports-optional-wifi/ forum MangoPI https://forum.mangopi.org/