usual user

  • Posts

  • Joined

  • Last visited

Recent Profile Visitors

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

usual user's Achievements

  1. Looks like the existing boot firmware on the emmc, for whatever reason, does not tolerate a valid MSDOS MBR on the emmc. If this is still valid, you can certainly replace the existing firmware with a suitable one, but since a functioning solution has already been worked out, it is certainly easier to use it.
  2. AFAIS you have inserted a populated partition table. Maybe the boot firmware now changes the boot flow according these values. To confirm that the presence of an MSDOS MBR already triggers it, just add the boot signature "55AA" to the last two bytes of the sector. If booting still does not work with an otherwise empty partition table, no MSDOS MBR can be used unless the existing boot firmware is also adapted.
  3. The first 440 bytes of the MBR are used for bootstrap executable code. The partition management relevant data starts at 0x01B8 and lasts till 0x01FF. Tools that create MSDOS master boot records usually insert code into the bootstap code area that is suitable for PC BIOS use, i.e. useless for Arm systems. Regardless of what you put in the first 440 bytes of the MBR, you still have a valid MBR with partition table entries. Only the last 72 bytes of the first sector have to be maintained therefor.
  4. I am running at an entire different user space. But this doesn' t matter. Also the exact kernel version doesn' t matter. The only thing that is really important is that the elements that are needed by the hardware are also built. dmesg tells you which components are used. Looking at kernel config does only tell wich modules are build, but not if they are realy used. E.g. my kernel is built with a large number of modules. With the help of initramfs it is suitable for all devices with aarch64 architecture. When the kernel is booting it will either probe the hardware or know via devicetree wich modules are required. The customizieing I am aplying is to pull display support and everything to mount the rootfs as build-in. This way I have early display support and I can run without initramfs. Everything else will be loaded later as module. In order to learn which components are needed, it is very helpful to have a dmesg from a running system.
  5. I run my NanoPC-T4 as a fully flagged desktop with all the bells and whistles. I have uploaded my dmesg so you have a reference what messages to expect. More components, not called HDMI, are required for display support. This is user space that tries to load kernel modules and expected when the modules are built in or already loaded by the kernel. dmesg
  7. Then why not start, @jock has announced new versions and the links on the first page are already up?
  8. I don't know what requirements Kivy places on the graphics stack, but since Panfrost achieves OpenGL ES 3.1 conformance on Mali-G52, it certainly makes sense to read this to understand what to expect from a lima-driven GPU. I still remember very well times when my GPU only reached almost 2.0 and the performance was quite moderate. With now 3.1 it's a big difference for daily desktop use, although my GPU isn't yet declared fully compliant. But since this is bleeding edge development, at least the current mesa mainline release is required in any case. If not even the main branch to use just implemented extentions. Kernel driver wise everything necessary should already be available and therefor mesa is where you are looking for GPU support improvements.
  9. Thank you for sharing the schedule. But no hurry, my daily use cases are already working anyway. I'm only doing this for my own education and as a preview of maybe landing features in Mainline. For me, it's the other way around. hwdec=drm yield high CPU utilisation for bbb_sunflower_2160p_30fps_normal.mp4 and hwdec=drm-copy yield low CPU utilisation. As the values are fluctuating heavyly it is difficult to provide absolut numbers. But anyway here are some rough values: bbb_sunflower_1080p_30fps_normal.mp4: gst-play-1.0 ~35% mpv --hwdec=none --hwdec-codecs=all ~40% mpv --hwdec=drm --hwdec-codecs=all ~38% mpv --hwdec=drm-copy --hwdec-codecs=all ~28% bbb_sunflower_2160p_30fps_normal.mp4: gst-play-1.0 ~35% mpv --hwdec=none --hwdec-codecs=all ~98% playing slow, sound out of sync mpv --hwdec=drm --hwdec-codecs=all ~98% playing jerky, sound out of sync mpv --hwdec=drm-copy --hwdec-codecs=all ~34% playing slow, sound out of sync This is on plasma desktop with wayland backend. Desktop CPU usage fluctuates around 8 to 15% without playing a video, so it's uncertain which CPU cycles are really associated with video playback. The utilization is always distributed almost evenly over all cores. Frequency scaling is not considered here. For reference here the values for lxqt desktop with native xorg backend: bbb_sunflower_1080p_30fps_normal.mp4: gst-play-1.0 ~25% mpv --hwdec=none --hwdec-codecs=all ~30% mpv --hwdec=drm --hwdec-codecs=all ~28% mpv --hwdec=drm-copy --hwdec-codecs=all ~18% bbb_sunflower_2160p_30fps_normal.mp4: gst-play-1.0 ~18% paying as diashow mpv --hwdec=none --hwdec-codecs=all ~98% playing slow, sound out of sync mpv --hwdec=drm --hwdec-codecs=all ~98% playing jerky, sound out of sync mpv --hwdec=drm-copy --hwdec-codecs=all ~22% playing slow, sound out of sync Conlusion: The VPU decoder is not the bottleneck, but setting up an efifcient video pipeline with proper interaction of the several involved hardware acellerators. For Xwindow with the modeset driver this seems not realy possible.
  10. Thank you for the offer @jock. But 5.14.0 wise I had all VPU relevant LE patches and even the drm ones applied. With gstreamer framework it is working, even for bbb_sunflower_2160p_30fps_normal.mp4 without any problem. It is mpv that seems not be able to cope with the hight data rate. Useing --hwdec=drm-copy makes the CPU utilization ramp up go away and the video plays smoothly, but to slow and the sound get out of sync. I don't think I am missing anything kernel wise. Just tried to drop 2000-v4l-wip-rkvdec-vp9 in favour of this more recent patchset. Resolving a merge conflict to apply the LE patches on top was easy: But the kernel build drops out with this: So I will stay at the status quo of LE patches on 5.15.0-rc1 for now and wait till they rebase. VPU wise everything from LE is in place and seems to work.
  11. Moved on to 5.15.0-rc1. But applying the LE patches makes the kernel unbootable for rockchip. I had now omitted 2001 also, as it no longer applies cleanly, and of course the cherry-picking 0010, which have landed. Guess I have to take a closer look at which patches are really important to me and see if they are the cause. With only linux-0011-v4l2-from-list, linux-1001-v4l2-rockchip and 2000-v4l-wip-rkvdec-vp9 applied the kernel keeps working. Although the drm patches seem interesting, I'll leave them out for now.
  12. I'm currently at gstreamer1-1.19.1, which works for my daily use cases flawless with the distribution package. But as soon as a deficiency should show up, it would be no big deal for me to rebuild with current master or pull in in-flight patches. But till then I will let the improvements trickle in via the regular updates. Out of curiosity, I just started two instances of gst-play-1.0 with different videos at the same time, and both videos play flawlessly at the same time. OK, the mixed sound is a bit confusing.
  13. Thank you @jernej for your detailed background information. In the past I didn't care much about ffmpeg driven video pipelines. I made several attempts, but because of the sparse documentation and not even the basic support in mainline, I gave up pretty quickly. I do this out of curiosity and for early use of future maninline support. So as long as I can't find information on how to use it in daily use cases, I'll ignore it again. At least I have now some kernel patches that benefit gstreamer framework that I can track till they land in mainline.
  14. Thank you @jock for your detailed explanation. Since I use a different distribution, your instructions don't apply to my environment, but I know how to do it for myself. I just need to know what to do and @jernej has already pointed this out (needed patches and build requirements). I haven't considered this aspect so far, as it hasn't been mentioned that LE patched headers are required. I just applied all the LE kernel patches and just omitted obviously not necessary ones. Because ffmpeg build flawless with the native headers, I moved on. I have installed round about twenty kernels at the same time and it will be decided at boot which one to use. Therefore, I only move in new headers when necessary. gst-play-1.0, ffplay and mpv now play bbb_sunflower_1080p_30fps_normal.mp4 with similar achievement. For gst-play-1.0 I know how to visualize the composed video pipeline. And due to the v4l2slh264dec (V4L2 Stateless H.264 Video Decoder) component in gst-play-pipiline.pdf I know for sure that hardware acceleration is used. So I guess the ffmpeg video pipeline is also using hardware acceleration. gst-play-1.0 plays bbb_sunflower_2160p_30fps_normal.mp4 with same CPU utilization. For ffplay and mpv CPU utilization ramps up significantly and frame drops are reported. The video also plays jerky. I can't say which components of the ffmpeg video pipeline is the limiting factor here. Because the kernel patches also benefit the gstreamer framework, I will probably continue to use them. Let's see what explodes when 5.15.0-rc1 is available next week.
  15. My kernel has now 0010, 0011, 0020, 1000, 1001, 2000 and 2001 LE patch applied. I don't see any significant change in behavior, so I can't say if the ffmpeg-driven video pipeline realy uses hardware acceleration. The mpv command of @kprasadvnsi is playing for me. In the mpv.log the Codec list mentions, "h264_v4l2m2m (h264) - V4L2 mem2mem H.264 decoder wrapper", but I don't know if this is used. Neither I don't know how to select which decoder (hantro, rkvdec) will be used, it's the first time I use mpv.