balbes150

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.

Version 20230103-EDK2-edge with kernel 6.2. The launch procedure is the same - burn images to two media SD card and USB flash drive, connect both media at the same time and turn on the power. Management only via the UART console.

version 20230103-edge with kernel 6.2. running from an SD card works, but there is no USB and LAN, so there is little practical use yet. Added support for PCIe, the eth0 interface appeared, but the network does not see it. may need drivers or additional settings for DTB. A link to a working image with kernel 6.2, and DTB with eth0 enabled.

Ver 20221229-EFI-EDK2 kernel 6.2-rc1

Are you ready to pay for this work ?

For me, gnome = shit, I don't use it and have no idea what's wrong with it.