Posts by metaron

    OK I found the procedural error that caused /dev/vcsm not to appear; Step 3 in the post from Morphy above:

    I'll see if I can summarise what I did to get it working as I was a bit confused by a couple of things:


    1. Download LE9: https://releases.libreelec.tv/…LEC-RPi2.arm-9.2.8.img.gz
    2. Download LE11 Nightly: https://test.libreelec.tv/Libr…y-20211210-7f19d9f.img.gz
    3. Copy "bcm2710-rpi-3-b.dtb" from the LIBREELEC partition on the LE11 SD card to the same partition on the LE9 SD but rename to "bcm2710-rpi-zero-2.dtb"....

    If you copy brcm2710-rpi-3-b.dtb from the LE9 partition rather than from the LE11 partition, it works.

    (Stands to reason; dtb and kernel version belong together).

    in kodi crash log:

    Hello,

    Got LE 9.2 working on Pi Zero 2 using the method provided by @Synerworks but Kodi crashes every time I try to play a video.

    Code
    mmal: mmal_component_create_core: could not find component 'vc.ril.video_decode'

    I also noticed /dev/vcsm is missing. I guess this is why video playback fails but have no idea how to make /dev/vcsm available.

    Well I get pretty much the same with my zero2 as well. Everything seems to work fine until I try and play a video, then kodi crashes:

    Code
    ERROR: CMMALPool::CMMALPool Failed to create component vc.ril.video_decode

    I've tried giving the GPU the same memory as my RPI3 which is running the same LE 9.2.8 build by tweaking config.txt to:

    Code
    #  gpu_mem_512=160
      gpu_mem_512=256

    but no cigar.

    I can confirm, like powiedzmi, I haven't got a /dev/vcsm (although my RPI3 does)

    I did read on https://archlinuxarm.org/forum/viewtopic.php?f=9&t=14931 that similar issues occur when there's something wrong with the firmware, so maybe there's a change in later firmwares that means this hack won't work anymore?

    My current firmware version (wifi working, no /dev/vcsm or video playback) is:

    Code
    raspberrypi-firmware soc:firmware: Attached to firmware from 2021-11-16 17:41, variant start_x
    raspberrypi-firmware soc:firmware: Firmware hash is 99c5aad7da0d1e3b2c28669a3941db77734b9f2d

    Can anyone confirm video playback working using this hack on a zero2, in which case, which versions of bcm2710-rpi-3-b.dtb, fixup.dat and start.elf did you use and what does dmesg report for your firmware version?

    Notes:

    I also tried using the the most recent LE nightly resulting in a firmware version from 1/12/2021, but the symptoms are the same.

    I don't have any of the extra codec licenses enabled on either the RPI3 or the Zero2

    Just managed to follow Synerworks latest post above successfully with one minor addition. I also copied brcmfmac43436-sdio.clm_blob into the /storage/.config/firmware/brcm folder (re-naming it brcmfmac43430-sdio.clm_blob) to remove a dmesg error.

    (I had previously associated this missing file with not getting any wireless network adapters detected, but I guess that must have been finger trouble elsewhere)

    metaron - any further news on tracking down the kernel commit responsible?

    Sorry - I was getting closer but real life got in the way about a month ago and I haven't had a chance to to finish my 'slow' bisect yet. I'm still under the cosh a little as it were.

    Given the mess I got into last time I wanted to get to a 100% certain position, but it may not be that simple. Given that this merge commit appears to contain a bunch of merge commits on merge commits I'm just following bisect 'blind'. I may be close but I haven't a clue.

    It may not prove to be as simple as 'this commit introduced the problem' as I've seen some slightly less severe artifacts on the way to get here. If USB things have been re-written somewhere along the way (which the titles of some of the commits appear to suggest) it may be that a re-write had bugs which were fixed one at a time, leaving the feature we're seeing once all the changes had been incorporated:

    Progress so far this time appears to be as follows:

    git bisect start

    # good: [e6dce825fba05f447bd22c865e27233182ab3d79] Merge tag 'tty-4.9-rc1' of git://http://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty

    git bisect good e6dce825fba05f447bd22c865e27233182ab3d79

    # bad: [e6445f52d9c8b0e6557a45fa7d0e8e088d430a8c] Merge tag 'usb-4.9-rc1' of git://http://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb

    git bisect bad e6445f52d9c8b0e6557a45fa7d0e8e088d430a8c

    # good: [54a2ec67f1db62a763f57b7f8f2e82874f5f358b] usb: ohci: Allow ohci on omap5 also

    git bisect good 54a2ec67f1db62a763f57b7f8f2e82874f5f358b

    # good: [e6be244a83211f3a9daaf5e29ee97fe0bf1efe5a] usb: gadget: uvc: add V4L2 dependency

    git bisect good e6be244a83211f3a9daaf5e29ee97fe0bf1efe5a

    # good: [6ba43c2919613dad1a880fcab19cda1d68a5ce3d] phy-sun4i-usb: Add support for phy_set_mode

    git bisect good 6ba43c2919613dad1a880fcab19cda1d68a5ce3d

    # bad: [eeb7df270f1c4629b52fc1f98035fe9e7fe63df2] include: extcon: Fix compilation error caused because of incomplete merge

    git bisect bad eeb7df270f1c4629b52fc1f98035fe9e7fe63df2

    Well I didn't trust the results I got last time so I've tried to repeat the process again from scratch:

    Code
    git bisect start
    git bisect good e6dce82
    git bisect bad e6445f5

    But I got all the way through without finding a single bad build.

    Obviously what I thought was a guaranteed environment to reproduce the problem quickly isn't.

    I did mark some of the earlier builds as bad the first time around, but unfortunately didn't make an independent record of the hashes involved.

    (I have this time, but none appear to have failed...)

    Is there a log somewhere I might be able to resurrect? (git bisect log obviously only shows the most recent bisect)

    I've also noticed that running git status or git bisect goot/bad, which results in 100% dual core cpu usage and significant disk access, while watching video is a good confirmation (the mythtv video storage directory and kernel git repository are on the same drive).

    • When I've got a 'bad' version I get significant video artifacts as soon as disk access starts.
    • When I've got a good version I get interrupted playback but no artifacts and the audio having got very out of sync eventually catches upwithout any noticeable video corruption.

    What's confusing me at the moment is that I can't currently get any artifacts to appear with 54a2ec67f1db62a763f57b7f8f2e82874f5f358b. I've reset the bisect and am trying a fresh build based on this commit to see if that shows the artifacts I expect, but am a bit dubious that the bisected builds actually worked all the time (several of the 'good' builds were rather quick compiles without much if any content which isn't what I was expecting)

    Watch this space....

    Code
    blackbox linux #git clone --unshallow
    ....
    blackbox linux # git bisect start
    Already on 'post-usb-change'
    blackbox linux # git bisect good e6dce825fba05f447bd22c865e27233182ab3d79
    blackbox linux # git bisect bad e6445f52d9c8b0e6557a45fa7d0e8e088d430a8c
    Bisecting: 184 revisions left to test after this (roughly 8 steps)
    [54a2ec67f1db62a763f57b7f8f2e82874f5f358b] usb: ohci: Allow ohci on omap5 also

    That looks more like it....

    e6445f52d9c8b0e6557a45fa7d0e8e088d430a8c is the first bad commit

    which is what I knew already ... ??? ...

    ab21b63 HEAD@{0}: checkout: moving from decc5360f23e9efe0252094f47f57f254dcbb3a9 to ab21b63e8aedfc73565dd9cdd51eb338341177cb

    decc536 HEAD@{1}: checkout: moving from a2f195a73eba807006fb0cb882ecb552c06eea00 to decc5360f23e9efe0252094f47f57f254dcbb3a9

    a2f195a HEAD@{2}: checkout: moving from e8624859dde2ad07633dac7ec86629a516411ea1 to a2f195a73eba807006fb0cb882ecb552c06eea00

    e862485 HEAD@{3}: checkout: moving from 2ad9d544f2497a7bf239c34bd2b86fd19683dbb5 to e8624859dde2ad07633dac7ec86629a516411ea1

    2ad9d54 HEAD@{4}: checkout: moving from post-usb-change to 2ad9d544f2497a7bf239c34bd2b86fd19683dbb5

    Any idea what I'm doing wrong?

    @popcormix , following your instructions I get:

    Code
    blackbox linux # git bisect start
    blackbox linux # git bisect good e6dce825fba05f447bd22c865e27233182ab3d79
    blackbox linux # git bisect bad e6445f52d9c8b0e6557a45fa7d0e8e088d430a8c
    Bisecting: 14 revisions left to test after this (roughly 4 steps)
    [2ad9d544f2497a7bf239c34bd2b86fd19683dbb5] cdc-acm: hardening against malicious devices

    Which seems slightly less than the 184 steps you were expecting expecting...

    Code
    git log  e6445f52d9c8b0e6557a45fa7d0e8e088d430a8c^..e6445f52d9c8b0e6557a45fa7d0e8e088d430a8c

    Only shows 31 individual commits. Might it be because I cloned with --depth=1 then ran --deepen=100?

    Anyhow will see what this bisecting lark turns up.

    Ok, some further investigations. I've moved from the pi2 to a core2 x86 PC, using the same DVB-T2 USB stick.

    (To run a vanilla kernel and therefore get closer to the commit which introduced the problem)

    blackbox linux # git remote -v

    origin git://http://git.kernel.org/pub/scm/linux/…inux-stable.git

    I found a suspicious looking commit:

    commit e6445f52d9c8b0e6557a45fa7d0e8e088d430a8c

    Merge tag 'usb-4.9-rc1' of git://http://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb

    Pull usb/phy/extcon updates from Greg KH:

    "Here is the big USB, and PHY, and extcon, patchsets for 4.9-rc1....

    So I built two kernels.

    One based on e6445f52d9c8b0e6557a45fa7d0e8e088d430a8c and one based on the previous commit e6dce825fba05f447bd22c865e27233182ab3d79

    Based on e6445f52d9c8b0e6557a45fa7d0e8e088d430a8c

    Within a few seconds of viewing BBC1 HD, there are the artifacts again.

    Based on e6dce825fba05f447bd22c865e27233182ab3d79

    no artifacts seen in about 5 minutes of viewing BBC1 HD

    Maybe gregkh can help identify which of the many changes it contains is the most likely culprit?

    Given that I also see corruption in the largest of mythtv's mysql database files (updated while recordings are in progress and hosted by me on a USB sitck) when using 4.9 based kernels (although much less frequently than the artifacts in recorded HD video), my money's on changes to the USB subsystem / interrupt priority rather than any tweaks to V4L code:

    -rw-rw---- 1 mysql mysql 331575000 Jun 3 22:08 /var/lib/mysql/mythconverg/recordedseek.MYD
    -rw-rw---- 1 mysql mysql 308227072 Jun 3 22:08 /var/lib/mysql/mythconverg/recordedseek.MYI

    I was getting rather too familiar with myisamchk -o as a command, needing to run it at least 3-4 times a month.

    Since switching back to 4.6 / 4.8 based kernels, I've not needed to use it once.

    rpi-update bcc6146e102d85b1aa214855ad7aae278d3bd269

    gets me:

    Linux pi2 4.9.0-v7+ #939 SMP Thu Dec 15 18:07:48 GMT 2016 armv7l ARMv7 Processor rev 5 (v7l) BCM2835 GNU/Linux

    And the artifacts are back.

    rpi-update 7a47836821b92efa569500b3382b1812082e42d3

    gets me:

    Linux pi2 4.8.13-v7+ #937 SMP Fri Dec 9 17:45:13 GMT 2016 armv7l ARMv7 Processor rev 5 (v7l) BCM2835 GNU/Linux

    No artifacts. Sticking with this build for now.

    Let me know if/when there's a test build / git hash to localize things further.

    rpi-update using: kernel: Bump to 4.3.24 · Hexxeh/rpi-firmware@bbd611a · GitHub gives me:

    andrew@pi2 ~ $ uname -a
    Linux pi2 4.9.24-v7+ #991 SMP Sat Apr 22 20:26:57 BST 2017 armv7l ARMv7 Processor rev 5 (v7l) BCM2835 GNU/Linux

    Not quite what gert and maroi are running. Anyone know how to track down #993?

    Like you gert, I don't have LibreElec on the PI2 - I record using Mythv and then playback using LibreElec on a different machine (an RPi B+)

    (Mythtv always records to disk first, even if watching 'live')

    By the way I'm still seeing artifacts with build #991 on the PI2.

    OK, so now I'm really confused. I've blown a jesse-lite image to a spare SD card, logged in and run:

    sudo apt-get install --reinstall raspberrypi-bootloader raspberrypi-kernel

    but ls /lib/modules shows me 4.4.50+ 4.4.50-v7+ (which isn't the 4.9.24 version maroi says he has on his box)

    Typing sudo apt-get dist-upgrade tells me 0 upgraded, 0 newly installed, o to remove and 0 not upgraded. - so that doesn't work either.

    Looking through Commits · Hexxeh/rpi-firmware · GitHub I can't find a commit for 4.9.24 - it seems to skip directly from 4.9.23 to 4.9.25.

    I'm running gentoo on my pi2 and not familiar with the debian way of doing things (I was going to cut and paste the kernel onto my pi2 using tar)

    @marol - how did you get 4.9.24 on your rasbian box?

    Edit: Maybe kernel: Bump to 4.3.24 · Hexxeh/rpi-firmware@bbd611a · GitHub is it?

    (It's a bit late now - will try again another day!)