Posts by frakkin64

  • Vero 4K+ board bring-up and testing

    Quote from chewitt

    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.

    I probably phrased it poorly, it was broken in 5.10 and that's as far as I went back. I know it was introduced in 5.6, so I can give that a shot and see, but I think there were some changes with the DT bindings related to sound that I didn't have time to figure out. I was going to look when the DT binding change was introduced and build that version.

    The general idea was to bisect and see if I could find it. Best I can tell is they set up a few registers with the codec chip (similar to 4.9) and then start pushing buffers and the interrupt just never fires, which suggests the hardware is probably not setup properly -- because I am assuming the interrupt fires when the buffers are processed by the codec chip. I didn't look too closely at how the buffers are transferred, assuming it is DMA, with 2 ring buffers. I guess it is possible that it's DT related, so maybe I should just test with the p230 DTS and see (I was backporting the DT changes made for my device).

  • Vero 4K+ board bring-up and testing

    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. :)

  • Vero 4K+ board bring-up and testing

    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.

  • Vero 4K+ board bring-up and 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

  • Vero 4K+ board bring-up and testing

    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.

  • power button with led for rpi3

    Quote from pooh22

    There seems to be some confusion about the term "firmware", I thought it was the stuff that stays on the pi, rather than the sd-card, but it looks like it may be just "drivers" for the kernel in raspian. Or perhaps rpi-update calls the eeprom update as well?

    rpi-update definitely doesn't update the eeprom. It does deliver "firmware" files, I just don't think they are persisted to chip based on what I have seen. I would expect the eeprom has a stage 1 bootloader, then there is a stage 2 bootloader on the FAT partition (which is updated by rpi-update), and stage 2 should load the kernel image. I believe the other bits like "start.elf" may be for the GPU, so those might be firmware files loaded in stage 1 or 2 bootloaders -- but I would maybe consider that a soft-firmware like your Broadcom drivers.

    LE is using the same bootloaders, firmware files, etc that Raspberry Pi OS uses -- but the update method & timeline may be different than Raspberry Pi OS, so they could be different versions. And I think the biggest difference is as I mentioned earlier, LE doesn't automatically update the eeprom but Raspberry Pi OS does at boot up. See below for output of one of the systemd services running there, it's dependent on new eeprom files delivered via the "rpi-eeprom" package (once you run apt-get upgrade or via the GUI, install new packages, and reboot it will stage the eeprom for loading, might require 2 reboots, never really looked closely).

    In any case, just wanted to mention that it was perhaps the eeprom that need to be updated, in case some one else wanted to use your solution. Good to hear that your solution works on the RPi4.

  • Official LE11 Test Images for Amlogic (Kodi-20)

    Quote from tomaszc

    Do these types of bugs need to be reported somewhere or assume that the developers know about them?

    Who is developing this codec? Is this project available somewhere like github, or is it integrated with Kodi?

    Hardware decoding is handled in the kernel, so it would be a mainline kernel issue. Kodi will use hardware decoding first if it is available for the video codec, and fall back to software decoding.

    This is the site that communicates out items that are being worked on, including their WIP and TODO items:

    Kernel mainlining progress — Linux for Amlogic Meson https://gitlab.com/pages/sphinx documentation

    Everything you need to know is there on that website. You will see near the bottom:

    Quote

    Stalled WiP

    • HEVC HW Video Decoder (elyotna / narmstrong)
    • Meson GX System Suspend / Power Management (Neil Armstrong / narmstrong) (last patches)
    • convert existing devices to use the PWM LED driver to allow dimming the LEDs (Martin Blumenstingl / xdarklight) (last patches)

  • power button with led for rpi3

    Quote from pooh22

    The pi4 needs a recent firmware (the first ones produced have a firm-ware which doesn't let the power button works. If you have this problem, best use a different sd card with raspian to update the firmware with ``````rpi-update

    IIRC, rpi-update doesn't load any firmware to chip (it's just bootloader & kernel), so switching back to LE would still be running the same bootloader & kernel. Maybe you meant rpi-eeprom-update for the Pi4? Which LE10 comes with a fairly recent "firmware", but it has to be loaded to EEPROM (otherwise it is factory default). You can run rpi-eeprom-update on LE10.

    I believe Raspberry Pi OS automatically updates the EEPROM at boot, so perhaps that is what it took?

  • Vero 4K+ board bring-up and testing

    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.

  • Official LE11 Test Images for Amlogic (Kodi-20)

    Quote from hieppo

    HEVC is the future. Actually, it is whatever newer than HEVC. But currently HEVC would be best bet most are using to encode videos. It would be nice to have it working properly than say MPEG2. I guess that is my opinion anyway, I am sure there are others that need MPEG2 over the others.

    It would be nice to have every HW decoder working, but all we can do is wait and eventually it'll get there, I don't think anyone is setting their priorities other than folks that are paying, the rest is perhaps in their free time based on what they feel is a priority. I think the priority list is probably long, and now that a big chunk is usable we might see some community patches rolling in to close the gap.

    It pretty much is going to depend on people & manufacturers who want to run mainline, rather than the vendor kernel. CE was running 4.9.113 for few years, and just recent it seems like they managed to get a vendor kernel bump to 4.9.269 which is amazing get for those guys and probably closes the door on quite a few unpatched kernel security vulnerabilities.

    BTW, ATSC 2.0 still uses MPEG2 for OTA Broadcasts, probably looking at another 10 years until ATSC 3.0 rolls out and it will be obsolete by then.

  • Vero 4K+ board bring-up and testing

    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.

  • Turning off flashing led on 8812bu

    Quote from (Owl)

    These are my config options in the .conf file: "8822bu rtw_power_mgnt=0 rtw_enusbss=0 rtw_drv_log_level=0 rtw_led_enable=0" (I added the rtw_led_enable=0 myself)

    The module is typically named "88x2bu", so try replacing 8822bu with 88x2bu in the modprobe conf.

    You can confirm the module name is correct by using "lsmod" utility to see what is loaded.

  • Vero 4K+ board bring-up and testing

    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.

  • 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

  • Vero 4K+ board bring-up and testing

    Quote from chewitt

    Vero4k is indeed p212 and Vero4k+ claims to be p231 but looks like the upstream p230 and inherits most of it's content from the Vero4k/p212 tree so

    Yeah, the recovery image is Android 7.1 reporting "ro.product.name=p230", "ro.product.model=X96", "ro.product.brand=Amlogic" in the default.prop.

    Quote from chewitt

    I can't see anything unusual in the external_mdio node but then I have no clue about IRQ/interrupt stuff.. it sounds likee you know way more than me

    LOL, I know it was simpler in the 80's :) Kernel hacking is quite the daunting task, I know enough to make bad assumptions based on things I understand conceptually but it's so time consuming trying to trace through the code and understand what's going on. I am sure it is like a lot of big/complex software where you can spend an entire career working on it and still not know every subsystem, but those guys certainly have brought it a long ways since the 1.2 kernel days when I started with Linux.

    I think the IRQ splat is because there is no driver code actually registered to the IRQ, but the IRQ is registered to the kernel via the DT.

    Quote from chewitt

    I've updated the box image and tar file in my share and pushed updated patches to kernel/LE branches. Boot logs appreciated..

    http://ix.io/3MXT

    Looks good, other than the IRQ. Light does turn off at boot.

  • Vero 4K+ board bring-up and testing

    Dug a bit more into missing GPIO/IRQ for wifi, and it appears to a PM "wake up", so not too worried about that. I doubt it has anything to do with WiFi performance, it probably is the "DMA" issue.

    Wifi is working, and it is respectable and usable, the Pi 4 can't even hit those speeds since the SDIO bus gated at 50Mhz IIRC (it's caps out at ~80Mbps on Pi 4, I think it's basically 50Mhz * 4 data bits / 2 for duplex -- since it's half duplex a theoretical 100Mbps?). At 100MHz, I would expect a 200Mbps speed less maybe 20% (~160Mbps) if the overhead numbers for the Pi track over. At 125Mbps it's pretty close, and if they figure out the DMA issue eventually I'll circle back and see where it's at, it almost sounds like perhaps some devices do not send aligned/padding frames like the mmc host driver is expecting.