-
Posts
4456 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Everything posted by balbes150
-
@Erica I have read your information, but the problem is. that I don't have a working T4 instance for tests. I will try to make a new version of DTB in the coming days, but there are no guarantees that it will work.
-
I am currently busy preparing the release, all checks will be after the release.
- 188 replies
-
3
-
- MangoPi MQ Pro
- Sipeed Nezha
-
(and 1 more)
Tagged with:
-
Check this version to work with eDp. Don't change anything, just download, burn to SD card and check eDP operation. I need to figure out if this is going to work or not. https://disk.yandex.ru/d/cN0Nz8Y2RRBpfg
-
This command is enough to get information about the date of creation of the kernel and its version.
- 188 replies
-
1
-
- MangoPi MQ Pro
- Sipeed Nezha
-
(and 1 more)
Tagged with:
-
Specify the exact name of the image where there is support.
- 188 replies
-
2
-
- MangoPi MQ Pro
- Sipeed Nezha
-
(and 1 more)
Tagged with:
-
That's how it should be. While there is no startup interrupt mode (I haven't figured out how it works yet), you will be taken to the EFI menu atomically if there are problems with startup.
-
Is this when starting with eMMC ? Which ports is the keyboard connected to ?
-
I am not involved in panfork support. https://github.com/armbian/build/pull/4476#issuecomment-1330101529
-
Do you have an NVMe module ? It is advisable to check the system startup from all USB ports of the system with EDK2 (if Ubuntu is installed on eMMC, write it to a Debian USB flash drive or vice versa, so that it would be easier to determine which system is starting). After starting the system from USB, update the grub menu in the startup menu, the system on eMMC should appear and then check the selection and launch of systems with eMMC.
-
Ver 20230129-legacy - image gnome3 and kde5
-
Ver 20230128-EDK2-EFI for Quartz64-B Added EDK2-EFI support for Quartz64-B,
-
I checked KD5+wayland, it works well. The interface is fast, there are no freezes on the video when moving the mouse cursor, as on x11. Glmark2 showed more than 400 units. test images from KDE5 on the site.
- 8 replies
-
- Station M2
- Station P2
-
(and 1 more)
Tagged with:
-
In the coming days I plan to upload version with Gnome3
-
PWM causes kernel 6.1\6.2 to panic, so disabled
-
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 =======================================================
- 8 replies
-
- Station M2
- Station P2
-
(and 1 more)
Tagged with:
-
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.
-
Alpha version 20230124-edge Armbian for Quartz64-B Kernel 6.2-rc5. https://disk.yandex.ru/d/u0ioJbqtXqvJ6w
-
I explained to you what the problem is and I absolutely don't care what you will use.
-
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 ?