Jump to content

@lex

Members
  • Posts

    530
  • Joined

  • Last visited

Everything posted by @lex

  1. My assertion was based on guessing... Practical experiments here indicated that the performance governor and 600 MHz heated up the board very soon in idle mode, 408 MHz and ondemand is acceptable for a mini router inside the case, around 55 ºC on a long run (ambient temp ~22 ºC). It is possible to run CPU at 1.5 GHz and change CPU throttling to start at 80 ºC , nothing that a swiss cheese and convection can't help. Perhaps the heat sink pad is a bit thick and a copper shim (or many) would help a lot, but the whole board is heated up and i suppose it should.
  2. Ahh, Good catch. DOVDD first, then AVDD, followed by DVDD. In the case of M2Z: gpio = <&pio 3 14 GPIO_ACTIVE_HIGH>; /* PD14 */ sensor is at least recognized with i2c bit bang. ls /dev/video video0 video1 v4l2-ctl --list-devices sun6i-csi (platform:camera): /dev/video1 cedrus (platform:cedrus): /dev/video0 v4l2-ctl -d 1 --list-formats --list-ctrls User Controls contrast 0x00980901 (int) : min=0 max=255 step=1 default=0 value=0 flags=slider saturation 0x00980902 (int) : min=0 max=255 step=1 default=64 value=64 flags=slider hue 0x00980903 (int) : min=0 max=359 step=1 default=0 value=0 flags=slider white_balance_automatic 0x0098090c (bool) : default=1 value=1 flags=update red_balance 0x0098090e (int) : min=0 max=4095 step=1 default=0 value=0 flags=inactive, slider blue_balance 0x0098090f (int) : min=0 max=4095 step=1 default=0 value=0 flags=inactive, slider exposure 0x00980911 (int) : min=0 max=65535 step=1 default=0 value=885 flags=inactive, volatile gain_automatic 0x00980912 (bool) : default=1 value=1 flags=update gain 0x00980913 (int) : min=0 max=1023 step=1 default=0 value=176 flags=inactive, volatile horizontal_flip 0x00980914 (bool) : default=0 value=0 vertical_flip 0x00980915 (bool) : default=0 value=0 power_line_frequency 0x00980918 (menu) : min=0 max=3 default=1 value=1 Camera Controls auto_exposure 0x009a0901 (menu) : min=0 max=1 default=0 value=0 flags=update Image Processing Controls pixel_rate 0x009f0902 (int64) : min=0 max=2147483647 step=1 default=61430400 value=61430400 flags=read-only test_pattern 0x009f0903 (menu) : min=0 max=4 default=0 value=0 ioctl: VIDIOC_ENUM_FMT Type: Video Capture [0]: 'BA81' (8-bit Bayer BGBG/GRGR) [1]: 'GBRG' (8-bit Bayer GBGB/RGRG) [2]: 'GRBG' (8-bit Bayer GRGR/BGBG) [3]: 'RGGB' (8-bit Bayer RGRG/GBGB) [4]: 'BG10' (10-bit Bayer BGBG/GRGR) [5]: 'GB10' (10-bit Bayer GBGB/RGRG) [6]: 'BA10' (10-bit Bayer GRGR/BGBG) [7]: 'RG10' (10-bit Bayer RGRG/GBGB) [8]: 'BG12' (12-bit Bayer BGBG/GRGR) [9]: 'GB12' (12-bit Bayer GBGB/RGRG) [10]: 'BA12' (12-bit Bayer GRGR/BGBG) [11]: 'RG12' (12-bit Bayer RGRG/GBGB) [12]: 'YUYV' (YUYV 4:2:2) [13]: 'YVYU' (YVYU 4:2:2) [14]: 'UYVY' (UYVY 4:2:2) [15]: 'VYUY' (VYUY 4:2:2) [16]: 'HM12' (YUV 4:2:0 (16x16 Macroblocks)) [17]: 'NV12' (Y/CbCr 4:2:0) [18]: 'NV21' (Y/CrCb 4:2:0) [19]: 'YU12' (Planar YUV 4:2:0) [20]: 'YV12' (Planar YVU 4:2:0) [21]: 'NV16' (Y/CbCr 4:2:2) [22]: 'NV61' (Y/CrCb 4:2:2) [23]: '422P' (Planar YUV 4:2:2) [24]: 'RGBP' (16-bit RGB 5-6-5) [25]: 'RGBR' (16-bit RGB 5-6-5 BE) [26]: 'JPEG' (JFIF JPEG, compressed)
  3. NanoPi Neo Air https://github.com/avafinger/linux-5.6.y/blob/master/arch/arm/boot/dts/nanopi-neo-air.dts#L578 The NanoPi A64 also works, using the i2c bitbang as probably the same way for the PineTab rear camera, I posted it on the Armbian forum a long time ago.
  4. Yes, it works on NanoPi Neo Air. Maybe someone can have a look at PineTab schematic and compare it to Pine64. It says /* Rear camera */.
  5. OV5640 is ready and works in mainline kernel. /dev/video0 will be created if the driver can find the sensor using the i2c line (generally speaking). You can check the schematic of your board if the sensor is attached to i2c. Compare it to NanoPi Neo Air schematic and you will see the nuances.
  6. That is an indication of wrong CPU_GOVERNOR, yes you get nice benchmarks values for a very short period of time and then the board overheats. just check with: cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor ondemand ondemand ondemand ondemand I think the holes are the best workaround...
  7. It is also important to check if the thermal pad touches the CPU, someone noticed the spacer is higher than it should be. Remove the board from the case and look against a light source, if you see a gap, you have a problem ...
  8. Wrong CPU_GOVERNOR and no way to dissipate the heat from inside the enclosure leads to overheating. Some very simple benchmarks on recent kernel: https://github.com/avafinger/nanopi-r2s-ubuntu-server-minimal-image
  9. Maybe you should update your kernel to 5.4.43 and/or run armbian-config: https://github.com/armbian/build/blob/master/config/kernel/linux-sunxi-current.config#L4362 I can't see any node /dev/video0 created from your dmesg info. Perhaps you have loaded a driver manually that created the node? Camera is not Plug&Play , the node /dev/videoX should be created only if a device is probed with success. reboot and check : ls /dev/video*
  10. You should have something like this if all devices are enabled: aplay -l **** List of PLAYBACK Hardware Devices **** card 0: realtekrt5651co [realtek,rt5651-codec], device 0: ff890000.i2s-rt5651-aif1 rt5651-aif1-0 [ff890000.i2s-rt5651-aif1 rt5651-aif1-0] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: ROCKCHIPSPDIF [ROCKCHIP,SPDIF], device 0: ff870000.spdif-dit-hifi dit-hifi-0 [ff870000.spdif-dit-hifi dit-hifi-0] Subdevices: 1/1 Subdevice #0: subdevice #0 card 2: hdmisound [hdmi-sound], device 0: ff8a0000.i2s-i2s-hifi i2s-hifi-0 [ff8a0000.i2s-i2s-hifi i2s-hifi-0] Subdevices: 1/1 Subdevice #0: subdevice #0 Ignore the message: [ 4.422324] No soundcards found. You don't have alsamixer controls for hdmi-sound. I am not able to test 4K and i have just fixed my mistakes with hantro and rkvdec so i can try Kodi on 5.7.0 and see what i get when time permits. But i think to fix the problem you have to enable module-allow-passthrough in PulseAudio config. see if you have: /usr/lib/pulse-13.0/modules/module-allow-passthrough.so Try adding load-module module-allow-passthrough to /etc/pulse/system.pa and restart PulseAudio or reboot. I Hope this helps you.
  11. Check out this info about Pulseaudio, secion 2 PulseAudio Output Configuration and pavcontrol https://kodi.wiki/view/PulseAudio 10:14:54.339 T:547838738576 WARNING: Pulseaudio module module-allow-passthrough not loaded - opening PT devices might fail
  12. I think the camera driver was not loaded. Maybe v4l2_g_parm_cap crashed while trying to get /dev/video1 capabilities (cedrus). Try to disable cedrus and review OV5640 parms to be able to load the driver.
  13. @lex

    Mainline VPU

    @rubenvb I did some experiments with vanilla kernel + Ezequiel patches (5.7.0-rc6) and some of my changes and with @balbes150 's kernel (5.7.0-rc6) which has the Ezequiel patches and a few more patches. I used @Kwiboo 's v4l2-request-hwaccel-4.2.2 and not the latest v4l2-request-hwaccel-4.2.2-rkvdev (i just missed that update). I get minor artifacts on the H264 sample (link provided) visible on screen , that seem you don't get that artifacts. The logs are ok, no error at all. Slightly better results for the balbes's kernel. I would like to figure out how kernel decides which driver will be used to decode, the hantro H264 driver or the rkvdec H264 driver . I will try @Kwiboos Kernel with v4l2-request-hwaccel-4.2.2-rkvdev and see the results. I don't know how different these kernel are from LE.
  14. @lex

    Mainline VPU

    Thanks, You need to see the output to /dev/fb0 to know if it is really working, can you do that?
  15. @lex

    Mainline VPU

    I am curious about your results, can you guys try this video and report the result? wget https://test-videos.co.uk/vids/jellyfish/mp4/h264/1080/Jellyfish_1080_10s_30MB.mp4 ffmpeg -loglevel debug -hwaccel drm -i Jellyfish_1080_10s_30MB.mp4 -pix_fmt bgra -f fbdev /dev/fb0
  16. I can't remember if i enabled wayland anywhere during the mesa build but SDL2 tells me: INFO: Built-in video drivers: wayland, KMSDRM, dummy INFO: Video driver: KMSDRM but SDL2 assume this: --enable-video-wayland use Wayland video driver [[default=yes]]
  17. The test was conducted on a NanoPi M4 with a full Mesa and SDL2 stack rebuilt from git in a non Armbian kernel. Armbian has better support for lima, but not sure if panfrost is in a better state than lima. You can get some ideas from here: https://forum.clockworkpi.com/t/help-with-mesa-lima-compilation-retroarch-freezing-screen-when-loading-a-saved-state/5228 Can you run: ./testgles2 --info all
  18. A tip that might help, try to run SDL2 without X window (not in a console inside X11, kill the desktop or don't run Desktop at all). Build latest SDL2-2.0.12 which has support for OpenGLES2 on GBM. ./configure --enable-video-kmsdrm --disable-video-x11 It works with panfrost and should work with lima as well. It is just crazy fast. ./testgles2 --geometry 1980x1080 INFO: Screen bpp: 32 INFO: INFO: Vendor : panfrost INFO: Renderer : panfrost INFO: Version : OpenGL ES 2.0 Mesa 20.0.0-devel (git-0eb78a078e) INFO: Extensions : GL_EXT_blend_minmax GL_EXT_multi_draw_arrays GL_EXT_texture_format_BGRA8888 GL_OES_compressed_ETC1_RGB8_texture GL_OES_depth24 GL_OES_element_index_uint GL_OES_fbo_render_mipmap GL_OES_mapbuffer GL_OES_rgb8_rgba8 GL_OES_stencil8 GL_OES_texture_3D GL_OES_texture_float GL_OES_texture_float_linear GL_OES_texture_half_float GL_OES_texture_half_float_linear GL_OES_texture_npot GL_OES_vertex_half_float GL_OES_EGL_image GL_OES_depth_texture GL_OES_packed_depth_stencil GL_EXT_texture_type_2_10_10_10_REV GL_OES_get_program_binary GL_APPLE_texture_max_level GL_EXT_discard_framebuffer GL_EXT_read_format_bgra GL_EXT_frag_depth GL_NV_fbo_color_attachments GL_OES_EGL_image_external GL_OES_EGL_sync GL_OES_vertex_array_object GL_EXT_occlusion_query_boolean GL_EXT_texture_rg GL_EXT_unpack_subimage GL_NV_draw_buffers GL_NV_read_buffer GL_NV_read_depth GL_NV_read_depth_stencil GL_NV_read_stencil GL_EXT_draw_buffers GL_EXT_map_buffer_range GL_KHR_debug GL_KHR_texture_compression_astc_ldr GL_OES_required_internalformat GL_OES_surfaceless_context GL_EXT_separate_shader_objects GL_EXT_compressed_ETC1_RGB8_sub_texture GL_EXT_draw_elements_base_vertex GL_EXT_texture_border_clamp GL_KHR_context_flush_control GL_OES_draw_elements_base_vertex GL_OES_texture_border_clamp GL_KHR_no_error GL_KHR_texture_compression_astc_sliced_3d GL_KHR_parallel_shader_compile INFO: INFO: SDL_GL_RED_SIZE: requested 5, got 8 INFO: SDL_GL_GREEN_SIZE: requested 5, got 8 INFO: SDL_GL_BLUE_SIZE: requested 5, got 8 INFO: SDL_GL_DEPTH_SIZE: requested 16, got 24 ^CINFO: 505.45 frames per second info: ./testdisplayinfo INFO: Using video target 'KMSDRM'. INFO: See 1 displays. INFO: 0: "0" (1920x1080, (0, 0)), 12 modes. ERROR: DPI: failed to query (That operation is not supported) INFO: CURRENT: fmt=SDL_PIXELFORMAT_ARGB8888 w=1920 h=1080 refresh=60 INFO: DESKTOP: fmt=SDL_PIXELFORMAT_ARGB8888 w=1920 h=1080 refresh=60 INFO: MODE 0: fmt=SDL_PIXELFORMAT_ARGB8888 w=1920 h=1080 refresh=60 INFO: MODE 1: fmt=SDL_PIXELFORMAT_ARGB8888 w=1920 h=1080 refresh=50 INFO: MODE 2: fmt=SDL_PIXELFORMAT_ARGB8888 w=1920 h=1080 refresh=30 INFO: MODE 3: fmt=SDL_PIXELFORMAT_ARGB8888 w=1920 h=1080 refresh=25 INFO: MODE 4: fmt=SDL_PIXELFORMAT_ARGB8888 w=1920 h=1080 refresh=24 INFO: MODE 5: fmt=SDL_PIXELFORMAT_ARGB8888 w=1280 h=1024 refresh=60 INFO: MODE 6: fmt=SDL_PIXELFORMAT_ARGB8888 w=1280 h=720 refresh=60 INFO: MODE 7: fmt=SDL_PIXELFORMAT_ARGB8888 w=1280 h=720 refresh=50 INFO: MODE 8: fmt=SDL_PIXELFORMAT_ARGB8888 w=1024 h=768 refresh=60 INFO: MODE 9: fmt=SDL_PIXELFORMAT_ARGB8888 w=800 h=600 refresh=60 INFO: MODE 10: fmt=SDL_PIXELFORMAT_ARGB8888 w=720 h=576 refresh=50 INFO: MODE 11: fmt=SDL_PIXELFORMAT_ARGB8888 w=720 h=480 refresh=60 INFO: Using vsync ./testgles --geometry 1980x1080 --vsync INFO: Screen bpp: 32 INFO: INFO: Vendor : panfrost INFO: Renderer : panfrost INFO: Version : OpenGL ES-CM 1.1 Mesa 20.0.0-devel (git-0eb78a078e) INFO: Extensions : GL_EXT_blend_minmax GL_EXT_multi_draw_arrays GL_EXT_texture_lod_bias GL_OES_byte_coordinates GL_OES_fixed_point GL_OES_stencil_wrap GL_OES_compressed_paletted_texture GL_OES_query_matrix GL_OES_read_format GL_OES_single_precision GL_OES_draw_texture GL_OES_point_size_array GL_OES_point_sprite GL_EXT_texture_format_BGRA8888 GL_OES_compressed_ETC1_RGB8_texture GL_OES_depth24 GL_OES_element_index_uint GL_OES_fbo_render_mipmap GL_OES_framebuffer_object GL_OES_mapbuffer GL_OES_rgb8_rgba8 GL_OES_stencil8 GL_OES_texture_env_crossbar GL_OES_texture_mirrored_repeat GL_OES_texture_npot GL_OES_EGL_image GL_OES_packed_depth_stencil GL_OES_texture_cube_map GL_APPLE_texture_max_level GL_EXT_discard_framebuffer GL_EXT_read_format_bgra GL_OES_blend_equation_separate GL_OES_blend_func_separate GL_OES_blend_subtract GL_OES_EGL_image_external GL_OES_EGL_sync GL_OES_vertex_array_object GL_EXT_map_buffer_range GL_KHR_debug GL_OES_required_internalformat GL_OES_surfaceless_context GL_EXT_compressed_ETC1_RGB8_sub_texture GL_KHR_no_error INFO: INFO: SDL_GL_RED_SIZE: requested 5, got 8 INFO: SDL_GL_GREEN_SIZE: requested 5, got 8 INFO: SDL_GL_BLUE_SIZE: requested 5, got 8 INFO: SDL_GL_DEPTH_SIZE: requested 16, got 24 ^CINFO: 60.05 frames per second
  19. Wifi and Bluetooth works fine on Mainline kernel 5.6.y with the more up to date firmware found here: https://people.linaro.org/~manivannan.sadhasivam/rock960_wifi/
  20. Maybe this can help: https://github.com/aguinet/usbtop
  21. ENODEV 19 No such device If you see the previous line of your dmesg output you see the message: USB device disconnected. In theory, if you connect 2 USB cameras to USB3 and one to USB2 it should work as someone has proven to work in a PC box. I must have done something wrong with the wiring in my quick test. I think your camera disconnected and reconnected for some reason and the handler was not free in time, so kernel asked for a new one.
  22. @Igor @martinayotte Here is the fix: &cpu0 { cpu-supply = <&reg_dcdc2>; };
  23. I just did a quick test with some usb 2.0 camera collecting dust here. It always fails with the third usb camera. Maybe with usb 3 would work. Reason: [22863.516749] usb 7-1.4: Not enough bandwidth for new device state. [22863.516807] usb 7-1.4: Not enough bandwidth for altsetting 6 Update: Attaching two usb 2.0 cameras to USB3 receptacles and the other one to USB2 did not work.
  24. I have been told LE 9.8.8 has panfrost working smooth , i think it's a @jernej's work. (not sure) I have no idea how to fetch this version and have a look at panfrost diff. Maybe you can. In my experience i have applied all available patches and still not stable enough.
  25. It has been a while since i last touched the 4.19 , but i think you should enable: CONFIG_DVB_USB_RTL28XXU Look for the module *rtl28xxu* (build as a module).
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines