Vero 4K+ board bring-up and testing

    Quote from chewitt

    Does that resolve the splat?

    Still got it.

    http://ix.io/3MZJ

    But I don't think the tar was updated? Still see 29 in /proc/interrupts and I don't see those changes in the DTB. I applied that DT patch on top of your LE branch and it appears to be missing a reference to eth_phy_irq_pins:

    arch/arm64/boot/dts/amlogic/meson-gx.dtsi:590.29-602.5: ERROR (phandle_references): /soc/ethernet@c9410000: Reference to non-existent node or label "eth_phy_irq_pins"

    Quote from chewitt

    I'm also interested to know if this patch improves speed (untested): https://github.com/superna9999/li…1a72fb03b85d099

    Applied this patch, plus "amlogic,dram-access-quirk" to the sd_emmc_a node leads to:

    Code
    [   12.085355] brcmfmac: F1 signature read @0x18000000=0xff0fff
[   12.085883] brcmfmac: brcmf_chip_cores_check: CPU core not detected
[   12.085907] brcmfmac: brcmf_sdio_probe_attach: brcmf_chip_attach failed!
[   12.085920] brcmfmac: brcmf_sdio_probe: brcmf_sdio_probe_attach failed
[   12.088463] brcmfmac: brcmf_ops_sdio_probe: F2 error, probe failed -19...

    with the patch and without "amlogic,dram-access-quirk", no difference:

    http://ix.io/3N0i

    Code
    [    2.037266] dwc2 c9100000.usb: dwc2_core_reset: HANG! Soft Reset timeout GRSTCTL_CSFTRST
[    2.039904] dwc2: probe of c9100000.usb failed with error -16

    Hmm.. I will bug maintainers for ideas on the IRQ splat - I also see it on a Bananapi-M5 board. This ^ also needs looking into.

    Quote from chewitt

    Hmm.. I will bug maintainers for ideas on the IRQ splat - I also see it on a Bananapi-M5 board. This ^ also needs looking into.

    Yeah, if you find out anything new then happy to test it out. Where things are at now, at least probably for GXL devices, it is pretty good. Sure a few minor video glitches, MPEG2 is probably the only thing to be a problem for me, but the "shimmer" with overlays and artifacts at start/seek are not a big deal to me, even the Wifi isn't a big deal [100~120Mbps is totally fine with a nice buffer cache on Kodi]. YouTube was working fine, and I think I tested Netflix as well. I haven't tested 4K, because this is not connected to a 4K display, have 4K downstairs and don't really know what the fuss it about [guess my eyes are too old].

    CPU temp at idle has also dropped from 56 degrees to 51, so that's nice.

    This is great work here, and I appreciate your help and what you guys are doing here. I should have a Radxa Zero coming eventually, to play with as well.

    RE: Zero see https://github.com/radxa/kernel/p…ment-1013592761 .. although I'm not sure whether A311D (more compute, but also more power needed, more heat given off, etc.) is a good fit of the small package size. A sample is in the post so I get to have a play someone soon in theory. I do like the S905Y2 version as I can power it off the UART pins and it runs well except for the state of playback on newer devices (there are some problems). There's a plan for fixing things but we need to be patient while developers work through other items on a long board bring-up list .. and eventually they reach the subset of media topics we care about.

    4K and HDR works quite well on GXL/GXM devices although GXL internally processes at 10-bit but outputs only 8-bit (GXM can do 10-bit).

    Latest attempt at the IRQ splat with suggestions from maintainers - see if it works:

    WIP: arm64: dts: meson: add support for OSMC Vero 4K/4K+ · chewitt/linux@12d9c05
    The OSMC Vero 4K device is based on the Amlogic S905X (P212) reference design with 10/100 Ethernet. The Vero4K+ is based on the S905D (P230) reference design…
    github.com


    Code
    +&usb2_phy0 {
+       /* HDMI_5V also supplies the USB VBUS */
+       phy-supply = <&hdmi_5v>;
+};

    ^ also see if that works for the USB error?

    EDIT: I've pushed updated box/tar files with those changes.

    Quote from chewitt

    Latest attempt at the IRQ splat with suggestions from maintainers - see if it works:

    No IRQ splat, but eth0 does not get an IP address and I see no request for DHCP on the dhcp server. Ends up with a link local address.

    http://ix.io/3N7u

    Quote from chewitt

    also see if that works for the USB error?

    Yep, that seems to have solved it. The OTG port was working for a key pad device, so guessing this has something to do with the OTG device/host switching.

    chewitt

    This seems to work, picked it up from the meson-gx-libretech-pc.dtsi, which should be in two flavors s905d & s912. I see gpio interrupt 25 fire when the cable is plugged/unplugged, I guess that's what it's for? I don't know how we can verify, I looked through the original DTS and saw no mention of GPIOH_4 or GPIOZ_15.

    I don't see any mention of the GPIOs in the original dts files either, but "If it works, don't fix it" so I think we're good. Can you share a final dmesg with that applied please.

    It would also be good to validate the 4K dts as well, although ethernet on that should be trivial as all S905X use internal PHY and there's nothing to configure. I suspect only the usb fix might be needed.

    Sadly the next round of improvements will be all about media codecs, which is beyond my code-skills.

    Quote from chewitt

    I don't see any mention of the GPIOs in the original dts files either, but "If it works, don't fix it" so I think we're good. Can you share a final dmesg with that applied please.

    Yeah, it's not. I booted up OSMC and it doesn't appear to have the GPIO/interrupt registered in the kernel /proc/interrupts table. Here is the boot up from last night, just patched in the DTS:

    http://ix.io/3Nee

    I based this assumption on the libretech pc dtsi, and was looking at the schematics for VIM2 (S912/GXL) on how the lines from the Ampak/Broadcom chips are connected to the SOC.

    Quote from chewitt

    It would also be good to validate the 4K dts as well, although ethernet on that should be trivial as all S905X use internal PHY and there's nothing to configure. I suspect only the usb fix might be needed.

    Unfortunately don't have one of those, unless you think there is something I can do to help? I know the difference is pretty much Ethernet & LEDs, according to the OSMC delivered DTS files.

    Quote from chewitt

    Sadly the next round of improvements will be all about media codecs, which is beyond my code-skills.

    Yeah, me too. I am a programmer, occasionally do C programming (not regularly anymore, mostly Oracle PL/SQL & JavaScript these days).

    I think I saw it posted somewhere finding the right guy that understands hardware, kernel programming, ffmpeg is a fairly limited pool of people -- and most would like to be paid.

    I'm aware of a well known SOM board manufacturer who's nearing launch of an A311D based product, and an early customer wants upstream kernel and working video on Linux so I've been connecting their lead developer to all the right sources and bits, and he's preparing to start looking at the code although we need to be patient as there's some other tasks on the board bring-up list right now. How much overlap there is between his customer's needs and our needs remains to be seen, but I'm hopeful that we can get another lurch forwards on the newer hardware out of it. Otherwise we're at the mercy of community development. It needs one or two 'community' developers with some driver skills and time on their hands who are prepared to experiment and learn. Some of the changes needed probably aren't too big .. it just needs the will to fiddle and do trial/error testing.

    Just noticed this is back, when I built the DTB with the Ethernet IRQ changes. I guess there was more changes than what you noted above?

    Code
    [    2.040199] dwc2 c9100000.usb: dwc2_core_reset: HANG! Soft Reset timeout GRSTCTL_CSFTRST
