aaditya

Members
  • Posts

    13
  • Joined

  • Last visited

Reputation Activity

  1. Like
    aaditya reacted to Gareth Halfacree in No "Install" option in armbian-config - how to upgrade bootloader?   
    My Helios64 has been booting from an M.2 drive since I got it, and while I've been doing regular apt-upgrades I've been ignoring the bootloader. This post suggests that could be a problem, so I figured I'd upgrade the bootloader through armbian-config. Trouble is, I can't.
     
    I can load armbian-config without error, but when I go into System there's no Install option any more. All I have are Freeze, Nightly, Lowlevel, Bootenv, CPU, Avahi, Hardware, Other, SSH, Firmware, ZSH, Default.
     
    Is there another way to ensure the bootloader is up-to-date?
  2. Like
    aaditya reacted to Yajaiku in Firefox-esr Netscape.cfg error   
    I fixed this on my system by changing a line in my /etc/armbian/firefox.conf
    from this:
    pref("browser.cache.memory.capacity", "-1");
    to this:
    pref("browser.cache.memory.capacity", -1);
     
    What I did was used strace on firefox to a file, grepped the file for .cfg, found a link to firefox.conf, commented out lines by binary halving until I found the right line,
    and then futzed the line until firefox would start without the error.
     
    Hope this helps, good luck!
     
    -Y
  3. Like
    aaditya reacted to atomxxx in Firefox-esr Netscape.cfg error   
    Anyone know how to fix this.  A known problem sometimes.  Only been able to find a fix for Windows. 
     
  4. Like
    aaditya reacted to Heisath in armbian upgrade from buster to bullseye   
    I did the upgrade from Buster to Bullseye. 
     
    As far as steps:
    - Backup
    - apt update & full-upgrade
    - Disable /etc/apt/sources.list.d/armbian.list all entries to stop armbian from upgrading
    - Use normal debian upgrade steps -> Change release in /etc/apt/sources.list 
    - apt update & full-upgrade
    - Restart, validate working system
    - Update /etc/apt/sources.list.d/armbian.list with new release (buster->bullseye)
    - apt update & full-upgrade
    - Should be done. 
     
    Take extra care for some new/renamed packages. armbian-bsp-cli-<BOARD> is new. Older armbian-root-* packages dont exist anymore (I think).
     
    For me this worked flawless, you might have to fix some dependency problems, and make sure at least some working version of armbian-image-* armbian-dtb-* is installed before rebooting.
  5. Like
    aaditya reacted to NicoD in Armbian Donations   
    Donations reached the goal. 
    To everybody who helped. Big thank you. This will be well used. I've seen the server and it's a monster.

    Next goal maybe different desktop implementations, with GPU and maybe VPU if possible. Who could we hire? What cost?
     
    But before that there's already enough new things coming soon. And the server will be in good use or that.

    From the whole team. Thank you.
    NicoD
  6. Like
    aaditya reacted to TRS-80 in Booting ROCK Pi 4(A/B/C) with mainline u-boot in SPI, NVMe and Armbian v20.11.x   
    (emphasis mine)
     
    That's the spirit!   
     
    IMO, everyone who play with SBC should own at least one.  In fact, it's on my list to add that to the docs, right in "Getting Started" section...
  7. Like
    aaditya reacted to piter75 in Booting ROCK Pi 4(A/B/C) with mainline u-boot in SPI, NVMe and Armbian v20.11.x   
    With Armbian v20.11 one can write mainline u-boot image to board's SPI and enjoy booting nvme drives without any mmc devices.
    Prerequisities: ROCK Pi 4(A/B/C) v1.4 or 1.3 with SPI soldered in (v1.3 comes without SPI flash from the factory).
     
    If you already have Radxa's u-boot written to SPI you need to short pins 23 and 25 for Armbian to boot Boot fresh image of Armbian v20.11.x for ROCK Pi 4(A/B/C) Add the following lines to /boot/armbianEnv.txt overlays=spi-jedec-nor param_spinor_spi_bus=1 Reboot If you shorted 23-25 pins in 1.) then: disconnect them after the ROCK Pi 4 fully boot's  enable spi-nor by executing (as root):
    echo spi1.0 > /sys/bus/spi/drivers/spi-nor/bind verify that the SPI mtd interface is enabled by running
    ls /dev/mtdblock0 if the last command does not list any file then something went wrong between 3.) and 5.) Run nand-sata-install choose option: "Boot from SPI - system on SATA, USB or NVMe" choose NVMe partition, eg. /dev/nvme0n1p1 accept erasing of the choosen partition with "Yes" choose fs type (tested with ext4) wait a few minutes for rootfs transfer to chosen partition choose writing SPI bootloader with "Yes" confirm that you want to flash it with "Yes" wait ~60 seconds for writing choose Exit Reboot Enjoy Armbian booting with SPI / NVMe  
    Why bother with mainline u-boot?
    It is known to boot some NVMe drives that legacy u-boot from Radxa has issues with, eg. SAMSUNG 970 EVO Plus and SAMSUNG PM981.
    This does not mean that all NVMe drives are supported, YMMV.
     
    Which NVMe drives are known to be working?
    Corsair MP510 240GB/480GB/960GB
    Gigabyte SSD M.2 2280 PCIe x2 Model:GP-GSM2NE8128GNTD
    HP SSD EX900 M.2 NVMe 120GB. Model: 2YY42AA#ABB
    Intel SSD 660p Model:SSDPEKNW512GB
    Kingston A1000 SSD 240GB (PHISON PS5008-E8-10)
    Kingston A2000 M.2 2280 PCIe NVMe
    PNY 250GB XLR8 CS3030 M.2 NVMe SSD PCIe Gen3 x4
    Sabrent Rocket 256GB NVMe PCIe M.2 2280
    Samsung 970 EVO Plus SSD 250GB M.2 2280, PCIe 3.0 x4, NVMe, 3500/2300 MB/s
    Samsung PM981 256GB
    XPG SX6000 Lite 128GB (ASX6000LNP-128GT-C)
     
    Why not using Radxa's u-boot SPI image?
    Ambian's u-boot configuration is incompatible with Radxa's SPI image
     
    Why Armbian is using u-boot that is incompatible with Radxa's?
    It uses mainline u-boot with Open Source TPL/SPL/proper and BL31 from Rockchip packaged into u-boot and we may switch to using open source ATF instead of the BL31 in the future.
     
    Can I boot Radxa's images with Armbian's u-boot written to SPI?
    Yes. Armbian's SPI u-boot is compatible with Radxa's images available here: https://github.com/radxa/rock-pi-images-released/releases
    It may not be compatible with some older images (released before July 2020) because of the device tree filename change.
  8. Like
    aaditya reacted to Werner in Armbian 20.11 Tamandua   
    Release info:
    https://www.armbian.com/newsflash/armbian-20-11-tamandua/
     
    Downloads:
    https://www.armbian.com/download/
     

  9. 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.
     
     
  10. 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/
  11. 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!
  12. 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!
     
     
     
     
  13. 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.
  14. 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?
  15. 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.
     
  16. 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.
  17. 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.
  18. 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 :-)
  19. 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.
  20. 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.
  21. 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
  22. Like
    aaditya reacted to balbes150 in Kernel 5.x.x and rk3399   
    The clock or priority of using cores may have been fixed.
  23. 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
  24. 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.
  25. 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: