Jump to content

Alex ThreeD

Members
  • Posts

    9
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. @shellless USB as GND source sound legit. Just to double check that you are correctly wired UART - have you tried to swap RX/TX? I have a board that looks exactly the same as yours: GND is a last drill hole on a board corner (probably there is nothing to afraid of soldering), then board's TX, board's RX, and VCC (next to the IR receiver). Baudrate 1500000. Also, be aware that sometimes board does not fully reset with board's RX pin connected to PC (it seems some components still powered up by RX pin). So I have to temporary disconnect RX pin. AFAIK Armbian does not need bootloader on emmc. So emmc could be cleared, masked or unsoldered.
  2. from the photos it seem you didn't connect GND uart pin
  3. @suser try to set another "display type" values in openvfd config: https://github.com/arthur-liberman/vfd-configurations
  4. Fixed https://github.com/armbian/build/pull/5723 Here is (probably not so interesting) list of modelines that available with and without this patch on FullHD monitor: Modelines enabled by rk356x-vop2-support.patch: Modeline "1920x1080": 60 148352 1920 2008 2052 2200 1080 1084 1089 1125 0x40 0x5 Modeline "1920x1080i": 60 74176 1920 2008 2052 2200 1080 1084 1094 1125 0x40 0x15 Modeline "1680x1050": 60 119000 1680 1728 1760 1840 1050 1053 1059 1080 0x40 0x9 Modeline "1280x1024": 75 135000 1280 1296 1440 1688 1024 1025 1028 1066 0x40 0x5 Modeline "1280x800": 60 71000 1280 1328 1360 1440 800 803 809 823 0x40 0x9 Modeline "1280x720": 60 74176 1280 1390 1430 1650 720 725 730 750 0x40 0x5 Modeline "1024x768": 75 78750 1024 1040 1136 1312 768 769 772 800 0x40 0x5 Modeline "832x624": 75 57284 832 864 928 1152 624 625 628 667 0x40 0xa Modeline "800x600": 75 49500 800 816 896 1056 600 601 604 625 0x40 0x5 Modeline "720x480": 60 27027 720 736 798 858 480 489 495 525 0x40 0xa Modeline "720x480": 60 27027 720 736 798 858 480 489 495 525 0x40 0xa Modeline "640x480": 75 31500 640 656 720 840 480 481 484 500 0x40 0xa Modeline "640x480": 60 25200 640 656 752 800 480 490 492 525 0x40 0xa Modeline "640x480": 60 25175 640 656 752 800 480 490 492 525 0x40 0xa Modeline "640x480": 60 25175 640 656 752 800 480 490 492 525 0x40 0xa Modeline "720x400": 70 28320 720 738 846 900 400 412 414 449 0x40 0x6 Modelines available both with and without this patch: Modeline "1920x1080": 60 148500 1920 2008 2052 2200 1080 1084 1089 1125 0x48 0x5 Modeline "1920x1080": 60 148500 1920 2008 2052 2200 1080 1084 1089 1125 0x40 0x5 Modeline "1920x1080i": 60 74250 1920 2008 2052 2200 1080 1084 1094 1125 0x40 0x15 Modeline "1920x1080i": 60 74250 1920 2008 2052 2200 1080 1084 1094 1125 0x40 0x15 Modeline "1920x1080": 50 148500 1920 2448 2492 2640 1080 1084 1089 1125 0x40 0x5 Modeline "1920x1080i": 50 74250 1920 2448 2492 2640 1080 1084 1094 1125 0x40 0x15 Modeline "1600x900": 60 108000 1600 1624 1704 1800 900 901 904 1000 0x40 0x5 Modeline "1280x1024": 60 108000 1280 1328 1440 1688 1024 1025 1028 1066 0x40 0x5 Modeline "1152x864": 75 108000 1152 1216 1344 1600 864 865 868 900 0x40 0x5 Modeline "1280x720": 60 74250 1280 1390 1430 1650 720 725 730 750 0x40 0x5 Modeline "1280x720": 60 74250 1280 1390 1430 1650 720 725 730 750 0x40 0x5 Modeline "1280x720": 50 74250 1280 1720 1760 1980 720 725 730 750 0x40 0x5 Modeline "1024x768": 60 65000 1024 1048 1184 1344 768 771 777 806 0x40 0xa Modeline "800x600": 60 40000 800 840 968 1056 600 601 605 628 0x40 0x5 Modeline "720x576": 50 27000 720 732 796 864 576 581 586 625 0x40 0xa Modeline "720x576": 50 27000 720 732 796 864 576 581 586 625 0x40 0xa Modeline "720x480": 60 27000 720 736 798 858 480 489 495 525 0x40 0xa Modeline "720x480": 60 27000 720 736 798 858 480 489 495 525 0x40 0xa Modeline "720x480": 60 27000 720 736 798 858 480 489 495 525 0x40 0xa
  5. @jock good news! I have finally found a root cause: rk356x-vop2-support.patch Without this patch HDMI is OK. Apparently this happend due to one hunk of rk356x-vop2-support.patch lost in transition 6.3 -> 6.4: - if (pclk == mpll_cfg[i].mpixelclock) { + if (pclk <= mpll_cfg[i].mpixelclock) { I can fix this patch and check everything is ok, but I'm not sure whether this patch is still needed given that 4k resolution already added to mainline 6.4. What to you think?
  6. @jock Hi, I've seen your comment on HDMI not working with 6.5 egde kernel: https://github.com/armbian/build/pull/5657#issuecomment-1703880889 Have you had time to investigate it since then? At first I've tried to revert one suspicious drm fbdev commit, but it doesn't help. Then I've enabled kernel drm debug (drm.debug=0x1bf in kernel command line) and it shed some light on a problem. 6.5 kernel rejected to use all modelines available (the same modelines was not rejected by 6.1): > [drm:drm_mode_debug_printmodeline] Modeline "1920x1080": 60 148500 1920 2008 2052 2200 1080 1084 1089 1125 0x48 0x5 > [drm:drm_mode_prune_invalid] Not using 1920x1080 mode: BAD > ... Can you suggest a direction for further diagnostics? dmesg-6.1.txtdmesg-6.5.txt PS I'm not sure where is best place to discuss it - here or on github.
  7. Yeah, I've seen suggestions to lock cpufreq here on forum and checked it before starting voltage experiments. Here are my observations (on RK3328 box): 1) I have not seen stability issues with stock rk3318-box install with default 1.1 GHz limit 2) Stability issues appear after enabling "RK3328 (max 1.3GHz)" option in rk3318-config 3) Locking cpufreq to 1.3GHz in armbian-config does not help to mitigate issues (I've verified that cpu frequency are actually locked in `htop` output) 4) I've changed boot dtb to rk3318-a95x-z2.dtb and disabled rockchip-rk3318-box-cpu-hs.dtbo overlay. With this setup there was no issues. 5) Finally I've changed back boot dtb to rk3318-box.dtb and activated a patched rockchip-rk3318-box-cpu-hs.dtbo overlay with increased voltages only for 1.2-1.3GHz. No stability issues both for a few hours of stress test and for a few weeks of common use. Here is my patched rockchip-rk3318-box-cpu-hs.dtbo source: /dts-v1/; / { fragment@0 { target-path = "/opp_table0/opp-1200000000"; __overlay__ { opp-microvolt = <0x12b128>; status = "okay"; }; }; fragment@1 { target-path = "/opp_table0/opp-1296000000"; __overlay__ { opp-microvolt = <0x13d620>; status = "okay"; }; }; fragment@2 { target-path = "/opp_table0"; __overlay__ { opp-408000000 { opp-hz = <0x00 0x18519600>; opp-microvolt = <0xe7ef0>; clock-latency-ns = <0x9c40>; opp-suspend; }; }; }; }; As you see I've also added 408MHz setting, but it is probably not needed. I've seen no measurable difference in power consumption at 400MHz vs 600MHz. I haven't tried it yet. I could check it if you find it useful
  8. Hi @jock. I've found my rk3328 box have stability issues on 1.2-1.3 GHz with default voltage in rk3318-box.dtb. It hangs out every few days with kernel oops or something alike. It works fine with opp-microvolt values for 1.2-1.3 GHz taken from rk3318-a95x-z2.dtb (i.e +0.025V). I'm not sure whether such increase are bad for other boards, probably you could consider making it a default in rk3318-box.dtb. I've found a simple way to trigger stability issues: connect a display, run `glmark2`/`glmark2-wayland`/`glmark2-drm` and `armbianmonitor -z` in infinite loop simultaneously. With `rk3318-box.dtb` voltages system hangs up in 5-10 minutes. With `rk3318-a95x-z2.dtb` voltages it runs for hours without issues.
  9. Hi! I'd like to share my findings on running UxPlay AirPlay Mirror server on rk3328 box. Default setup with x11 works quite bad on Armbian 23.05 (Armbian_23.5.1_Rk3318-box_bookworm_current_6.1.30_xfce_desktop.img). Video playback falls behind of realtime both for default video output method (autovideosink) and for -vs xvimagesink/glimagesink. At the same time uxplay with kmssink or waylandsink video output works without issues: # chvt 2 # uxplay -vs kmssink In all these cases CPU usage are far from 400% and even lower than 100%, so I assume that 1080p h264 video stream are HW-decoded but there are some stalls happening in x11 graphic stack (xorg config 40-serverflags.conf doesn't help). I've also ran glmark2 tests to confirm a problems with x11. OpenGL/GLES are 3-5 times less performant under x11 than under wayland/drm. rk3318-box:~:# glmark2 --fullscreen glmark2 2023.01 ======================================================= OpenGL Information GL_VENDOR: lima GL_RENDERER: Mali450 GL_VERSION: 2.1 Mesa 22.3.6 Surface Config: buf=32 r=8 g=8 b=8 a=8 depth=24 stencil=0 samples=0 Surface Size: 1920x1080 fullscreen ======================================================= [build] use-vbo=false: FPS: 41 FrameTime: 24.919 ms ... ======================================================= glmark2 Score: 29 ======================================================= rk3318-box:~:# glmark2-wayland --fullscreen ======================================================= OpenGL Information GL_VENDOR: lima GL_RENDERER: Mali450 GL_VERSION: 2.1 Mesa 22.3.6 Surface Config: buf=32 r=8 g=8 b=8 a=8 depth=24 stencil=0 samples=0 Surface Size: 1920x1080 fullscreen ======================================================= [build] use-vbo=false: FPS: 207 FrameTime: 4.832 ms ... ======================================================= glmark2 Score: 98 =======================================================
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines