balbes150

They use an old crappy u-boot with UART disabled, incorrect startup order (when NVMe is connected with the system on it, startup from any other media is blocked), etc. If you are satisfied with this, use the official versions of the images. The very idea of using power supplies with PD is complete crap. And this was done by the stupidity of the developers of this device, they are trying to use USB-C, which has a very small thickness of contacts, and to transfer high power, they have to increase the voltage. If these idiots used a normal power connector (Jack 5\2.1mm) and a normal standard voltage value of 12V (or 24 for direct industrial use), this would save all users from the problems of idiotic solutions with PD. Because I use a full-fledged u-boot (starting from SD without disabling NVMe, with a UART console, the correct order of device selection, in the next version with support for launching from USB, etc.) without shit for PD approvals, and only normal power solutions (without PD) should be used with it.

Replace the DTB name in /boot//grub/grub.cfg with your model (I do not know which one is needed), you can try all the names in a row from the /dtb/nvidia directory. But if you use the wrong DTB, there is a chance of damage (if incorrect supply voltage values are set there).

Which power supply do you use ? Which version of u-boot did you write to SPI? Do not use PD power supplies, this is complete crap, for their proper operation requires the mandatory presence of a built-in battery (for the operation of the voltage matching stage).

I already wrote above, you have old shit in SPI. The only way to fix this is to disable NVMe physically, launch Armbian from the Sd card and overwrite SPI with a new bootloader. Only after that you connect NVMe back and start the system from the SD card and the correct installation is performed (re-start the system installation on NVMe + SPI).

These are the official versions, please contact the appropriate section with all questions. Modified versions are discussed in this topic, they differ from the official ones.

Full name and link to the Armbian image you are using.

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