@lex

Members
  • Content Count

    414
  • Joined

  • Last visited

 Content Type 

Forums

Member Map

Store

Crowdfunding

Raffles

Applications

Everything posted by @lex

  1. @lex

    htop has strange "layout"

    Type in the console terminal and ssh terminal: echo $LANG You should see UTF-8 on both terminals, that will fix the problem. It is just configuration.
  2. @lex

    htop has strange "layout"

    htop was built without support for ncursessw (shared libraries for terminal handling (wide character support)). I realized that is not the problem, i found out if you run htop from ssh terminal and from a console terminal you get ASCII on one and UTF-8 on the other (or vice-versa) and both have UTF-8 support. Can you please check if you have the same behavior?
  3. @lex

    htop has strange "layout"

    Type in the shell: printf "This is ASCII representation:\n|\n\`\n\`-\nThis is UTF-8 representation:\n\xe2\x94\x82\n\xe2\x94\x9c\n\xe2\x94\x94\xe2\x94\x80\n" You should see this: This is ASCII representation: | ` `- This is UTF-8 representation: │ ├ └─ If you don't see the above representation, you should set UTF-8 for your language in Terminal.
  4. @lex

    NanoPI M4

    Yes, it does have the same issue. This harmless annoying warning message just halted my NanoPi M4 in a matter of 24 hrs in idle mode. Flooded 5 GB of data and kernel was stalled on next day. That's why i thought this info could help. I would not waste time on this issue, make sure you disable wlan completely and watch for the message, it should not appears, clean up your SD card and run domoticz. If this fix your crash then you should hunt for the fix.
  5. @lex

    NanoPI M4

    Not sure it is related to your Domoticz crash but if i recall correctly the "warning" message is related to Wifi and should be harmless. There was a patch to fix that and i think the message is due to the missing password or wrong password to connect to wifi. BUT if you were connected to wifi before the crash you could try running without wifi configured and see what happens. Hope this helps.
  6. @lex

    [Experiment] armbian on NanoPi A64

    I hope you mean "mainline kernel"... Please, try that on Pine64+ too.
  7. @lex

    [Experiment] armbian on NanoPi A64

    My last update on this issue in case someone is working to get sound on A64 (>= 4.20). I tried every patch out there, triple checked the code , same situation, no sound. I must have missed something or overlooked something. I finally tried Vasily's kernel and for my surprise no sound. Last hope, i tried Vasily ARCH img, no luck, no sound even on Pine64. Maybe it works on Pinebook,....
  8. @lex

    [Experiment] armbian on NanoPi A64

    Here is what i found so far, there are three patches floating around about audio on A64. for dai compatible string: "allwinner,sun50i-a64-codec-i2s", "allwinner,sun50i-a64-acodec-i2s", "allwinner,sun50i-a64-i2s", I tried to match the code with the compatible string, but i still have issues, no one claims the sun50i-a64-audio and i get this errors:
  9. @lex

    The VPU driver

    @Myy, Any chance you will be working on RK3399 5.0.rcX ? (GPU / VPU). I have been looking at your work for NanoPi-T4 but the label ** NOT TESTED ** was a bit discouraging. I can try to help testing or to provide some feedback.
  10. @lex

    NanoPC T4

    FYI 5.0-rc1 works on NanoPi M4 with this DT, Bluetooth works with this instruction: The missing bits are Wifi and I think for GPU/VPU a new mali userspace is needed. ops, no mali or VPU ready on linux-next, sorry. ERROR: The DDK is not compatible with any of the Mali GPUs on the system. The DDK was built for 0x860 r2p0 status range [0..15], but none of the GPUs matched:
  11. big.LITTLE has a policy for each cluster so I pushed some changes to display CPU Temp, CPU Freq, and CPU V-core for each cluster instead of CPU Freq for each CPU. Added a branch: rk3399 so it does not break things, you may need to review the boot script if one would like to know CPU temp for big and for LITTLE cores.
  12. Just In case anyone is interested I have pushed HTOP 2.2.1 to github, so it is possible to monitor big.LITTLE cores in real-time. You can view the big.LITTLE in action, Vcore, Cpu thermal throttling and Cpu frequency for each big or LITTLE core. HTOP is a nice console graphical tool for system-monitor, process-viewer and process-manager. DEB package and source code in case you want to extend or fix things. Be aware the process list and task can be very intrusive if you want to monitor many things at once. It has been tested on NanoPi M4 (thanks to FriendlyElec for the samples) but should work on any SBC just adjust the Vcore path for different kernel version. https://github.com/avafinger/htop-2.1.1_enhanced-version
  13. If you get the xserver on Ubuntu (deb packages), please make a patch. Seems everyone else is using the Debian version which is older than Ubuntu. jock's solution sounds good to implement, maybe it works only on mainline. Glmark2-es2 23 FPS scores look more rendered by software than by mali. On Mali, it should be 55 / 56 FPS (1920x1080). * When i say fbdev i mean everything is rendered directly on /dev/fb0 and not having a Desktop and going CTRL+ALT+F1 to get into console ( framebuffer )
  14. I tried to build the xserver based on Rockchip xserver (debian) on Ubuntu, not much success. Broke font displaying on Desktop. Maybe you could ask for the patch on the RK32xx section, they have it working (armhf). I will give another try. [ 12.433] (==) modeset(0): Depth 24, (==) framebuffer bpp 32 [ 12.433] (==) modeset(0): RGB weight 888 [ 12.433] (==) modeset(0): Default visual is TrueColor [ 12.433] (II) Loading sub module "glamoregl" [ 12.433] (II) LoadModule: "glamoregl" [ 12.434] (II) Loading /usr/lib/xorg/modules/libglamoregl.so [ 12.907] (II) Module glamoregl: vendor="X.Org Foundation" [ 12.907] compiled for 1.19.6, module version = 1.0.0 [ 12.908] ABI class: X.Org ANSI C Emulation, version 0.4 [ 12.908] (II) glamor: OpenGL accelerated X.org driver based. [ 12.973] (II) glamor: EGL version 1.4 Midgard-"r14p0-01rel0": [ 12.973] EGL_KHR_surfaceless_gles2 required. [ 13.038] (II) modeset(0): Using GLES2. [ 13.038] (WW) modeset(0): Glamor is using GLES2 but GLX needs GL. Indirect GLX may not work correctly. [ 13.038] (II) modeset(0): glamor initialized [ 13.074] (II) modeset(0): Output HDMI-1 has no monitor section [ 13.074] (II) modeset(0): Output DP-1 has no monitor section [ 13.157] (II) modeset(0): EDID for output HDMI-1 [ 13.158] (II) modeset(0): Manufacturer: GSM Model: 1 Serial#: 16843009 [ 13.158] (II) modeset(0): Year: 2013 Week: 1
  15. Seems correct. I am not sure you can get 2D glamour decoration if it is that what you want. According to Rockchip doc no special X11 server. Did you test the usual glmark2-es2 ? Not working? Seems i was wrong: http://rockchip.wikidot.com/graphics
  16. I have been playing with T86x on my NanoPi M4 and i can say 3D and OpenCL are working fine with the mali userspace blobs. This blob setup below can save you a lot of sweat unless you really want to go with Panfrost. I can run Kodi 18b5, which renders menu and video on mali. Blobs used: https://github.com/avafinger/nanopi-m4-ubuntu-base-minimal/releases/tag/v1.2.1
  17. If you want to get your hands dirty i can give you briefly the steps if i recall correctly (it works on NanoPi M4, so should work on NanoPi-T4) but unfortunately, i did not take note: a) encode/decode is done by gstreamer (decoding by mvp) install gstreamer (if not already installed) sudo apt-get install libgstreamer1.0-0 gstreamer1.0-plugins-base gstreamer1.0-plugins-good gstreamer1.0-plugins-bad gstreamer1.0-plugins-ugly gstreamer1.0- libav gstreamer1.0-doc gstreamer1.0-tools b) clone https://github.com/rockchip-linux/mpp , build and install it (install dependencies fisrt) cmake -DRKPLATFORM=ON -DHAVE_DRM=ON && make sudo make install c) clone gstreamer-rockchip (i can't remember if i did for the -extra also) git clone https://github.com/rockchip-linux/gstreamer-rockchip.git cd gstreamer-rockchip ./autogen.sh --disable-rkximage make sudo make install sudo ldconfig git clone https://github.com/rockchip-linux/gstreamer-rockchip-extra make clean ./autogen.sh make sudo make install sudo ldconfig d) check if the plugins are then installed correctly gst-inspect-1.0|grep 4l2 gst-inspect-1.0|grep rkcamsrc gst-inspect-1.0 | grep rk gst-inspect-1.0 rkximage gst-inspect-1.0 rkv4l2 You will need libdrm-dev and some other dependencies i can't remember. This steps should work on any RK3399. Have fun.
  18. I thought you were using ayufan's kernel. I think nightly build has support for VPU already. Anyway, for BSP kernel: https://github.com/rockchip-linux/mpp
  19. It is a bit low. Don't you worry about the 100% source code, if you want the source code for mali you have to pay... and i guess it is not cheap. Rockchip has gone really nice on VPU and GPU. I think Allwinner should follow this path and give better support for VPU and mali. There is already support for VPU and mali from Rockchip on linux. Usually mali fbdev is 20 ~ 30% faster than mali X11 (don't know about Wayland) but there is an RK3399 board that claims a score of 58 (very good indeed, though i don't know which window size possibly Full HD)). Can you tell what kernel version on your build?
  20. If you have HDMI attached (1920x1080) can you benchmark mali? glmark2-es2 -s 1920x1080
  21. I was looking for errors, CSI does not really show up in dmesg. Seems no errors. I think more info is needed so others can help: armbianmonitor -u PS: You should have something similar to this depending on how is your kernel defconfig: Module Size Used by sun6i_csi 24576 0 videobuf2_dma_contig 20480 1 sun6i_csi ov5640 32768 1 videobuf2_memops 16384 1 videobuf2_dma_contig videobuf2_v4l2 20480 1 sun6i_csi v4l2_fwnode 16384 2 ov5640,sun6i_csi videobuf2_common 36864 2 sun6i_csi,videobuf2_v4l2 v4l2_common 16384 1 ov5640 videodev 139264 6 ov5640,v4l2_fwnode,v4l2_common,videobuf2_common,sun6i_csi,videobuf2_v4l2 sunxi_cir 16384 0 media 24576 3 ov5640,videodev,sun6i_csi hci_uart 36864 0 btintel 16384 1 hci_uart bluetooth 327680 2 hci_uart,btintel ecdh_generic 28672 1 bluetooth brcmfmac 188416 0 brcmutil 16384 1 brcmfmac ipv6 397312 18
  22. A couple of things to check: * check if ov5640 and csi are loaded. dmesg|grep 5640 & dmesg|grep csi * check if you have the correct camera module
  23. @lex

    OV5640 on mainline kernel

    The device tree: https://github.com/armbian/build/commit/10e206519089b8ff81b0dd6a6f3caa6c1adba04d#diff-5ec21c7daf434027694931230901ca60R96 If I recall correctly the driver (specific to FE boards) delivers YUV so you need to instruct fswebcam and cap-v4l2 to receive V4L2_PIX_FMT_YUYV. You can try mjpg-streamer that does that by default. Try 640x480 window size first and then move to 720p or higher. I have noticed there is (or there was) a slightly new/modified driver on mainline kernel 4.19.0 but did not have time to check the changes. That mainline driver has been originally written to v3s, you may check linux-sunxi. I don't know v3s so can't help much.