Posts by chewitt

  • mmu page fault on Odroid C2

    I got the YouTube add-on working again but I'm missing something to replicate the problem. All the "audio" content that I can find on YouTube also has video so I see normal video playback not audio with a visualiser. Can you share a link to something?

  • Wetek Hub - 11.0.4 - no passthrough of Dolby TrueHD (Atmos)

    IIRC the S905 chip in the Hub does not support the HD formats so cannot pass them through. The DD+/TrueHD streams contain a DTS (5.1) core with additional metadata; the core stream provides compatibility with hardware that doesn't support the full format so you still hear something. Note: no need to rename files if following the wiki instructions to create AMLGX "box" SD cards.

  • mmu page fault on Odroid C2

    Kodi provides instructions to draw shapes on-screen using OpenGLES and these instructions are translated by mesa into "jobs" that are scheduled and executed on the GPU cores through the lima driver. The non-exhaustive list of possible opportunities for bugs are: a) Kodi sending bad GLES instructions to the DRM layer (mesa), or b) Kodi sending valid GLES that mesa incorrectly translates into jobs, or c) mesa sends valid jobs that the lima driver does not correctly handle during execution.

    Changing the visualiser is "wagging the dogs tail to make the head move" and does not itself provide much of a clue where things go wrong. I need to see if I can resurrect the YouTube add-on (as it stopped working for me at some point and I switched to Tubed) to see if the issue exists on RPi5 too. If yes, it points to a Kodi issue as mesa effectively runs different code for the Mali 450 GPU in an S905 chip vs. the VideoCoreVII GPU in the RPi5, ergo a failure in both paths would be unusual and indicates something in Kodi-core or visualisation shader doing something wrong. If no (and I suspect it will be no) it's something lower in the stack and we'll need to capture debug job traces and share those with upstream maintainers to see if they can spot the problem.

    NB: Testing on the LE12 image is useful as we're typically running the latest lima/mesa versions so we elimiate any bugs that have already been resolved since the older LE11 versions.

  • Minix U9-H freeze on kodi loading page / black screen

    Amlogic mmc controller issues normally exhibit with high-speed card modes and faster speeds and the current/upstream U9-H device-tree is already defeatured to run at a minimum level. The usual way to rule out those issues with modern cards (that have fancy modes and such) is to test with an old, slow, low-capacity card. I have some 2GB cards which aren't much use for an install but are reliable for that kind of testing. Most vendor firmware will power-up the USB section in u-boot automatically which will make the AMLGX boot media discoverable and useable there too, so perhaps try with a USB stick instead of SD card.

    NB: For power-issues I'm thinking the device-tree description of how things are connected (which influences driver probing and power sequencing) might be off; not that the PSU itself is bad (although that would also cause problems). The vendor kernel has drivers for a Minix MCU chip which is not supported upstream; the MCU does handle some power things, but it's mostly low-level and the essentials are configured by u-boot so Linux shouldn't really need to care.

  • Explanation of the ffmpeg patches

    RPi3 and older have no hardware decode support for HEVC but the legacy display pipeline was tweaked (using never upstreamed patches) to offload some compute tasks to the GPU and this achieves enough headroom for low-bitrate 1080p HEVC adnd low-bitrate 720p DRM'd HEVC media to be software decoded. The current display pipeline hasn't reimplementated that (50,000 LOC) patchset becaue it would require a large effort and more importantly, the goal is run upstream-only or minimally-patched code and it was ultimately a clever hack that upstream maintainers aren't going to accept.

  • Anything better than a Pi4 currently?

    IIRC RPi 4/5 only support Vulkan under Wayland, and we do not run Kodi under Wayland because Wayland does not support refresh rate changing for optimal media playback. So yes FFMpeg added some support for DV but the devil is in the details and this is not a usable solution for our use-case. I'd also argue that using shaders is not "true" DV support; it's simply a way to get DV encumbered media to display with an acceptable (but not exact) on-screen appearance. True support requires knowledge of the proprietary stuff or a clean-room implementation. The former won't happen because it torpedo's Dolby's commercial model and the latter is rather unlikely since it will require a massive effort and the Linux community generally prefers to make a minimum acceptable effort when the target "standard" is vendor proprietary crap. I'll update/reword the wiki article a little to prevent further 2+2=5 conclusions.

  • [RPi5] USB SSD drive unmounting after a while

    If the device is booted from USB? and then the device unmounts the OS will mark things read-only and a bunch of things will stop working. Run "journalctl -f" and you might get lucky and see somehing in the journal before things start to fail. If you're unable to SSH in then it's likely the connection drops so you won't be able to run dmesg.

  • Official LE12 Test Images for Amlogic (Kodi-21)

    Quote from Shonk

    is gxm_q200_3g my best dtb? I have always used that in the past but dont know which one i should actually use

    It will probably work (other than BT). If it doesn't you'll (emphasis on the you) will need to experiment, but if chasing BT support you can skip the effort as I looked and there are no GXM device-tree files with support for QCA9377 modules in the upstream kernel so you won't find one. Running some fdtput commands from userspace can probably temp-fix the Q200 dtb file.

  • Minix U9-H freeze on kodi loading page / black screen

    Code
    [  512.554914] mmc0: card 59b4 removed

    ^ at that point the system is screwed because the OS is booted from the SD card device; hence all the "EXT4-fs error" messages that are logged. I'm only surprised it doesn't fail more completely/spectacularly.

    I have a hunch this is a power problem, but figuring it out might be a challenge. When you start Kodi the GPU is used for the first time which increases power demand on the system. The current assumption is that the box follows the Q200 reference design (the legacy device-tree suggests this: https://github.com/LibreELEC/devi…inix_neo_u9.dts) but there are probably differenes. I do have the schematics for the box, but I'm not the greatest reader of them.

    I'll send you a PM re the box.

  • Explanation of the ffmpeg patches

    The Pi devs are good at upstreaming their changes these days but there's always a delay between them fixing or proving something and getting patches into an upstream kernel so we use their downstream fork for Pi devices. Allwinner and Rockchip SoC's maintain their own patches for DRM things (mostly codec or core IP support) but most of the V4L2 items are common and upstream.

    NB: Be aware that Pi support for RPi 0/1/2/3/4 is stateful (so nothing to do with v4l2_request) for H264 and stateless (using v4l2_request) for HEVC on RPi 4/5 hardware. Stateful things in the upstream kernel are not as mature/robust as stateless.

    I'd suggest you reach out to JC and let him know that you're packaging for Gentoo. Although his primary focus is the Raspberry Pi OS, the secondary mission is ensuring Pi hardware works great under any distro, so it's good for him to know how and where his patchsets are being used.