MX_Master
-
Posts
42 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by MX_Master
-
-
Try any gpio lib with pull up/down features included. For example:
https://github.com/rm-hull/OPi.GPIO
Pulling usage examples are here
https://opi-gpio.readthedocs.io/en/latest/api-documentation.html
-
Pull up or pull down the pin using built-in 50k resistors. And compare the results.
-
See the a/arch/arm64/Kconfig section and compare it with other popular platforms
lsdiff patch-5.4.22-rt13.patch | grep x86 filterdiff -i a/arch/x86/Kconfig patch-5.4.22-rt13.patch lsdiff patch-5.4.22-rt13.patch | grep arm64 filterdiff -i a/arch/arm64/Kconfig patch-5.4.22-rt13.patch
-
There's no PREEMPT_RT option for the arm64 inside patch-5.4.22-rt13.patch
-
16 hours ago, Evtihij said:
No radiator.
If you want to use a 'big' apps like Chromium, setup a proper cooling for the board
-
Какой блок питания используется? Достаточно ли он мощный (5v, 2a)? Какое охлаждение у платы? Радиатор на процессоре есть?
-
Armbian image version? Chromium error logs?
Версию системы, версию ядра, и прочие логи в студию
-
More tests results is here
Using same desktop image (v20.02.1 buster). But this time with old kernel v4.19.38 from here https://apt.armbian.com/pool/main/l/linux-4.19.38-sunxi/. Same steps as before were made. And performance results are the same! 
I think the problem can be with armsoc+X11 pair. To prove that fact I installed an old package xserver-xorg-video-armsoc-sun4i instead of building it from the sources. Performance became very very low.
-
Your truth
I forgot to `apt update` first. My bad. Thanks
-
https://dl.armbian.com/orangepipc/archive/
Armbian_20.02.1_Orangepipc_buster_current_5.4.20_desktop.7z
Just checked a fresh buster desktop image. And found a tiny issue. If you will try to install linux-headers-current-sunxi using the latest v20.02.1 image (buster, K5.4.20), you will get the v5.3.9 headers
It would be nice to get the v5.4.20 headers instead
Quick tip for other users - headers package can be found here - https://apt.armbian.com/pool/main/l/linux-5.4.20-sunxi/
-
Big respect
waiting for news
-
Just made a fullscreen test with glmark2 and the results are
glmark2-es2 --fullscreen ======================================================= glmark2 2017.07 ======================================================= OpenGL Information GL_VENDOR: ARM GL_RENDERER: Mali-400 MP GL_VERSION: OpenGL ES 2.0 ======================================================= [build] use-vbo=false: FPS: 10 FrameTime: 100.000 ms [build] use-vbo=true: FPS: 14 FrameTime: 71.429 ms [texture] texture-filter=nearest: FPS: 16 FrameTime: 62.500 ms [texture] texture-filter=linear: FPS: 15 FrameTime: 66.667 ms [texture] texture-filter=mipmap: FPS: 14 FrameTime: 71.429 ms [shading] shading=gouraud: FPS: 10 FrameTime: 100.000 ms [shading] shading=blinn-phong-inf: FPS: 9 FrameTime: 111.111 ms [shading] shading=phong: FPS: 10 FrameTime: 100.000 ms [shading] shading=cel: FPS: 7 FrameTime: 142.857 ms [bump] bump-render=high-poly: FPS: 7 FrameTime: 142.857 ms [bump] bump-render=normals: FPS: 14 FrameTime: 71.429 ms [bump] bump-render=height: FPS: 11 FrameTime: 90.909 ms [effect2d] kernel=0,1,0;1,-4,1;0,1,0;: FPS: 7 FrameTime: 142.857 ms [effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: 7 FrameTime: 142.857 ms [pulsar] light=false:quads=5:texture=false: FPS: 15 FrameTime: 66.667 ms [desktop] blur-radius=5:effect=blur:passes=1:separable=true:windows=4: FPS: 3 FrameTime: 333.333 ms [desktop] effect=shadow:windows=4: FPS: 10 FrameTime: 100.000 ms [buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 3 FrameTime: 333.333 ms [buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=subdata: FPS: 3 FrameTime: 333.333 ms [buffer] columns=200:interleave=true:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 3 FrameTime: 333.333 ms [ideas] speed=duration: FPS: 11 FrameTime: 90.909 ms [jellyfish] <default>: FPS: 7 FrameTime: 142.857 ms Error: SceneTerrain requires Vertex Texture Fetch support, but GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS is 0 [terrain] <default>: Unsupported [shadow] <default>: FPS: 7 FrameTime: 142.857 ms [refract] <default>: FPS: 6 FrameTime: 166.667 ms [conditionals] fragment-steps=0:vertex-steps=0: FPS: 15 FrameTime: 66.667 ms [conditionals] fragment-steps=5:vertex-steps=0: FPS: 6 FrameTime: 166.667 ms [conditionals] fragment-steps=0:vertex-steps=5: FPS: 14 FrameTime: 71.429 ms [function] fragment-complexity=low:fragment-steps=5: FPS: 10 FrameTime: 100.000 ms [function] fragment-complexity=medium:fragment-steps=5: FPS: 7 FrameTime: 142.857 ms [loop] fragment-loop=false:fragment-steps=5:vertex-steps=5: FPS: 10 FrameTime: 100.000 ms [loop] fragment-steps=5:fragment-uniform=false:vertex-steps=5: FPS: 10 FrameTime: 100.000 ms [loop] fragment-steps=5:fragment-uniform=true:vertex-steps=5: FPS: 10 FrameTime: 100.000 ms ======================================================= glmark2 Score: 9 =======================================================
I don't no, but performance is very low
OK, i got it, X11 + mali is totally bad idea.
It's time to test something with direct rendering to fbdev
-
OK, I will make some fullscreen tests and will show the results.
Also I heard about another installing method for the mali drivers/blobs. It's using ump cacher and libdri2 for direct rendering (without Xorg).
-
There are many use cases of r6p2 blobs a few years ago using kernel v4. 14. And all of them were pretty successful. Performance of es2gears was about 300fps. Software rendering can do only 100 fps on idle system.
So, I think, in my case something goes wrong. While running the es2gears, Xorg uses the 99% of CPU core. It's very abnormal for the hardware acceleration
-
8 hours ago, OpenglMan said:
And i add this sentence: KERNELBRANCH='tag:v5.4.19'
Remove this parameter and start a build script again. Armbian will use v5.4.18 (or v5.4.20). The patching process can throw a few errors. These tiny errors can be easily fixed by editing the RT patch or the kernel's sources.
-
Just tested the system using your X conf. And.. YES, I think the egl/gles `acceleration` is present. But any graphics processing is very very slow
es2gears is working, window has a transparent background and a performance about 20 FPS, Xorg process uses 99% of CPU.
es2_info is working, but it's output ends up with segmentation fault
EGL_VERSION: 1.4 Linux-r6p2-01rel0 EGL_VENDOR: ARM EGL_EXTENSIONS: EGL_KHR_image, EGL_KHR_image_base, EGL_KHR_image_pixmap, EGL_EXT_image_dma_buf_import, EGL_KHR_gl_texture_2D_image, EGL_KHR_gl_texture_cubemap_image, EGL_KHR_gl_renderbuffer_image, EGL_KHR_reusable_sync, EGL_KHR_fence_sync, EGL_KHR_swap_buffers_with_damage, EGL_EXT_swap_buffers_with_damage, EGL_KHR_lock_surface, EGL_KHR_lock_surface2, EGL_EXT_create_context_robustness, EGL_ANDROID_blob_cache, EGL_KHR_create_context, EGL_KHR_partial_update, EGL_KHR_create_context_no_error EGL_CLIENT_APIS: OpenGL_ES GL_VERSION: OpenGL ES 2.0 GL_RENDERER: Mali-400 MP GL_EXTENSIONS: GL_OES_texture_npot, GL_OES_vertex_array_object, GL_OES_compressed_ETC1_RGB8_texture, GL_EXT_compressed_ETC1_RGB8_sub_texture, GL_OES_standard_derivatives, GL_OES_EGL_image, GL_OES_depth24, GL_ARM_rgba8, GL_ARM_mali_shader_binary, GL_OES_depth_texture, GL_OES_packed_depth_stencil, GL_EXT_texture_format_BGRA8888, GL_OES_vertex_half_float, GL_EXT_blend_minmax, GL_OES_EGL_image_external, GL_OES_EGL_sync, GL_OES_rgb8_rgba8, GL_EXT_multisampled_render_to_texture, GL_EXT_discard_framebuffer, GL_OES_get_program_binary, GL_ARM_mali_program_binary, GL_EXT_shader_texture_lod, GL_EXT_robustness, GL_OES_depth_texture_cube_map, GL_KHR_debug, GL_ARM_shader_framebuffer_fetch, GL_ARM_shader_framebuffer_fetch_depth_stencil, GL_OES_mapbuffer, GL_KHR_no_error Segmentation fault
I think it's a good step in progress
but something is still missing in the system -
Xorg config is standard, by armbian - /etc/X11/xorg.conf.d/01-armbian-defaults.conf
Section "Monitor" Identifier "Monitor0" Option "DPMS" "false" EndSection Section "ServerFlags" Option "BlankTime" "0" Option "StandbyTime" "0" Option "SuspendTime" "0" Option "OffTime" "0" EndSection Section "Device" Identifier "Default Device" Driver "modesetting" Option "AccelMethod" "glamor" EndSection
May be this "Device" section is a source of my problem.
-
1 hour ago, hexdump said:
maybe build your own kernel with lima disabled (i'm not sure, but i think it might conflict with the old mali driver even if the module is not loaded) ... make sure you apply those two patches:
I'm using the image with sunxi-current kernel. And these patches are already there
But I'm sure I missing something
[ 22.263] (EE) modeset(0): eglGetDisplay() failed
May be some paths to EGL/GLES libs still incorrect
sudo ldconfig -p | grep -P "(EGL|GLES)" libGLESv2.so.2.0 (libc6,hard-float) => /usr/lib/mali/libGLESv2.so.2.0 libGLESv2.so.2 (libc6,hard-float) => /usr/lib/mali/libGLESv2.so.2 libGLESv2.so.2 (libc6,hard-float) => /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2 libGLESv2.so (libc6,hard-float) => /usr/lib/mali/libGLESv2.so libGLESv2.so (libc6,hard-float) => /usr/lib/arm-linux-gnueabihf/libGLESv2.so libGLESv1_CM.so.1.1 (libc6,hard-float) => /usr/lib/mali/libGLESv1_CM.so.1.1 libGLESv1_CM.so.1 (libc6,hard-float) => /usr/lib/mali/libGLESv1_CM.so.1 libGLESv1_CM.so.1 (libc6,hard-float) => /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so.1 libGLESv1_CM.so (libc6,hard-float) => /usr/lib/mali/libGLESv1_CM.so libGLESv1_CM.so (libc6,hard-float) => /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so libEGL_mesa.so.0 (libc6,hard-float) => /usr/lib/arm-linux-gnueabihf/libEGL_mesa.so.0 libEGL.so.1.4 (libc6,hard-float) => /usr/lib/mali/libEGL.so.1.4 libEGL.so.1 (libc6,hard-float) => /usr/lib/mali/libEGL.so.1 libEGL.so.1 (libc6,hard-float) => /usr/lib/arm-linux-gnueabihf/libEGL.so.1 libEGL.so (libc6,hard-float) => /usr/lib/mali/libEGL.so libEGL.so (libc6,hard-float) => /usr/lib/arm-linux-gnueabihf/libEGL.so
Interesting path is
libEGL_mesa.so.0 (libc6,hard-float) => /usr/lib/arm-linux-gnueabihf/libEGL_mesa.so.0
-
Thanks, guys. Just added these new steps to the list:
5. Granting access to the `/dev/mali` for the current user
sudo usermod -a -G video $USER touch 50-mali.rules echo 'KERNEL=="mali", MODE="0660", GROUP="video"' >> 50-mali.rules echo 'KERNEL=="mali0", MODE="0660", GROUP="video"' >> 50-mali.rules sudo mv 50-mali.rules /etc/udev/rules.d/50-mali.rules
6. Enabling the `armsoc` driver for the X server
sudo sed -i -e 's/modesetting/armsoc/' /etc/X11/xorg.conf.d/01-armbian-defaults.conf sudo sed -i -e 's/.*glamor.*//' /etc/X11/xorg.conf.d/01-armbian-defaults.conf sudo reboot
These steps were done successfully too. But.. still have no egl/gles HW acceleration
And this time, when I'm trying to use es2gears or es2_info, the X server immediately crashes. Interesting.. May be a few more components needs access rights to the /dev/mali and /usr/lib/mali/* too?
Xorg logs shows me some errors at the start. And there are no interesting info about Xorg crash.
..... [ 20.080] (==) Log file: "/var/log/Xorg.0.log", Time: Sun Feb 23 04:42:20 2020 [ 20.087] (==) Using config directory: "/etc/X11/xorg.conf.d" [ 20.087] (==) Using system config directory "/usr/share/X11/xorg.conf.d" [ 20.103] (==) No Layout section. Using the first Screen section. [ 20.103] (==) No screen section available. Using defaults. [ 20.103] (**) |-->Screen "Default Screen Section" (0) [ 20.103] (**) | |-->Monitor "<default monitor>" [ 20.104] (==) No device specified for screen "Default Screen Section". Using the first device section listed. [ 20.104] (**) | |-->Device "Default Device" [ 20.104] (**) | |-->GPUDevice "mali" [ 20.105] (==) No monitor specified for screen "Default Screen Section". Using a default monitor configuration. [ 20.105] (**) Option "BlankTime" "0" [ 20.105] (**) Option "StandbyTime" "0" [ 20.105] (**) Option "SuspendTime" "0" [ 20.105] (**) Option "OffTime" "0" [ 20.105] (==) Automatically adding devices [ 20.105] (==) Automatically enabling devices [ 20.105] (==) Automatically adding GPU devices ..... [ 20.118] (II) systemd-logind: logind integration requires -keeptty and -keeptty was not provided, disabling logind integration [ 20.122] (II) xfree86: Adding drm device (/dev/dri/card0) [ 20.127] (II) no primary bus or device found [ 20.128] falling back to /sys/devices/platform/display-engine/drm/card0 [ 20.128] (II) LoadModule: "glx" [ 20.139] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so [ 20.291] (II) Module glx: vendor="X.Org Foundation" [ 20.291] compiled for 1.20.4, module version = 1.0.0 [ 20.291] ABI class: X.Org Server Extension, version 10.0 [ 20.291] (II) LoadModule: "modesetting" [ 20.304] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so [ 20.313] (II) Module modesetting: vendor="X.Org Foundation" [ 20.314] compiled for 1.20.4, module version = 1.20.4 [ 20.314] Module class: X.Org Video Driver [ 20.314] ABI class: X.Org Video Driver, version 24.0 [ 20.314] (II) LoadModule: "armsoc" [ 20.325] (II) Loading /usr/lib/xorg/modules/drivers/armsoc_drv.so [ 20.352] (II) Module armsoc: vendor="X.Org Foundation" [ 20.352] compiled for 1.20.4, module version = 1.4.1 [ 20.352] Module class: X.Org Video Driver [ 20.352] ABI class: X.Org Video Driver, version 24.0 [ 20.352] (II) modesetting: Driver for Modesetting Kernel Drivers: kms [ 20.353] (II) ARMSOC: Driver for ARM Mali compatible chipsets [ 20.393] (II) modeset(0): using drv /dev/dri/card0 [ 20.394] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card support [ 20.394] (II) modeset(0): Creating default Display subsection in Screen section "Default Screen Section" for depth/fbbpp 24/32 [ 20.394] (==) modeset(0): Depth 24, (==) framebuffer bpp 32 [ 20.395] (**) modeset(0): Option "AccelMethod" "glamor" [ 20.395] (==) modeset(0): RGB weight 888 [ 20.395] (==) modeset(0): Default visual is TrueColor [ 20.395] (II) Loading sub module "glamoregl" [ 20.395] (II) LoadModule: "glamoregl" [ 20.407] (II) Loading /usr/lib/xorg/modules/libglamoregl.so [ 20.495] (II) Module glamoregl: vendor="X.Org Foundation" [ 20.495] compiled for 1.20.4, module version = 1.0.1 [ 20.496] ABI class: X.Org ANSI C Emulation, version 0.4 [ 22.263] (EE) modeset(0): eglGetDisplay() failed [ 22.271] (EE) modeset(0): glamor initialization failed ..... [ 22.694] (II) Loading sub module "fb" [ 22.694] (II) LoadModule: "fb" [ 22.695] (II) Loading /usr/lib/xorg/modules/libfb.so [ 22.703] (II) Module fb: vendor="X.Org Foundation" [ 22.703] compiled for 1.20.4, module version = 1.0.0 [ 22.703] ABI class: X.Org ANSI C Emulation, version 0.4 [ 22.703] (II) UnloadModule: "armsoc" [ 22.703] (II) Unloading armsoc .....
-
Hi, guys, I'm trying to install the mali driver to the latest armbian desktop image (20.02.1, debian buster, current, 5.4.20, x11, lima). My board is Orange Pi PC (H3). I have a good progress but still have a few questions.
The list of my successful steps:
1. Getting `mali` blobs
git clone https://github.com/bootlin/mali-blobs.git sudo mkdir /usr/lib/mali sudo cp -a mali-blobs/r6p2/arm/x11_dma_buf/lib* /usr/lib/mali/ sudo sed -i -e '1 s/^/\/usr\/lib\/mali\/\n/;' /etc/ld.so.conf sudo ldconfig
2. Blacklisting the `lima` driver
touch blacklist.conf echo "blacklist lima" >> blacklist.conf echo "blacklist gpu_sched" >> blacklist.conf sudo mv blacklist.conf /etc/modprobe.d/blacklist.conf sudo reboot
3. Building and installing `mali` driver
sudo apt-get install linux-headers-current-sunxi sudo apt-get install quilt xorg-dev xterm libudev-dev xutils-dev libtool sudo apt-get install mesa-utils mesa-utils-extra cmake git clone https://github.com/mripard/sunxi-mali cd sunxi-mali export CROSS_COMPILE=arm-linux-gnueabihf- export KDIR=/lib/modules/$(uname -r)/build ./build.sh -r r6p2 -b sudo mkdir /lib/modules/$(uname -r)/kernel/drivers/gpu/mali sudo cp mali.ko /lib/modules/$(uname -r)/kernel/drivers/gpu/mali/ cd .. sudo depmod sudo modprobe mali
4. Building and installing `xf86-video-armsoc`
git clone https://github.com/paolosabatino/xf86-video-armsoc cd xf86-video-armsoc autoreconf -vi ./configure --with-drmmode=sun4i make sudo make install sudo cp /usr/local/lib/xorg/modules/drivers/* /usr/lib/xorg/modules/drivers/ cd .. sudo reboot
These steps were done successfully. Of course, there are no egl/gles HW acceleration at this moment. es2_info and es2gears show me the "EGL init error" message. So.. what steps can I do next? Do I need some special settings for the X server?
-
2 hours ago, maxias said:
i've tried the machinekit distro from http://orange-cnc.ru/ its in russian by default so i had to change language first to try.
could you guys make a flashable IMG for the OrangePI ONE, im trying to implement a new CNC machine. The image form the russian webpage has very bad latency results. there is something written about a coprocessor that supports good stepping pulses but i dont understand whats ment.
i'm looking forward to use linuxcnc, because i think its just much better than MACH3. cheers
Try this one - https://github.com/orange-cnc/armbian_build/releases/tag/v2018.07.opi1
Image, based on Debian Jessie, has the best latency values. About 30-50 us.
orange-cnc - it's my free project, co-processor driver for the Machinekit has "work in progress" state
-
/etc/network/interfaces
# ... auto eth0 no-auto-down eth0 # ...
-
1 hour ago, kotc said:
@MX_Master: so, did you find what was off in armbian's uboot/kernel? because right now you are only sidestepping problem by loading via uboot
jernej is right. And your uboot config has the option
CONFIG_OLD_SUNXI_KERNEL_COMPAT=ythat is why you can edit the secure R_... registers from userspace loader in any mainline kernel.
-
8 hours ago, smaeul said:
You mentioned using the MSGBOX for communication. I've written drivers for both sides of the MSGBOX (Linux and ARISC)
Thanks, I will try your drivers soon
How to switch H6's ARISC (CPUS) core clock source? :)
in Beginners
Posted
I'm trying to use H6's ARISC (CPUS) core for my CNC project https://allwincnc.github.io/ There are no problems to switch ARISC (CPUS) clock source using H3 and H5 (latest Armbian Buster). I'm using R_PRCM (0x01F01400) > CPUS_CLK_REG (offset 0x0000) register to switch clock source to the PERIPH0 PLL. For the H3 I'm using uboot script, for the H5 - own kernel module.
But for the H6 this register (R_PRCM) isn't properly documented. Found out this register was moved to the 0x07010000. But modifying this register at offset 0x0000 doesn't take any effect. Just checked this using uboot cmd and own kernel module.
I need your help. guys. Any suggestions how to switch H6's ARISC (CPUS) clock to the PERIPH0 PLL? Is it possible this memory region is protected from uboot and linux kernel?