[    2.042840] dwc2: probe of c9100000.usb failed with error -16

    Edit: OK, figured out what's going on here. So when I tested it and found it working it was because I had a device plugged into the OTG port, and I later unplugged the device and realized it was broken and reported it. So I retested, and sure enough it happens when nothing is plugged into the OTG port. So I am guessing the 2 prior messages have something to do with it?

    Code
    [    2.429230] dwc2 c9100000.usb: supply vusb_d not found, using dummy regulator
[    2.431569] dwc2 c9100000.usb: supply vusb_a not found, using dummy regulator

    Edit2: OK, I think I figured it out. Again, blindly copying from the libretech-pc dtsi / s905d dts and some reading about similar problems on ODROID. I suspect just the dr_mode is necessary on the USB controller.

    fix dwc2 soft reset timeout errors · wagnerch/linux@7600da1

    Edited 3 times, last by frakkin64 (January 24, 2022 at 1:06 AM).

    Quote from chewitt

    I pushed the revised dts to my repo. I didn't change anything else with usb, but do you have that change?

    Yeah, I posted the commit above, but here is one rebased on your tree:

    fix dwc2 soft reset timeout errors · wagnerch/linux@cf59596
    github.com

    Basically dr_mode is set to host, on the USB controller, and phy-supply is set on both phy's. That seems to squash the error, I have no idea if the port works in "device" mode, because I guess I would need some software to provide a gadget. Never really used/needed "device" ports on Linux, so kind of a novice there.

    frakkin64 out of interest, how did you disabled hw mpeg2?

    Would be interested to try this out, because then I could use a s905 as a simple tvheadend client (only mpeg2 and h264 needed). So I don't mind having softwares code

    Thx

    Quote from tavoc

    out of interest, how did you disabled hw mpeg2?


    Would be interested to try this out, because then I could use a s905 as a simple tvheadend client (only mpeg2 and h264 needed). So I don't mind having softwares code

    On the kernel side, I removed it from the vdec formats table for my GXL device. Kodi runs at ~115% (about 30% on all 4 cores) CPU, but it's not really a problem.

    This is the patch, but it requires rebuilding LibreELEC:

    HACK: remove mpeg2 support · wagnerch/linux@ed50554
    github.com

    I don't know if there is another way, but this is the dirty hack I did. I also rebuilt the kernel all the way back to 5.10 and MPEG has been broken since 5.10 (December 2020), so it may be broken at least in how Kodi uses it since it was mainlined. I can understand that, as most people are focused on HEVC/H264. So dirty hack it is, not skilled enough to figure it out. :)

    Quote from frakkin64

    I also rebuilt the kernel all the way back to 5.10 and MPEG has been broken since 5.10 (December 2020)

    Did you bisect to a breaking commit? .. just that's how far back you've looked? - MPEG2 was the first codec upstreamed (H264 and VP9 were added later) so while it's had less focus it should also work. If 'we' can find the breaking commit it would be a good lead for investigating why the codec is currently broken.

    Removing content from "vdec_platform.c" is the correct/easiest way to disable it.