balbes150
-
Posts
4456 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Everything posted by balbes150
-
Why install something that is not needed???? The correct system check is to record a clean image and carry out all the steps strictly according to the initial instructions, on a completely clean \ new system.
-
IMHo - all these checks and the "problems" found in patches have no practical use. A practical test of applying a patch to the source code, with a detailed indication of exactly which part of the patch code is not applied. You can see an example in the Libreelec build system. There is a detailed patch overlay log and you can immediately see which piece of patch code is problematic. This is especially true for large patches with a large number of fix points in different places. Now there is a patch overlay log in the build log, and there is only scanty information there, which makes it difficult to understand where the problem is in patches, especially if there are many changes in one file.
-
Please note that these are packages that he is trying to install into the host system, i.e. these dependencies are written somewhere as mandatory for the host system where the build is launched. The assembly with GIT-Master works fine on the same host system, i.e. all the packages and dependencies necessary for the assembly system to work are already installed and the assembly works without problems. But the NEXT version is trying to install all this extra junk. You can easily reproduce it yourself. Take any ARM device (power and other parameters do not matter), run for example from SD\USB a ready-made Armbian Jammy image for this device and see what happens when you try to start building any image.
-
Checked the startup using system-boot. Two variants of u-boot with EFI support and EDK2-EFI. I took the original image from u-boot, which includes support for EFI, it is guaranteed to work and the system starts in EFI\grub mode without any problems. With the standard installation of additional kernel with the "apt install" command, the new kernel is automatically added to the grub startup list and works fine without any manual manipulations (I installed 4 kernel to check and checked their launch). Re-recorded launched this image. I uninstalled GRUB and installed system-boot ("bootctl install"), checked that the necessary files were created in the EFI partition and there were no errors during installation. Rebooted the system and ... the system does not start. Conducted similar check with EDK2-EFI. The result is similar, grub works fine and automatically adds the kernel during installation by standard means (without any manual manipulations), allows to select any kernel at startup and runs it perfectly. System-boot behavior with EDK2 - no startup works. I admit that if it takes a long and tedious tinkering with manual settings and commands, can make it work, but the question was about an easy installation by an ordinary user. I pay special attention to the fact that all additional cores are standard DEB packages (from network repositories) with the correct structure and content, which are perfectly installed by standard APT or SYNAPTIC modules without manual manipulation. By the way, I am currently testing the installation on rk3399\rk356x\rk3588 Armbian on eMMC\NVMe in EFI mode (u-boot and EDK2) and it works fine with GRUB.
-
I tried Jammy in Ubuntu - the package is missing. Further discussion does not make sense. P.S. Installing the kernel root system (kernel-install Balbes-ornery /usr/lib/linux/linux-6.1-balbes150 /usr/lib/linux/initrd) is very bad advice.
-
The system is a specific version of a full-fledged Armbian system (for example, Debian-22.11-XFCE, Ubuntu 22.08-server, etc.). The kernel is several versions of the kernel installed simultaneously (6.0.10 and 6.0.15 and 6.1.1). Which the user can choose independently at startup. I really want to see how system-boot will "guess" the thoughts of users, which version of the kernel (from the installed 2-3) needs to be launched at a given time. I work with Armbian and it is Armbian support that is being discussed here, so I am absolutely indifferent to "other distributions". Let their developers puzzle over how to work with them. Or are you suggesting that Armbian should pay out of pocket for fun for "other distributions"? "other distributions" too often use ready-made Armbian solutions and get money and bonuses for it. Which the user must manually configure. let "other distributions" deal with this masochism. show simple instructions for regular users for easy installation and automatic configuration for system-boot.
-
Version 20221224 is EDK2-EFI. EDK2-EFI\grub is used to run. Burn the image simultaneously to two media - an SD card and a USB flash drive.After recording, connect the SD card and USB flash drive at the same time. If you have a UART console, you can control the startup process.
-
How does it make it difficult to manage multiple systems\cores? On the contrary, a single control point, you add any number of systems, cores. The only limitation is that to use the selection, you need support for monitor output and USB for u-boot. For rk3399 - it is implemented. Everything written is wrong. grub does an excellent job with the AUTOMATIC (no manual manipulation needed) addition of a new kernel when installing it, supports all standard functions, as on regular PCs, and so on. excessively complex and poorly supported in Debian\Ubuntu systems, it is not widespread even on PCs.
-
I looked at the table by the link. I don't understand what practical use it is? "No description of mbox" - has no use. "rebase" - it is not clear why. the rest of the items are the same. does not do the main thing - does not check the error when using patches https://rpardini.github.io/linux/armbian-next-media-6.1-20221220.html
-
I tried armbian-next to run a native build (on an ARM device), and got errors. Why is a bunch of unnecessary shit being put on ARM (snap, gcc-riscv, etc.)? 👉] Reading package lists... [👉] Building dependency tree... [👉] Reading state information... [👉] Package ccze is not available, but is referred to by another package. [👉] This may mean that the package is missing, has been obsoleted, or [👉] is only available from another source [👉] Package python3-pip is not available, but is referred to by another package. [👉] This may mean that the package is missing, has been obsoleted, or [👉] is only available from another source [👉] Package distcc is not available, but is referred to by another package. [👉] This may mean that the package is missing, has been obsoleted, or [👉] is only available from another source [👉] No apt package "axel", but there is a snap with that name. [👉] Try "snap install axel" [👉] No apt package "tree", but there is a snap with that name. [👉] Try "snap install tree" [👉] E: Package 'distcc' has no installation candidate [👉] E: Package 'python3-pip' has no installation candidate [👉] E: Unable to locate package python2-dev [👉] E: Package 'ccze' has no installation candidate [👉] E: Unable to locate package colorized-logs [👉] E: Unable to locate package tree [👉] E: Unable to locate package pbzip2 [👉] E: Unable to locate package axel [👉] E: Unable to locate package crossbuild-essential-armel [👉] E: Unable to locate package crossbuild-essential-amd64 [👉] E: Unable to locate package gcc-riscv64-linux-gnu [👉] --> 🧽 78: 3365 - 3365 - 3365: hBE: trap: main_trap_handler [ ERR and 100 trap_manager_error_handled: short_stack:/home/user/armbian-build-next/lib/functions/logging/runners.sh:186 ] [💥] 👆👆👆 Showing logfile above 👆👆👆 [ /home/user/armbian-build-next/.tmp/logs-599221b8-4094-41cf-af68-4d18190ab396/004.000.prepare_host.log ] [💥] Error occurred in main shell [ code 100 at /home/user/armbian-build-next/lib/functions/logging/runners.sh:186 run_host_command_logged_raw() --> ./lib/functions/logging/runners.sh:186 run_host_command_logged() --> ./lib/functions/logging/runners.sh:169 host_apt_get() --> ./lib/functions/logging/runners.sh:139 host_apt_get_install() --> ./lib/functions/logging/runners.sh:132 install_host_side_packages() --> ./lib/functions/host/host-utils.sh:60 install_host_dependencies() --> ./lib/functions/host/prepare-host.sh:291 prepare_host() --> ./lib/functions/host/prepare-host.sh:111 do_with_logging() --> ./lib/functions/logging/logging.sh:112 main_default_build_single() --> ./lib/functions/main/default-build.sh:27 cli_standard_build_run() --> ./lib/functions/cli/cli-build.sh:16 armbian_cli_run_command() --> ./lib/functions/cli/utils-cli.sh:121 cli_entrypoint() --> ./lib/functions/cli/entrypoint.sh:154 main() --> ./compile.sh:52
-
Version 20221222 is EDK-EFI. The launch from USB media works (all ports work). The order of launching this version. Burn the same image to two media at once - an SD card and a USB flash drive. Connect both media SD card and USB flash drive and turn on the power. The system starts automatically from a USB flash drive (the SD card is used as a carrier for the EDK2-EFI\grub bootloader). If you have a UART console, you can control the process of starting and selecting the system\kernel. Please note that the system startup speed from USB can take up to 10-30 seconds (before the image appears on the monitor). Important. If the correct u-boot version is installed in SPI and there is a configured working system on NVMe, the new version of the system allows you to check the operation of the system in EDK2-EFI\grub mode from external media (SD+USB) without affecting the working system on NVMe.
-
No, initially there was an attempt to use the normal version (extlinux.conf) for rock 5b, but under the pressure of retrogrades, there was a rollback to this old stuff. Odroid is the stupidest choice and obsession with all sorts of old shit (boot.ini, piteboot). rk35xx (rk356x rk3588) - should initially focus on normal, new versions of startup systems (EFI\Grub). For rk356x - EDK2 has been available for a long time with a choice of system\kernel on the screen (for the headless option, this also works fine). For rk3588 - test versions are already available and in the coming weeks \ month there will be a working version with monitor support. With whom and what to discuss if retrogrades don't even understand how extlinux or efi\grub works and squeal at every corner that these are "very bad decisions"? At the same time, they do not understand elementary things - that switching at least to extlinux gives a huge step forward and allows you to atomize the installation of several cores at the same time (it is not necessary to make a choice of the core on the screen, it is important to keep the ability to easily roll back to the primary core if the new one has problems). Try using boot.scr to implement two\three\N cores installed in the system at the same time. When using boot.scr - updating the system\kernel, this is a lottery, with a high probability of getting a serious problem (strictly there is no kernel anymore. and the new one is not working).
-
Using boot.scr is initially a bad idea. This old junk has been "obsolete" for a long time and it's time to get rid of it. Changing boot.scr - you will not solve the problem, it is only a disguise laying a time bomb.
-
And now try to start the system from the SD card (imitation of problems with updating the kernel and you need a recovery system from an external media).
-
Using qemu to check the kernel - it shows nothing and has nothing to do with the actual operation of the kernel. such a "test" is useless. The source code from rpi is basically not suitable for Jetson Nano, so what you have compiled will not work on JN.
-
Test version 20221216-legacy for rk3399 (Station P1). The kernel 5.10.11 is used instead of 4.4. Some of the functions are not working yet. Switching to this version will get rid of a very outdated version of the BSP 4.4 kernel.
-
To update/install a new version of the loader in SPI, it does not matter which image (where the new version of the loader is used) you used (minimal or DE) from any version of Ubuntu or Debian. This is a one-time procedure. After that, you can use any system from the SD card or install it on NVMe. The only condition is the correct contents of the boot partition using extlinux.conf (without the old stuff with boot.scr and other things). Where have you seen such a condition ? Use the correct settings to run the kernel\system in the first boot partition, the size and number of other partitions are unlimited. Old and useless junk. use a normal system - extlinux.conf or edk2-efi\grub.
-
Are you sure your kernel is working at all? Show the output of the UART console with your kernel.
-
In order for you to have the correct u-boot in SPI. Follow the instructions from this topic exactly. The image from this theme is used, only it has the correct u-boot for SPI. Download, unpack, burn to SD card. Run on Rock 5b and execute the u-boot update command in SPI in armbian-config. No manual manipulation of files (download, copy, etc.) is needed. Everything you need is included in the image. don't do this nonsense anymore Measuring the speed of SPI is absolutely useless and will not give you anything useful. Remember - SPI is used for storing and loading only u-boot, not to be confused with booting the system (kernel). The size of the u-boot is only a few tens of kilobytes and it absolutely does not matter where it is launched from, it does not affect the boot speed of the system itself (the kernel) in any way. And placing the kernel on eMMC, instead of NVMe - this already significantly affects the boot time. eMMC memory is much slower than NVMe and it takes a lot of empty time to load the kernel from it. you can use eMMC to host the kernel only if the bootloader does not support direct startup of the entire system with NVMe. It won't work (or rather it will work very crookedly and badly) - because you are trying to use old shit (boot.scr), which work very poorly and contain a bunch of hidden problems. Which versions of SPI have you used, how did you install them on SPI? If you use the official versions of u-boot for SPI, they will not work correctly, there are too many bugs and errors in them. do not try to mount it and look for something in it, this part contains specially generated binary code.
-
Use the first section. Searches for the boot partition only on the first partition.
-
How did you determine that SPI is not working? Please note that the SPI recording process is very slow, it can take up to 5-7 minutes. After installing the system on NVMe, you need to confirm the replacement \ update of the SPI content, you must wait for the process to complete, when the system itself informs that the process is completed. I also pay attention if you have a u-boot on eMMC (left over from previous installations), it will be used to run. To make sure that SPI is working, disable eMMC or completely erase it with the DD utility (so that the remnants of the previous systems \ bootloader do not affect the startup process). If desired, you can use eMMC as an additional disk (create partitions on it and mount it into the system), but there should be no old u-boot on eMMC (which use the wrong order of starting systems). The SPI+NVMe variant will be the fastest than eMMC+NVMe. If you chose eMMC+NVMe, the kernel will be started from eMMC (reading the kernel, initrd. dtb), which is significantly slower than reading the same files from NVMe. What system are you using (full image name)? The HDMI sound is guaranteed to work in my builds. If this is the DE (XFCE) version, just launch the playback application and, with the application running, open the Volume Control sound Settings applet and select the device for audio output (analog output is enabled there by default). I don't understand what kind of Wi-Fi are we talking about? Are these the official versions from the Armbian website ?
-
This is normal for the first launch, during which a lot of primary settings (partition expansion, etc.) take place.
-
the manufacturer's use of a power supply with PD is a big stupidity Now, to solve this problem, have to use a regular power supply (12 or 20 volts) and a jack to USB-C adapter.
-
Describe your steps in detail. Which devices do you have connected - eMMC, NVMe? Have you recorded something in SPI before? The general procedure for installing the system on SPI+NVMe. If the eMMC module is connected, remove it, it is not needed to work in SPI+NVMe mode. Start the system from the SD card. Create a partition on the NVMe (if the NVMe is new, perhaps create an MBR partition table first). To create a partition, you can use gparted, which is convenient for graphical execution of steps. For example, you can create one partition for the entire NVMe with ext4. And only after that, run armbian-config and select the installation of SPI - NVMe\ SATA. Select the NVMe partition and start the installation. At the end, the system will ask you to update \ install the bootloader on SPI, confirm the choice and wait a few more minutes (the process of writing SPI is slow). If you do everything correctly, after turning off and removing the SD card, when you turn on the system will start with NVMe. Please note that armbian-conf (armbian-install) does not create partitions on NVMe, it uses existing ones, i.e. you must create a partition on NVMe yourself BEFORE starting the installation.
-
I'm just wondering which power supply do you use (with or without PD function)? What size of RAM do you have , is it correctly determined ? How does starting the system from an SD card work after installing the system on NVMe ?
