Jump to content

balbes150

Members
  • Posts

    4100
  • Joined

  • Last visited

Other groups

Contributor/Maintainer

Recent Profile Visitors

98555 profile views
  1. PWM causes kernel 6.1\6.2 to panic, so disabled
  2. Added images (kernel 6.2-rc5) from Gnome3. Surprisingly for me (I don't use gnome and built it at the user's request) the interface works well. Glmark2 shows 342 on Station P2. When running glmark2 on XFCE, I get 115-120. Video plays smoothly up to 1440p user@station-p2:~/Desktop$ glmark2 ======================================================= glmark2 2021.02 ======================================================= OpenGL Information GL_VENDOR: Panfrost GL_RENDERER: Mali-G52 r1 (Panfrost) GL_VERSION: 3.1 Mesa 22.0.5 ======================================================= [build] use-vbo=false: FPS: 337 FrameTime: 2.967 ms [build] use-vbo=true: FPS: 349 FrameTime: 2.865 ms [texture] texture-filter=nearest: FPS: 583 FrameTime: 1.715 ms [texture] texture-filter=linear: FPS: 589 FrameTime: 1.698 ms [texture] texture-filter=mipmap: FPS: 595 FrameTime: 1.681 ms [shading] shading=gouraud: FPS: 251 FrameTime: 3.984 ms [shading] shading=blinn-phong-inf: FPS: 252 FrameTime: 3.968 ms [shading] shading=phong: FPS: 244 FrameTime: 4.098 ms [shading] shading=cel: FPS: 249 FrameTime: 4.016 ms [bump] bump-render=high-poly: FPS: 101 FrameTime: 9.901 ms [bump] bump-render=normals: FPS: 662 FrameTime: 1.511 ms [bump] bump-render=height: FPS: 637 FrameTime: 1.570 ms [effect2d] kernel=0,1,0;1,-4,1;0,1,0;: FPS: 457 FrameTime: 2.188 ms [effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: 193 FrameTime: 5.181 ms [pulsar] light=false:quads=5:texture=false: FPS: 567 FrameTime: 1.764 ms [desktop] blur-radius=5:effect=blur:passes=1:separable=true:windows=4: FPS: 182 FrameTime: 5.495 ms [desktop] effect=shadow:windows=4: FPS: 526 FrameTime: 1.901 ms [buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 85 FrameTime: 11.765 ms [buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=subdata: FPS: 84 FrameTime: 11.905 ms [buffer] columns=200:interleave=true:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 72 FrameTime: 13.889 ms [ideas] speed=duration: FPS: 238 FrameTime: 4.202 ms [jellyfish] <default>: FPS: 286 FrameTime: 3.497 ms [terrain] <default>: FPS: 25 FrameTime: 40.000 ms [shadow] <default>: FPS: 166 FrameTime: 6.024 ms [refract] <default>: FPS: 26 FrameTime: 38.462 ms [conditionals] fragment-steps=0:vertex-steps=0: FPS: 445 FrameTime: 2.247 ms [conditionals] fragment-steps=5:vertex-steps=0: FPS: 442 FrameTime: 2.262 ms [conditionals] fragment-steps=0:vertex-steps=5: FPS: 445 FrameTime: 2.247 ms [function] fragment-complexity=low:fragment-steps=5: FPS: 446 FrameTime: 2.242 ms [function] fragment-complexity=medium:fragment-steps=5: FPS: 436 FrameTime: 2.294 ms [loop] fragment-loop=false:fragment-steps=5:vertex-steps=5: FPS: 444 FrameTime: 2.252 ms [loop] fragment-steps=5:fragment-uniform=false:vertex-steps=5: FPS: 443 FrameTime: 2.257 ms [loop] fragment-steps=5:fragment-uniform=true:vertex-steps=5: FPS: 438 FrameTime: 2.283 ms ======================================================= glmark2 Score: 342 =======================================================
  3. OK. I'll repeat it again with details. Armbian and Radxa images use essentially the same u-boot (in any case, this was the case at the time when I analyzed them). They are assembled from the same sources, so their behavior is the same. My u-boot is significantly different, it is a different source code and configuration, in which errors have been fixed and the configuration has been changed (UART is enabled, the startup order has been fixed, support for PD has been removed, etc.). Therefore, when using a power supply with PD, my version will not work. By the way, I recommend thinking about why radxa disabled the UART console in its u-boot. For the correct launch of my u-boot, you also need to completely erase the SPI, so that its "pieces" do not interfere with the correct launch of the new u-boot from the SD card. For reference, the primary loader (the first stage) is always launched in the strict order of SPI-eMMC-SD polling.
  4. Alpha version 20230124-edge Armbian for Quartz64-B Kernel 6.2-rc5. https://disk.yandex.ru/d/u0ioJbqtXqvJ6w
  5. I explained to you what the problem is and I absolutely don't care what you will use.
  6. 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.
  7. 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).
  8. 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).
  9. 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).
  10. 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.
  11. Full name and link to the Armbian image you are using.
  12. What model are we talking about ?
  13. Alpha version 20230122-EDK-EFI Armbian for SOQuartz + SOQuartz Model-A Baseboard. Kernel 6.2-rc4. https://disk.yandex.ru/d/Oq5yvBkuIK4R3A
  14. 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.
  15. 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.
×
×
  • Create New...