aaditya

Members
  • Content Count

    13
  • Joined

  • Last visited

Reputation Activity

  1. Like
    aaditya reacted to mjhammel in Mainline VPU   
    I've been following @xmixahlx work on pbp-tools.  I have an rk3399 board we're developing in house (kind of) and I'm tasked with seeing what it takes to get the VPU working.  Our build system won't work with the pbp scripts but I extraced the useful bits (urls, patches, etc.) from them to get a build working with the following components.  I also wrote a BASH test script for doing validation (see link below) up to and including attempting to decode and encode to the NULL device with ffmpeg.  I'm not getting the output I'm expecting and was wondering if I've missed a step.
     
    This is what I have now.  This is the order I build them as well.
            1. Linux 5.8.5 w/local config plus pbp patch
                a. url: https://github.com/xmixahlx/pbp-tools/tree/master/resources/linux/5.8
                b. linux-5.8-rc4-hwaccel_20200709.diff
            2. v4l2-utils 1.20.0 (no patches)
            3. libva (git master) with patches
                a. url: https://patch-diff.githubusercontent.com/raw/intel/libva/pull/
                b. 332.patch
                c. 340.patch
                d. patches edited based on https://github.com/xmixahlx/pbp-tools/blob/master/pbp-install-libva
            4. libva-v4l2-request (git master) with patches
                a. url: https://patch-diff.githubusercontent.com/raw/bootlin/libva-v4l2-request/pull/
                b. 30.patch
                c. 32.patch
                d. Why not 28, 29 too? (31 doesn't exist: https://github.com/bootlin/libva-v4l2-request/pulls) - I think I found these may not be needed after all, but can't remember now why I left them out.
            5. libva-utils (git master, no patches)
            6. ffmpeg n4.3.1 with patches
                a. url: https://raw.githubusercontent.com/xmixahlx/pbp-tools/master/resources/ffmpeg/4.3/
                b. ffmpeg-4.3-v4l2request-rkvdec_20200709.diff
            7. v4l2-request-test (git master, no patches)
     
    The test script, which I linked at the bottom of this post, is mostly just printing out what my setup looks like and responses to various v4l2, va and ffmpeg commands suggested here, the pbp forum and for ffmpeg.  I run it like this:
     
     
    I can also run it without the -t option to enable decode/encode tests but those don't work and I think that's because of what the rest of the tests are telling me.  Most important is that vainfo is not showing any profile or entrypoints. 
    One important fact for my build:  drm is not enabled yet.  We have it working on a 4.4.179 kernel and are working on a port to 5.4, but I have to wait for that before I port again to 5.8.5.  Not sure if that's going to be a show stopper for testing the VPU or not.  I thought with the va interface I wouldn't need that.
     
    Any tips on what to try next would be appreciated.
     
    Here is the output from the test.
    VPU TESTS ==== CHECK FOR DRIVERS Drivers: hantro-vpu rkvdec ==== LIST DEVICES Video Devices: /dev/video1 /dev/video2 /dev/video0 Media Devices: /dev/media1 /dev/media0 ==== DUMP FORMATS AND CONTROLS ++++ /dev/video1: |---------------------------------------------------- JPEG Compression Controls compression_quality 0x009d0903 (int) : min=5 max=100 step=1 default=50 value=50 ioctl: VIDIOC_ENUM_FMT Type: Video Capture Multiplanar [0]: 'JPEG' (JFIF JPEG, compressed) |---------------------------------------------------- ++++ /dev/video2: |---------------------------------------------------- mpeg_2_slice_parameters 0x009909fa (unknown): type=103 flags=has-payload mpeg_2_quantization_matrices 0x009909fb (unknown): type=104 flags=has-payload vp8_frame_header 0x009910d0 (unknown): type=301 flags=has-payload ioctl: VIDIOC_ENUM_FMT Type: Video Capture Multiplanar [0]: 'NV12' (Y/CbCr 4:2:0) |---------------------------------------------------- ++++ /dev/video0: |---------------------------------------------------- Codec Controls h264_level 0x00990a67 (menu) : min=0 max=15 default=0 value=0 h264_profile 0x00990a6b (menu) : min=0 max=6 default=2 value=2 vp9_profile 0x00990b00 (menu) : min=0 max=0 default=0 value=0 hevc_profile 0x00990b67 (menu) : min=0 max=2 default=0 value=0 hevc_level 0x00990b68 (menu) : min=0 max=8 default=0 value=0 h264_sequence_parameter_set 0x00990ce8 (unknown): type=110 flags=has-payload h264_picture_parameter_set 0x00990ce9 (unknown): type=111 flags=has-payload h264_scaling_matrix 0x00990cea (unknown): type=112 flags=has-payload h264_slice_parameters 0x00990ceb (unknown): type=113 flags=has-payload h264_decode_parameters 0x00990cec (unknown): type=114 flags=has-payload h264_decode_mode 0x00990ced (menu) : min=1 max=1 default=1 value=1 h264_start_code 0x00990cee (menu) : min=1 max=1 default=1 value=1 hevc_sequence_parameter_set 0x00990cf0 (unknown): type=120 flags=has-payload hevc_picture_parameter_set 0x00990cf1 (unknown): type=121 flags=has-payload hevc_slice_parameters 0x00990cf2 (unknown): type=122 [16] flags=has-payload hevc_scaling_matrix 0x00990cf3 (unknown): type=123 flags=has-payload hevc_decode_mode 0x00990cf7 (menu) : min=1 max=1 default=1 value=1 hevc_start_code 0x00990cf8 (menu) : min=1 max=1 default=1 value=1 vp9_frame_context_0 0x009918a0 (unknown): type=400 flags=has-payload vp9_frame_context_1 0x009918a1 (unknown): type=400 flags=has-payload vp9_frame_context_2 0x009918a2 (unknown): type=400 flags=has-payload vp9_frame_context_3 0x009918a3 (unknown): type=400 flags=has-payload vp9_frame_decode_parameters 0x009918a4 (unknown): type=404 flags=has-payload ioctl: VIDIOC_ENUM_FMT Type: Video Capture Multiplanar [0]: 'NV12' (Y/CbCr 4:2:0) [1]: 'NV15' (10-bit Y/CbCr 4:2:0 (Packed)) [2]: 'NV16' (Y/CbCr 4:2:2) [3]: 'NV20' (10-bit Y/CbCr 4:2:2 (Packed)) |---------------------------------------------------- ==== SHOW HW ACCELS ffmpeg version n4.3.1-Kodi Copyright (c) 2000-2020 the FFmpeg developers built with gcc 7.5.0 (GCC) configuration: --prefix=/usr --arch=arm64 --target-os=linux --cross-prefix=aarch64-linux-gnu- --enable-cross-compile --sysr oot=/home2/qsys3/src/os/../aarch64-linux-gnu/install --pkg-config=aarch64-linux-gnu-pkg-config --enable-shared --disable-doc --enable-v4l2-request --enable-libdrm --enable-libudev --enable-pic --enable-avfilter --enable-postproc --enable-pthreads --e nable-gpl --enable-nonfree --enable-version3 --toolchain=hardened --enable-avfilter --enable-libfontconfig --enable-libfreety pe --enable-libxml2 --enable-openssl --enable-protocol=file --enable-protocol=pipe --enable-hwaccel=h264_vaapi --enable-hwacc el=hevc_vaapi --enable-hwaccel=mjpeg_vaapi --enable-hwaccel=mpeg2_vaapi --enable-hwaccel=mpeg4_vaapi --enable-hwaccel=vp9_vaa pi --enable-muxer=h264 --enable-muxer=mjpeg --enable-muxer=mpeg2video --enable-muxer=mp2 --enable-muxer=mp4 --enable-muxer=mo v --enable-muxer=null --enable-demuxer=mpegvideo --enable-demuxer=h264 --enable-demuxer=hevc --enable-demuxer=mov --enable-en coder=mjpeg_vaapi --enable-encoder=vp9_vaapi --enable-encoder=vp8_v4l2m2m --enable-encoder=vp8_vp8_vaapi --enable-encoder=hev c_vaapi --enable-encoder=hevc_v4l2m2m --enable-encoder=mpeg2_vaapi --enable-encoder=h264_vaapi --enable-encoder=h264_v4l2m2m --enable-encoder=wrapped_avframe --enable-encoder=pcm_s16le --enable-decoder=mjpeg --enable-decoder=vp9 --enable-decoder=vp8 --enable-decoder=vp8_v4l2m2m --enable-decoder=vp9_v4l2m2m --enable-decoder=hevc --enable-decoder=hevc_v4l2m2m --enable-decode r=h264 --enable-decoder=webp --enable-decoder=mpeg2video --enable-decoder=mpeg2_v4l2m2m --enable-decoder=mpeg4 --enable-decod er=mpeg4_v4l2m2m --enable-rpath --extra-ldflags=-ludev --libdir=/usr/lib --shlibdir=/usr/lib libavutil 56. 51.100 / 56. 51.100 libavcodec 58. 91.100 / 58. 91.100 libavformat 58. 45.100 / 58. 45.100 libavdevice 58. 10.100 / 58. 10.100 libavfilter 7. 85.100 / 7. 85.100 libswscale 5. 7.100 / 5. 7.100 libswresample 3. 7.100 / 3. 7.100 libpostproc 55. 7.100 / 55. 7.100 Hardware acceleration methods: vaapi drm |---------------------------------------------------- ==== SHOW VAINFO ++++ /dev/video1: |---------------------------------------------------- libva info: VA-API version 1.9.0 libva info: User environment variable requested driver 'v4l2_request' libva info: Trying to open /usr/lib/dri/v4l2_request_drv_video.so libva info: Found init function __vaDriverInit_1_9 libva info: va_openDriver() returns 0 vainfo: VA-API version: 1.9 (libva 2.9.0.pre1) vainfo: Driver version: v4l2-request vainfo: Supported profile and entrypoints |---------------------------------------------------- ++++ /dev/video2: |---------------------------------------------------- libva info: VA-API version 1.9.0 libva info: User environment variable requested driver 'v4l2_request' libva info: Trying to open /usr/lib/dri/v4l2_request_drv_video.so libva info: Found init function __vaDriverInit_1_9 libva info: va_openDriver() returns 0 vainfo: VA-API version: 1.9 (libva 2.9.0.pre1) vainfo: Driver version: v4l2-request vainfo: Supported profile and entrypoints |---------------------------------------------------- ++++ /dev/video0: |---------------------------------------------------- libva info: VA-API version 1.9.0 libva info: User environment variable requested driver 'v4l2_request' libva info: Trying to open /usr/lib/dri/v4l2_request_drv_video.so libva info: Found init function __vaDriverInit_1_9 libva info: va_openDriver() returns 0 vainfo: VA-API version: 1.9 (libva 2.9.0.pre1) vainfo: Driver version: v4l2-request vainfo: Supported profile and entrypoints |---------------------------------------------------- Tests completed.  
    Here is the test script.
     
     
  2. Like
    aaditya reacted to Werner in Help Test Upcoming Armbian v20.08 (Caple)!   
    Aaaaaaand it's out: https://www.armbian.com/newsflash/armbian-20-08-caple/
  3. Like
    aaditya reacted to rubenvb in Mainline VPU   
    Current Kodi master (currently hash 9f6d978f646) with the v4l2-request-hwaccel-4.3-rkvdec ffmpeg branch leads to audio only when starting video playback. The log produces this:
    2020-07-23 20:32:06.003 T:57711 INFO <general>: Creating InputStream 2020-07-23 20:32:06.015 T:57711 INFO <general>: Creating Demuxer 2020-07-23 20:32:06.166 T:57711 INFO <general>: Opening stream: 0 source: 256 2020-07-23 20:32:06.166 T:57711 INFO <general>: Creating video codec with codec id: 27 2020-07-23 20:32:06.166 T:57711 INFO <general>: CDVDVideoCodecDRMPRIME::Open - using decoder H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 2020-07-23 20:32:06.167 T:57711 INFO <general>: Creating video thread 2020-07-23 20:32:06.168 T:57718 INFO <general>: running thread: video_thread 2020-07-23 20:32:06.168 T:57711 INFO <general>: Opening stream: 1 source: 256 2020-07-23 20:32:06.168 T:57711 INFO <general>: Finding audio codec for: 86020 2020-07-23 20:32:06.169 T:57711 INFO <general>: CDVDAudioCodecFFmpeg::Open() Successful opened audio decoder dca 2020-07-23 20:32:06.169 T:57711 INFO <general>: Creating audio thread 2020-07-23 20:32:06.169 T:57719 INFO <general>: running thread: CVideoPlayerAudio::Process() 2020-07-23 20:32:06.169 T:57711 INFO <general>: Opening stream: 2 source: 256 2020-07-23 20:32:06.172 T:57718 INFO <general>: CVideoPlayerVideo - Stillframe left, switching to normal playback 2020-07-23 20:32:06.180 T:57719 INFO <general>: Creating audio stream (codec id: 86020, channels: 8, sample rate: 48000, no pass-through) 2020-07-23 20:32:06.184 T:57718 ERROR <general>: CDVDVideoCodecDRMPRIME::AddData - send packet failed: Invalid data found when processing input (-1094995529) 2020-07-23 20:32:06.184 T:57718 ERROR <general>: CDVDVideoCodecDRMPRIME::AddData - send packet failed: Invalid data found when processing input (-1094995529) 2020-07-23 20:32:06.185 T:57718 ERROR <general>: CDVDVideoCodecDRMPRIME::AddData - send packet failed: Invalid data found when processing input (-1094995529) ... 2020-07-23 20:32:06.589 T:57718 ERROR <general>: CDVDVideoCodecDRMPRIME::AddData - send packet failed: Invalid data found when processing input (-1094995529) 2020-07-23 20:32:07.006 T:57718 ERROR <general>: CDVDVideoCodecDRMPRIME::Drain - send packet failed: Invalid data found when processing input (-1094995529) 2020-07-23 20:32:07.006 T:57718 ERROR <general>: CDVDVideoCodecDRMPRIME::GetPicture - receive frame failed: Invalid data found when processing input (-1094995529) 2020-07-23 20:32:07.006 T:57718 INFO <general>: CVideoPlayerVideo - Stillframe detected, switching to forced 23.976024 fps 2020-07-23 20:32:07.047 T:57718 ERROR <general>: CDVDVideoCodecDRMPRIME::GetPicture - receive frame failed: Invalid data found when processing input (-1094995529) 2020-07-23 20:32:07.064 T:57718 INFO <general>: CVideoPlayerVideo - Stillframe left, switching to normal playback 2020-07-23 20:32:07.064 T:57718 ERROR <general>: CDVDVideoCodecDRMPRIME::AddData - send packet failed: End of file (-541478725) 2020-07-23 20:32:07.064 T:57718 ERROR <general>: CDVDVideoCodecDRMPRIME::GetPicture - receive frame failed: Invalid data found when processing input (-1094995529) 2020-07-23 20:32:07.065 T:57718 ERROR <general>: CDVDVideoCodecDRMPRIME::AddData - send packet failed: End of file (-541478725) 2020-07-23 20:32:07.065 T:57718 ERROR <general>: CDVDVideoCodecDRMPRIME::GetPicture - receive frame failed: Invalid data found when processing input (-1094995529) 2020-07-23 20:32:07.148 T:57718 ERROR <general>: CDVDVideoCodecDRMPRIME::AddData - send packet failed: End of file (-541478725) 2020-07-23 20:32:07.231 T:57718 ERROR <general>: CDVDVideoCodecDRMPRIME::AddData - send packet failed: End of file (-541478725) To be honest, this has been like this for a while, and my old build (kodi hash 9f6d978f646 with the 4.2.2 ffmpeg branch) works fine.
    If I translate the hashes into "revisions", I get r55120 (working) vs r55380 (hash e64b3034b56) broken, which means roughly 260 commits that might have broken it for me.
    I fear the move to ffmpeg 4.3 is at least partially to blame.
    I will try to bisect this better, but the old revision won't build due to some networking related function pointer not being convertible without -fpermissive.
    I'll need to find some time to bisect, so I don't know when I'll get to it.
     
    Any thoughts or anything I can try to provide more info or at best fix this issue without bisecting kodi?
     
    Thanks for everything so far, you guys are great!
  4. Like
    aaditya reacted to xmixahlx in Mainline VPU   
    most scripts are not pbp specific, but that has been the focus so i am not sure for other devices. i would say test and give feedback after reading the scripts. i will be making these more generic as i expect to get a few HardRock64 devices when they are available.
     
    the most specific is the linux build script because of the pbp patch and kernel config, but you can override this with KERNELCONFIG and use your own config to build for almost any rockchip device. I will make the pbp patch overrideable.
     
    back on topic:
     
    kwiboo's linux-rockchip WIP branch is working great - and we have a LOT of activity for v4l2 and rkvdec on linux-media. excited for 5.9.
     
    kwiboo's ffmpeg 4.3 branch patch applies to 4.3.1 and master as well as release/4.3 -- all working well!
     
    i shared the vp9 file that gives me problems above. the same file decodes fine with intel vaapi.
     
    the ffmpeg frontend still does not share v4l2request support, so software that uses libavcodec like mpv are still broken due to lack of decoder detection and selection capability.
     
    wildly thankful for the work of kwiboo and jernej and others. thanks!
     
     
     
     
  5. Like
    aaditya reacted to Kwiboo in Mainline VPU   
    Thanks for testing!, kodi has just moved to ffmpeg 4.3 so LibreELEC will follow as soon as all ffmpeg patches has been rebased.
     
     
    Do you have a sample to share? Also note that only Profile 0 is supported and videos using frame resize is expected to have issues.
     
     
    I do not expect these formats to work, the kodi drmprime video codec and renderer sw decoding parts have mainly been tested with 8-bit video.
    The crash should probably be fixed, unfortunately 10/12-bit sw decoding is not high on priority list, in future when ffmpeg filters are supported in kodi drmprime video codec converting to a 8-bit pixel format may be possible.
  6. Like
    aaditya reacted to xmixahlx in Mainline VPU   
    understood. tyvm for context.
     
    5.7 is released! thanks again for your work and others getting patches upstreamed.
     
    i noticed vc1 and mpeg4 hwaccel work in @jernej
    repos. is that coming to rk3399?
     
    also bootlin has been active with v4l2-request-test with new hantro and other branches. and the bext branch was deleted in libva-v4l2-request. hopeful that these will be updated for v4l2 in 5.7!
     
    with ffmpeg not displaying v4l2request hwaccels any more, it seems that mpv hwdec doesn't work. should i be doing something different?
  7. Like
    aaditya reacted to Kwiboo in Mainline VPU   
    Thanks for testing, normally I try to keep ffmpeg_v4l2-request-hwaccel-master and ffmpeg_v4l2-request-hwaccel-4.2.2 in sync but I have not yet updated or tested the -master branch, I will try to update it in next few days.
     
     
    Background on my different ffmpeg branches:
    v4l2-request-hwaccel-x.y.z: Main branch that most of the time matches the patches used in LibreELEC master, x.y.z (4.2.2) matches the ffmpeg version used in Kodi master. This branch is usually tested on Rockchip/hantro/rkvdec by me and on Allwinner/cedrus by @jernej, fixup commits usually gets squashed right before we pick out a new patchset for use in LibreELEC.
    v4l2-request-hwaccel-master: This branch should contain the patches in v4l2-request-hwaccel-x.y.z on top of ffmpeg master, may see some delays at times.
    v4l2-request-hwaccel-4.2.2-rkvdec: work-in-progress branch for parts that currently only is expected to work on rockchip/rkvdec, e.g. 10-bit hevc decoding on cedrus stops working in this branch due to patches to handle rkvdec 10-bit decoding, patches should eventually flow to -x.y.z/-master branches once ready.
     
  8. Like
    aaditya reacted to S_R in [Mini review] ROCK64 SATA cable   
    I bricked my JSM578 with the v255.1.0.1 beta firmware, so I got a new enclosure from Orico (2139C3) http://www.orico.cc/goods.php?id=6352 with a VL716 chipset.
    After adding a udev rule as described here TRIM works perfectly fine now.
  9. Like
    aaditya reacted to tkaiser in [Mini review] ROCK64 SATA cable   
    No idea. I've one ASM1153E here but never measured consumption (only pretty unprecise and then I didn't notice differences to JMS567 or JMS578). Since the basic problem is always one USB3 SuperSpeed PHY and one SATA 3.0 PHY being active I also doubt that there are real power savings possible,
     
    Though for JMicron SATA bridges we learned recently that there exists the possibility to update/modify the firmware so maybe there are some tweaks possible. While I'm currently in direct contact with JMicron (issue here) I don't want to ask these questions now since waiting for firmware fixes that provide full SAT compliance for JMS567/JMS578.
  10. Like
    aaditya reacted to Kwiboo in 4k HDMI output   
    I have some work-in-progress patches at https://github.com/Kwiboo/linux-rockchip/compare/next-20200501...next-20200501-drm-rockchip that should enable up to 4k30hz hdmi modes on rk3399.
     
    My focus switched to rkvdec so these patches have been on hold for some time, they need to be synced with some of my older rk3328 patches for 420-mode support before they can be sent upstream. With 10-bit decoding now working I am expecting readying 4k/10-bit hdmi patches to be more fun :-)
  11. Like
    aaditya reacted to piter75 in rk3399 vs rockchip64 family   
    You probably meant RockPro64 which is indeed a SBC name that is now part of rockchip64 family.
     
    Well... IMHO the name is fitting well.
     
    The idea of rockchip64 family is to consolidate one day all (rockchip 64) bit boards if possible - that means all based on 64 bit SoCs, eg. rk3328, rk3399 and rk3308.
    The rockchip64 family is nothing new - it already exists and contains rk3328 and rk3399 boards.
  12. Like
    aaditya reacted to piter75 in Nanopi M4v2 - crash/freeze   
    There are some older threads where people noticed it too, myself included 
     
    Would you like to participate in testing of a possible cure workaround for those issues?
    Here is the image build off the master with RAM settings tweaked a bit: https://drive.google.com/open?id=1H4K-1sBUttbeHZUaE_J-t-P5cjYiqPU7 
    If you want to build the image yourself you can use this branch of Armbian build system: https://github.com/armbian/build/tree/nanopi-m4v2-stability-fix
     
    I have mine restarted several times with those settings and I see no crashes on boot/reboot but it certainly needs some longer uptime testing to be deemed successful.
  13. Like
    aaditya reacted to Hover in Mainline u-boot spl nvme support   
    I want to use the mainline u-boot spl to load the u-boot proper(u-boot.itb) from nvme, so that the only part off the nvme is the tpl/spl in the emmc/sd/spi flash.
    But now the mainline u-boot has no pcie driver and no nvme support in spl.
     
    I have found the radxa guys using their u-boot in spi flash to boot kernel from nvme. But their pcie driver(https://github.com/radxa/u-boot/commit/096f2c16bbfa24c93a4c87e31334d5b5064dfd0a) has a limitation: It can not be used in u-boot spl, or it would not function properly in u-boot proper and fail the boot. 
    After some frustrating tryings and compare with the linux driver, I found that the port initialization process was short cutted and causing the reinitialization malfunctioned. After this correction the pcie driver can be used in spl: it can be reinitialized correctly in u-boot proper.
     
    Bring nvme support into spl is just a mimic from the spl_mmc and spl_usb driver.
     
    Another patch for fixing spl_ext as I want the u-boot.itb and kernel in a ext4 partition on nvme but the existing spl_ext can not load the u-boot.itb properly.
     
    With these patches I can boot nanopc-t4 with u-boot.itb and linux kernel in nvme boot partition and only the u-boot tpl/spl in emmc.
     
    Btw, now the vidconsole of the mainline u-boot is working on rk3399, but usb phys are still missing.
     
     
    pcie.patch rk3399_boot_nvme.patch spl_ext_fix.patch spl_nvme.patch
  14. Like
    aaditya reacted to balbes150 in Kernel 5.x.x and rk3399   
    The clock or priority of using cores may have been fixed.
  15. Like
    aaditya reacted to piter75 in Kernel 5.x.x and rk3399   
    I wonder what was actually changed to fix this.
    Nonetheless we will keep our changes in u-boot for the "current" target which is v5.4.x
  16. Like
    aaditya reacted to balbes150 in Kernel 5.x.x and rk3399   
    In kernel 5.7 without u-boot changes, the startup time is fixed.
  17. Like
    aaditya reacted to Tido in RockPi 4b 'board bring up'   
    Hi,
     
    I try to set up the server of Armbian_20.02.1_Rockpi-4b_buster_current_5.4.20.img -  as the boot was very slow I wanted to see the systemd-analyze plot
    systemd-analyze plot > RockPi4B_boottime-$(date +%Y%m%d_%H%M%S).svg Bootup is not yet finished (org.freedesktop.systemd1.Manager.FinishTimestampMonotonic=0). Please try again later. Hint: Use 'systemctl list-jobs' to see active jobs tido@rockpi-4b:~/just_data$ systemctl list-jobs JOB UNIT TYPE STATE 109 rk3399-bluetooth.service start running 1 graphical.target start waiting 110 systemd-update-utmp-runlevel.service start waiting 2 multi-user.target start waiting 4 jobs listed.  
    The system itself is updated and rebooted:
     
    RPi-Monitor doesn't work on Buster, but did so on   Armbian_20.02.1_Rockpi-4b_bionic_legacy_4.4.213_desktop.img
    Is this in relation with the 5.x Kernel?  Linux rockpi-4b 5.4.32-rockchip64 #20.02.11 SMP PREEMPT Tue Apr 14 17:30:19 CEST 2020
     
    Looks like bluetooth was responsible for the 'hanger'..    and a picture of the situation:
     
     

     
    It was difficult to get a proper plot, so that gThumb doesn't crash. I reached that goal by disabling:   sudo systemctl disable rk3399-bluetooth.service ;  the plot reduced from 1,4MB to 181kB.
    However, the boot itself takes an eternity, here some more details, from serial-getty@ttyS2.service (at 66 seconds) to launch  user-1000.slice  (at 134 sec.)  Booting completed at 145 seconds.
     

     
    and 68 seconds later it continues:

     
  18. Like
    aaditya reacted to Kwiboo in Mainline VPU   
    That branch was just something I played with for stateful decoding on RPi and Amlogic and not something that was finished nor do I expect it to be working.
     
    https://github.com/Kwiboo/FFmpeg/commits/v4l2-request-hwaccel-4.2.2 is the branch we use in LibreELEC. I was able to hw decode h264 with that branch and vanilla linux 5.6.6 on my RK3288 Tinker Board S a few hours ago.
    Also you should not need the --enable-libv4l2 configure flag, --enable-libdrm --enable-v4l2-request --enable-libudev should be enough to enable the request api hwaccels.
     
    What device are you testing on? I have not done any testing with rkvdec driver and there is no rk3328/rk3399 hantro driver for h264 in upstream media tree. Mpeg-2 and VP8 should work across rk3288/rk3328/rk3399.
    I do not expect h264 rkvdec to be working without changes to ffmpeg since there was some flags that got changed and now do not match between upstream rkvdec driver and my ffmpeg branch.
     
    I am hoping to get some time this weekend to update ffmpeg to work with rkvdec and hopefully submit the initial hantro h264 decoder for rk3328/rk3399 vpu2 to upstream.
  19. Like
    aaditya reacted to Myy in Mainline VPU   
    Same thing here.
     
    As always, I think it will come down to :
     
    Generating a H264 sample frame Looking at the documentation about how to send this to the driver Get the result  
    But everytime I think about the 2 first steps, I'm like... "Ugh... do I really have to do this ?".
     
    If that's still the case with the 5.7, I'll try to build a test framework.
     
    Quite frankly, I looked at the FFMPEG patches and I still don't know how the FFMPEG select the right decoder in the first place.
    As with all big projects, there might be a few "magic tricks" here and there to do the whole auto-selection of each component with the least amount of code.
    And that's without counting the fact that "ffmpeg -hwaccels" list another kind of "hwaccels" so you won't know anything based on that output.
     
    I also heard there were a "libva" library built around V4L2 request system. I guess this might worth a try, if it still exists and is still developed.
  20. Like
    aaditya reacted to tkaiser in SD card performance   
    In this 'Let's start a collective benchmark' thread might appear a few other results (and 4 cards are already there that are missing here): 
     
    But IMO we can already sum it up: 
    On boards that only implement the slowest SDIO mode (4 bit @ 50 MHz) the SDIO interface between SoC and SD card becomes the bottleneck when we're talking about sequential transfer speeds. You won't exceed ~23MB/s anyway. Therefore choosing cards where sequential write/read exceed this treshold is somewhat useless unless you use them also somewhere else where the host is capable of higher speeds (this was one of my former use cases: burning OS images in minimum time with +80 MB/s on my laptop -- now mostly irrelevant since FEL/NFS booting is way more fast and convenient when it's about testing new Armbian images) Many 'normal' SanDisk, Toshiba and Transcend cards aren't that fast and show a strange random I/O write weakness with 16k record size (does not apply to the more/most expensive series from the same vendors!) The speed differences when we're talking about small record sizes (the typical card accesses when you put your rootfs or user homes on SD card) vary a lot, especially when it's about random I/O and especially random writes To my surprise the rather cheap Samsung EVOs in our scenario were as fast as the more expensive EVO+ (these show higher potential sequential performance you can't make use of if the SDIO implementation is already the bottleneck) and outperform the even more expensive Samsung Pros in most areas. The EVO's sequential write speeds are advertised as '10 MB/s' but in reality that's something +20 MB/s at least with the few samples we tested with The top performer was Hardkernel's eMMC module combined with their Micro SD adapter. Sequential transfer speeds limited as with the others but random I/O simply rocks. You get what you pay for  Things to mention:
    Boards exist that do not share the slow SDIO limitation as our test boards using Allwinner's A20. On these random I/O might be nearly identical but the sequential speed limitation of ~22/23 MB/s isn't existent. With these boards you might see huge differences when using more expensive branded cards as long as we're talking about sequential transfer speeds (writing/reading huge amounts of data constantly) Regarding more recent SoCs you always have to differentiate between SoC and implementation/board. For example Allwinner's cheap 64-bit A64 is able to use the faster SDIO modes. But on cheap boards like Pine64 this isn't implemented (requires on-the-fly voltage switching between 3.3V and 1.8V for the faster modes). A64 is also able to access eMMC which could be magnitudes faster than SD cards. But since some of the needed eMMC pins are already used for other stuff on the Pine64 you're limited to the slowest SDIO access mode (which also means: all performance numbers above are valid for Pine64 -- I did some cross checks to confirm) Please keep in mind that the Kingston results above as well as all results for cheap 'normal' SanDisk, Toshiba or Transcend cards are hard to interpret. Kingston buys flash chips and controllers on spot markets and combines whatever is cheap at the moment. Therefore you get the irrelevant sequential speeds as advertised but random I/O might vary between different batches a lot (please remember: On SBCs random I/O is more important) Same applies to the cheap SanDisk, Toshiba and Transcend cards, especially if the tested cards are a few years old. Chances are great that you now get a card that is labeled identical but features both a new controller and new NAND chips that are many times faster when we're talking about random I/O Always remember that there are a few renowned storage brands that just buy bunches of unknown flash chips to combine them with unknown controllers. Both performance and reliability might vary a lot between different batches Then there exist manufacturers that own NAND factories, produce their own controllers, have engineers that do not just think about optimal combinations but realize them and ship final products. Think about the difference to the aforementioned group when buying cards And finally... reliability:
    You read all of the above and thought 'Well, what can be wrong ordering 5 of these cheap and performant EVO?' Maybe, that you get something different. Fraud/counterfeit cards are still a massive problem, so always test any card you buy directly after purchase. Always! No excuses! It's really easy and worth the efforts (more info) What about longevity? SD cards were made for cameras/recorders (sequential transfers, access pattern: mostly idle). This is an absolutely different use case than using these cards with an SBC, especially when a lot of random I/O happens (Armbian already helps here with a rather high commit interval: with our defaults all disk related changes are collected and then written to the card just every 10 minutes) I talked recently to someone who deploys lots of devices built of SBCs relying on SD cards. His conclusion: Never ever buy anything again but SanDisk Extreme Plus (not Pro -- yes, those that are twice as expensive ). The costs to replace a broken card at a customer's location are many times higher than buying reliable hardware in the beginning What to do if this is not your situation but you still care about reliability/longevity? You can try to do burn-in tests (maybe lasting a few months/years of continual random writes/reads and results with no meaning since the manufacturer exchanged the controller and/or NAND dies in the meantime) or you take the trust the vendor has into his own products into account. Choosing cards with a warranty of 10 years or even more is not the worst choice in such a situation.
  21. Like
    aaditya reacted to tkaiser in SD card performance   
    Warning: This whole thread is only about historical information now since it's 2018 and we can buy inexpensive and great performing A1 rated SD cards in the meantime. Buying anything else is a mistake so directly jump to the end of the thread for performance numbers and recommendations.
     
     
     
    Edit: See an early 2017 update at the end of the thread regarding new SD specs also covering random IO performance.
     
    Edit 2: Some thoughts/observations on lifespan/reliability of SBC storage: http://tech.scargill.net/a-question-of-lifespan/ (see also/especially the comments there)
     
    Edit 3: CNX Software picked up recent performance reports (eg. by Andreas Spiess) and other important issues around SD cards: http://www.cnx-software.com/2017/06/13/micro-sd-cards-for-development-boards-classes-tools-benchmarks-reliability-and-tips-tricks/
     
    Edit 4: See an early 2018 update testing real world A1 performance class products at the end of the thread.
     
    Edit 5: See here and there for some rather boring but very important information about Armbian's tries to prevent SD cards wearing out too fast.
     
     

     
    Preparations:
     
    I tested 8 different SD/TF cards under identical conditions. I created an Armbian 5.07 image to be used on Banana Pi (A20 SoC with 4.4.6 kernel, ext4 rootfs (Armbian defaults == no journal), 960MHz scaling_max_cpufreq, scaling_governor == performance. All test runs were done using 'iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2' and monitored using 'sudo iostat 5' for anomalies (none detected).
      Kernel version matters (since with Allwinner's 3.4 kernel sequential throughput is limited to ~16MB/s, with mainline kernel we get close to Banana Pi SDIO implementation's max: ~23MB/s) and filesystem settings matter too (enabled journal for example slows down 4K writes a lot).   Sequential speeds:     Random I/O:     The 4 Samsung cards were bought within the last 3 weeks and manufactured between 09/2015 and 12/2015 according to the card's metadata. Interesting observation: I used three of these cards the first time and they all show identical behaviour especially regarding writes with small record sizes: pretty slow in the beginning and getting faster over time (the Samsung Pro for example started with only 1400KB/s 4K writes and 3 runs later the same test showed 3270KB/s -- maybe an indication that some sort of calibration happened. Anyway: I know why I always repeat tests and do not rely on a single test run)   Sequential speed mostly irrelevant / random I/O differs and matters a lot!   The SanDisk Extreme Pro has been bought nearly 3 years ago. This card shows superior sequential read/write performance compared to the three Samsung EVOs. But only when used in combination with a host that can make use of these speeds. My MacBook writes 4 times faster an OS image to the Extreme Pro compared to the EVOs. But this doesn't matter at all since the SDIO implementation of the board in question is limited to ~23MB/s (50MHz @ 4 bit). The same sequential write/read speed limitation applies to most SBCs since to be able to exceed this slow mode the voltage the SD/TF card is fed with would've to be adjusted (default 3.3V, the faster modes require a dynamic switch to 1.8V instead which some/most SoCs can perform but if the SBC vendor doesn't implement this you're limited to ~23MB/s).   Therefore cards labeled as being capable of "up to 90MB/s" do not perform different than those that can only do "up to 20MB/s" as long as we're talking about sequential transfers since the SD card interface is already the bottleneck. But since we're using SD/TF cards not in cameras but as storage media for the rootfs of an SBC something different is more important: Random I/O. And here performance of cards that are labeled identical ('class 10' for example) differs a lot.   All 4 Samsungs outperform the other cards easily in this area. The SanDisk Extreme Pro can not compete regarding random I/O compared to superiour (but mostly irrelevant) sequential transfer speeds. And funnily the 3 other cards show horribly slow random write performance, especially with 16k record size. According to card metadata the 2 Intenso are oemid 0x5048 / manfid: 0x000027 (cheap crap known to die way too early) and I would believe the SanDisk 'class 10' card is a fake or at least uses the same controller as the 2 Intenso since 16K random writes are also way slower than 4K writes.   Detailed results (summary table also available as .ods, .xlsx or .txt):   Samsung Pro 64GB (brand new) http://sprunge.us/DEYd   Samsung EVO+ 64GB (brand new) http://sprunge.us/NLQd   Samsung EVO+ 32GB (brand new) http://sprunge.us/heGL   Samsung EVO 64GB (already used some time) http://sprunge.us/DUOS   SanDisk Extreme Pro 8GB (already used some time) http://sprunge.us/ZPFZ   SanDisk 'Class 10' 8GB (already used some time) http://sprunge.us/OHjT   Intenso 'Class 10' 16GB (already used some time) http://sprunge.us/LUMZ   Intenso 'Class 4' 4GB (already used some time) http://sprunge.us/GbAY   Some updates from Igor (still showing superiour EVO results but the clear winner is ODROID's eMMC module with SD card adapter):   Transcend Premium 300x 16GB (almost new) http://sprunge.us/UcSD  
     
     
    Sandisk Extreme Pro 8Gb (almost new) http://sprunge.us/aDJJ
     
     
     
    Hardkernel eMMC 8G via SD reader (brand new) http://sprunge.us/SHXF
     
     
     
    Sandisk Ultra 8Gb (old and very used) http://sprunge.us/OWZf
     
     
     
    Sandisk 8GB (almost new) http://sprunge.us/iViT
     
     
     
    Sandisk 8G (new) http://sprunge.us/XHjj
     
     
     
    Transcend 8Gb (used) http://sprunge.us/NTRT
     
     
     
    Samsung EVO 32Gb (brand new) http://sprunge.us/bTQh
     
     
        Further readings: http://www.bunniestudios.com/blog/?page_id=1022 http://thewirecutter.com/reviews/best-microsd-card/ http://www.jeffgeerling.com/blogs/jeff-geerling/raspberry-pi-microsd-card http://www.bradfordembedded.com/2014/05/flashbenching/ Conclusions:
    If the board's SD card interface is the bottleneck since it's not supporting the faster SDIO modes using expensive cards that exceed the interface's maximum sequential bandwidth is useless. An expensive Samsung Pro Plus won't be faster than a way more cheap EVO when it's about sequential transfer speeds since you will stay at ~22MB/s anyway Sequential read and especially write speeds are all the SD association's speed ratings are about (to ensure reliable recording of videos/images in cameras/recorders) When an SD card is used in an SBC sequential speeds aren't that important. It's all about random I/O, especially with small block sizes (reading and writing small random chunks of data from/to the card) No commonly used 'random I/O' speed ratings exist so you have to check the card in question prior to usage or rely on appropriate benchmarks (see the two links directly above). Again: the 'speed class' won't tell you anything. You can get two different 'class 10' cards that differ by 500% or even more regarding real world storage performance (again: random I/O matters). In the example above the Intenso 'class 10' card is 385 slower compared to the EVOs when it's about 16K random writes (good luck if you have a database running that uses this page size) Interestingly more expensive cards are outperformed by cheaper ones (the EVOs show a better overall performance compared to the Samsung Pro since sequential speeds are limited by the interface) One extreme example: Using an identical cloned installation that was somewhat outdated on the small 4GB Intenso card and on the 64GB EVO resulted in the following times for an 'apt-get upgrade' (+200 packages): EVO less than 6 minutes vs. 390 minutes (yes, ~6.5 hours) with the Intenso. The time to finish depends largely on fast random writes. It's easy to test the card in question when running Armbian since we ship with iozone. Therefore simply execute the iozone call from the first paragraph after logging in as a normal user. Starting with Armbian 5.06 a even better method exists that also tests the whole card for errors: armbianmonitor -c will report precisely both performance and health state of your card
  22. Like
    aaditya reacted to balbes150 in RockPi4B - No audio from 3.5mm Jack   
    I added everything you used to DTS a long time ago, but the sound didn't work for me (due to the lack of settings for alsa), I thought my DTS settings weren't correct. I'm wondering how you found (defined) these parameters ? 
  23. Like
    aaditya reacted to balbes150 in Build Armbian with Panfrost   
    Strangely, when you build mesa-20, everything goes correctly, but after installing mesa, the old mesa-19 remains. Something changed in the rules, how do I install the new version ? Previously, the instruction worked correctly and mesa started using Panfrost. By the way, installation from repositories of the latest mesa-20 also does not use Panfrost.
  24. Like
    aaditya got a reaction from Werner in Build Armbian with Panfrost   
    Thanks for the instructions @NicoD!
     
    I modified the mesa build options to enable egl:
    meson -D egl=true -D gles1=true -D gles2=true -D shared-glapi=true -Ddri-drivers= -Dvulkan-drivers= -Dgallium-drivers=panfrost,kmsro -Dlibunwind=false -Dprefix=/usr build/  
    With egl one can compile and run git version of supertuxkart.
  25. Like
    aaditya reacted to SteeMan in Infrastructure needed for releasing new kernels for Armbian for TV Boxes   
    Are you willing to take on this task and do this work?  I would say it is clear that the current maintainers here do not see this as a good investment of their time.  This is open source, and the best way to get something you need in open source is to step up and do the work and then contribute it back to the community.
     
    A couple of additional thoughts on your request:
    1) From what I have observed and know of the state of android on these TV boxes is that the dtb's from android are fairly worthless in helping getting things working under mainline kernels with armbian.  Everyone assumes this is not the case, but I haven't seen anything to indicate otherwise.  The gulf between ancient android based kernels and drivers (without source code in most cases) and modern mainline kernels is vast.
    2) You are making an assumption that "pushing adoption" is a good thing.  The way things currently stand, there are not sufficient people on these forums with the desire and knowledge to provide end user support for the existing new users much less a larger quantity of new users in the future.  What is needed now is people willing to answer the basic questions that new users post here, and to work on high quality documentation and tutorials (and maintain them as things change), so that the core developers can be relieved of the burden of providing this information so that they can spend more time moving the project forward.