@lex

Members
  • Content Count

    479
  • Joined

  • Last visited

2 Followers

About @lex

  • Rank
    Embedded member

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

2470 profile views
  1. Nothing wrong with the board. Just for reference while comparing it with Renegade: Renegate size; 4.76 x 2.99 x 1.02 inches NanoPi R2S size: 2.36 x 1.16 x 2.36 inches Some info, Average consumption idling while cron is running is 1.8W, and i have observed for a while that the board was running with 1.0W ~ 1.2W , yes 1 Watt! As soon as cron and systemd-journald and systemd-udevd start working i get 2.0 ~ 2.2W. Kernel tested is essentially the Armbian Kernel (5.7) and vanilla mainline Kernel (5.8), but the booloader is based on Android (i think) found on internet (can't recall from where i got it, but is old version), no control about the DDR4 dram speed and i think it is very low freq, i maybe wrong. Obviously in my case with less running process, lower the CPU Temp will be. I did the Thumb test, seems consistent with the numbers. I have noticed that FE has now a tinny fan for the new version.
  2. Good question, i would say wrong when the CPU throttling kicks in too soon without load. I would stick to that tires vendor... "Power is nothing without control"
  3. 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.
  4. 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)
  5. 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.
  6. 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 */.
  7. 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.
  8. 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...
  9. 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 ...
  10. 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
  11. 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*
  12. 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.
  13. 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
  14. 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.
  15. @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.