Posts by dhewg

  • Support for A10/A20

    Quote from JohnDoe_71Rus

    sad news :(

    we can bury our cb2 boards.

    No need to bury working hardware, I still have a cb2 in use!

    But not with LE (it's too weak for that anyway), but with OpenWRT. You don't have to use it for wifi/routing though, it has a huge package collection.

    So my good old cb2 is a mpd client on OpenWRT playing music. And then there's my good old beaglebone, which runs asterisk on OpenWRT handling my phone calls. Both rock stable without hiccups, doing their job and while barely using any power :)

  • Nightly images for A64, H3, H5, H6 and R40 boards

    Quote from jernej

    Nice! If you don't mind working with Linux and U-Boot upstream on that, I'll close my PR. This is much better.

    There is no wlan-mac set. Even setting ethernet addresses is platform specific. For sunxi, it is generated here: board/sunxi/board.c · master · U-Boot / U-Boot · GitLab

    So where does the wlan mac come from? I'm getting an OUI of 6C:21:A2 AmpakTec AMPAK Technology, Inc.

    As for the bdaddr, I can try to get something upstream. But there's no opi3 support in u-boot atm. Even when adding that with the dts from linux, there's no ethernet support in linux mainline. And with the current dts copied to u-boot, my patch doesn't work because there's no "ethaddr"...

    So we need at least Add ethernet support for Orange Pi 3 on mainline before upsteaming u-boot. Until then we need to carry the bdaddr patches I guess...

  • Nightly images for A64, H3, H5, H6 and R40 boards

    Quote from jernej

    From supported boards only OPi3 suffers this. But this is actually property of the used BT module if it has unique MAC address programmed in or it uses default one.

    If you can research this topic and make something that works well, I would be grateful.

    Yeah, setting it via HCI_QUIRK_USE_BDADDR_PROPERTY and uboot gets it going: 0001-btmac.patch.txt

    But that's the ethernet mac with a bit flipped, I guess we want the wlan mac. Any idea how to get that from u-boot?

  • Nightly images for A64, H3, H5, H6 and R40 boards

    Quote from jernej

    No, I made a PR for that but it has several issues (doesn't work in all cases and should be done with udev instead of services). I guess best solution would be to develop some kernel and U-Boot patches, so BT MAC gets set same way as ETH MAC.

    Found this:

    kernel/git/torvalds/linux.git - Linux kernel source tree

    There's one board in u-boot making use of "local-bd-address", maybe we can use it too? Which boards are affected? Is this just a orangepi3 issue?

  • Nightly images for A64, H3, H5, H6 and R40 boards

    Quote from jernej

    nice. Did you try SD and HD videos? slightly different shader is used for that, so it may work differently. That certainly was an issue with lima at some point.

    My video collection doesn't have too many video codec variations, but these play fine for me:

    Code
    hevc (Main 10), yuv420p10le(tv, bt2020nc/bt2020/smpte2084), 3840x2160 [SAR 1:1 DAR 16:9], 23.98 fps, 23.98 tbr, 1k tbn, 23.98 tbc (default)
h264 (High), yuv420p(tv, bt709, progressive), 1920x1040, SAR 1:1 DAR 24:13, 58.82 fps, 58.82 tbr, 1k tbn, 117.65 tbc (default)
h264 (Main), yuv420p(progressive), 1280x720, Closed Captions, SAR 1:1 DAR 16:9, 23.98 fps, 23.98 tbr, 1k tbn, 47.95 tbc (default)
h264 (Main), yuv420p(progressive), 640x480 [SAR 1:1 DAR 4:3], 29.97 fps, 29.97 tbr, 1k tbn, 59.94 tbc (default)
h264 (Constrained Baseline), yuv420p(progressive), 640x368, 29.97 fps, 29.97 tbr, 1k tbn, 58 tbc (default)
vp9 (Profile 0), yuv420p(tv), 1920x1080, SAR 1:1 DAR 16:9, 29.83 fps, 29.83 tbr, 1k tbn, 1k tbc (default)
mpeg4 (Simple Profile) (XVID / 0x44495658), yuv420p, 640x480 [SAR 1:1 DAR 4:3], 1023 kb/s, 29.97 fps, 29.97 tbr, 29.97 tbn, 29.98 tbc
mpeg4 (Simple Profile) (XVID / 0x44495658), yuv420p, 512x384 [SAR 1:1 DAR 4:3], 992 kb/s, 29.97 fps, 29.97 tbr, 29.97 tbn, 29.98 tbc

  • Nightly images for A64, H3, H5, H6 and R40 boards

    Quote from jernej

    What I'm really after is how it behaves with sw decoded content. If you have time, please disable HW decoding in settings and test SD quality and HD quality videos. Additionally, enable HW acceleration and select EGL rendering for DRMPRIME. If all these tree cases works, then I might consider switching to mesa.

    Yeah, some videos won't play with EGL. Dunno why, there's no relevant debug output it seems

    Update: fixed by the nice folks in #panfrost, everything I throw at it plays fine now. With and without hw accel on either "direct plane" or "egl"

  • Nightly images for A64, H3, H5, H6 and R40 boards

    Quote from jernej

    Several things:

    - current GPU DT patch are only quick fix for proprietary driver. However, upstream patches exist but I didn't use them in LE yet

    - T720 needs some additional panfrost kernel patches. I think they will be included in Linux 5.5

    - T720 is currently blacklisted in mesa source.

    Thanks for the pointers, I got it working now ;)

    This is running on 5.4.0-rc7: https://imgur.com/a/cx578up

    Just tested a bit, but seems to work fine so far.

    Built from this tree: Commits · dhewg/LibreELEC.tv · GitHub

    jernej

    - switching to mesa resulted in a broken kodi: "kodi.bin: undefined symbol: glGetIntegerv", a full rebuild fixed that, maybe you ran into that too?

    - the patch "media: pixfmt-compressed.rst: improve H264/HEVC/MPEG1+2/VP8+9" in "projects/Allwinner/patches/linux/0001-backport-from-5.5.patch" seems misplaced, I didn't check, but I guess it has been merged for 5.4

  • Nightly images for A64, H3, H5, H6 and R40 boards

    Quote from jernej

    I try lima now and then, but last time I tried it, Kodi didn't even start. Buffer management was broken but I'm not sure where (kernel or mesa). I'll try again when Linux 5.4 is released.

    In order to try it yourself, you have to enable lima driver in kernel, set OPENGLES driver in project config to lima and configure mesa package to use latest master.

    Two notes:

    - T720 support is very broken in panfrost, so it makes no sense to try it, but according to panfrost IRC, it should be much better in following weeks

    - GPU driver doesn't have anything to do with HW decoding. It may be for rendering video, but even that will be soon bypassed almost completely (only SW decoding currently uses GPU for rendering)

    It compiled with mesa just fine, but it didn't get very far:

    Code
    [    0.977246] panfrost 1800000.gpu: clock rate = 432000000
[    0.987396] panfrost 1800000.gpu: gpu soft reset timed out
[    0.993370] panfrost 1800000.gpu: Fatal error during GPU init
[    0.999358] panfrost: probe of 1800000.gpu failed with error -110

    Sounds like a dts issue? Do you know what's missing?

    This is tree I used: Commits · dhewg/LibreELEC.tv · GitHub

  • Nightly images for A64, H3, H5, H6 and R40 boards

    Quote from jernej

    dhewg Thanks! Nightlies are always based on recent stable kernel, currently 5.3.5. However, a lot of upstream and wip patches are included on top of that. Check projects/Allwinner/patches/linux/ and projects/Allwinner/devices/H6/patches/linux/ folders for them. Idea is to upstream those patches as much as possible. This is never ending story - as soon as you manage to upstream something, you find something else to fix/update. However, this is beneficial for us and other distributions - once patch is upstreamed, we don't need to care about that patch anymore and other distros get same improvements when they update the kernel.

    Yeah, you don't have to sell me on the topic of upsteaming, upstream support for allwinner is why I chose such an device ;)

    On that topic, what's the status of getting rid of those gl vendor bin blobs? Shouldn't mesa be good enough (tm) for kodi by now? I guess hw decoding is the reason use libmali? Is the tree ready to just flip "OPENGL" to "mesa" to try it out?