Jump to content

balbes150

Members
  • Posts

    4436
  • Joined

  • Last visited

Everything posted by balbes150

  1. 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.
  2. 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.
  3. 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.
  4. do not confuse the general testing process on a clean system and the installation of any unnecessary junk that is not needed for the selected specific image (platform) into one pile.
  5. Are you ready to pay for this work ?
  6. For me, gnome = shit, I don't use it and have no idea what's wrong with it.
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. 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.
  14. 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.
  15. 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
  16. 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
  17. 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.
  18. 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).
  19. 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.
  20. 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).
  21. 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.
  22. 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.
  23. 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.
  24. Are you sure your kernel is working at all? Show the output of the UART console with your kernel.
ร—
ร—
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines