Posts by chewitt

frakkin64 interesting. I've submitted this series https://patchwork.kernel.org/project/linux-…/?series=605072 and in patch 3 one of the maintainers has reminded me that this change deliberately dropped SDIO speed to 50MHz:

[4/6] arm64: dts: meson: fix mmc v2 chips max frequencies - Patchwork

After that change (some time after) these changes were upstreamed by Khadas:

[1/2] arm64: dts: meson: improve gxl-s905x-khadas-vim wifi - Patchwork

[2/2] arm64: dts: meson: improve gxm-khadas-vim2 wifi - Patchwork

And I also note that all the p212 and p231 dts files in the 4.9 vendor kernels set 100MHz (3.14 sets 200MHz) so I reckon the GXL/GXM datasheets could be wrong (have checked and it does state 50MHz).

Can I ask you to run some proper before/after iperf tests with the 50MHz > 100MHz change (only), then a test with any other changes (and share the dts diff) and then start a new thread with the results in a post that I can link to. I'll run some smoke tests here too, and if all good I will include a bump to 100MHz (at least) and refer to the post when I resend the current p212 cleanup series.

frakkin64 Amlogic's codebase of forward-ported stuff started to mingle with the upstream codebase in their latest BSP release based on Linux 5.4, but for now they only adopted some things like crypto acceleration drivers which are quite simple. Otherwise it's simple, their kernel defconfg compiles their drivers, not the upstream ones, and everything remains separate. Over time I'd expect to see them align on core board support (which their developers are upstreaming) but they will keep all the media bits separate.

The clm blobs allow a board manufactuer to tune the wireless card for their specific implementation so they are board (not card) specific and thus not appropriate to use generically in "distro supports many boards" scenarios. It's a little different with e.g. RPi4 where we pull the firmware blobs from a repo dedicated to RPi firmware and we know they are only used with the correct board hardware. Lack of clm blobs is not the issue and the 'error' is harmless.

See https://github.com/torvalds/linux…a3c0cb287f6e223 for some history on the alignment message. I think it needs to be solved in brcmfmac? - I'll ask maintainers again. The p231 dts inherits 50MHz from https://github.com/torvalds/linux…-q20x.dtsi#L262 as most of the reference boards have slow speeds set. The solution for that might be to create an upstream board dts for Vero4+ that sets higher SDIO clock. Can you share "dmesg | paste" please.

MPEG2 should be supported (the codec is upstream) but no idea what state it's in - I'll have to go create media to test it.

tomaszc Collabora work on open-source Mali GPU support and also media codecs in Rockchip hardware which are derived from the same Hantro G1/G2 IP blocks that are also used in Allwinner SoC devices (so the upstream code overlaps and supports both vendors). They are not working on anything for Amlogic that I'm aware of, but we collaborate with them on other hardware.

LE uses ConnMan to manage wireless connections. ConnMan uses wpa_supplicant as a library (for now, until we switch to iwd) but you cannot configure connections that way. ConnMan supports connection to EAP networks, but our GUI is aimed firmly at dommestic users and does not implement support for configuration. However you can still create an appropriate *.config file under /storage/.cache/connman with required details and it will work (over the years there are a small number of reports of people doing it).

See https://manpages.debian.org/testing/connma…onfig.5.en.html for the large array of possible options and some examples.

That's something different .. /etc/resolv.conf is not the same as "update-resolv-conf" which looks to be a script used when connections are brough up/down. You can install the script somewhere on /storage and change the openvpn config to call the scrtip from that location instead of /etc/openvpn which is not writeable.

Quote from mirbg

Pi 4 2GB @ 2.35Ghz CPU and 900Mhz GPU:

Meh, only 2.35GHz .. see https://www.pcgamer.com/raspberry-pi-overclock-3ghz/ !!

This was shared in post #42 above: https://www.horus.com/~hias/tmp/libr…917-70986b0.tar

Play a video, bring up properties, change the orientation, then "set as default for all videos" and it should be persistent? (from memory, so might not be exact wording of what you see on-screen).

busfahrer303 there are no formal nightlies, but this image was shared by HiassofT in another thread https://www.horus.com/~hias/tmp/libr…917-70986b0.tar

Any chance you can run some tests anyway? .. I made a device-tree file for it, so it would be good to know if it works or not.

I'm not sure anyone has tested with an S905W2 chip so you'll have to go first and let us know. I would start with "meson-sm1-a95xf3-air.dtb" in uEnv.ini as that's quite simple hardware and probably a close match. I've no idea what WiFi module is in the box so it will be Ethernet only until someone shares some close-up photo's of the board inside. The Android boot log would also be useful.

Quote from frakkin64

Is Amlogic actually upstreaming any of their newer devices? Or are they going the Realtek route?

Amlogic recently started upstreaming support for S805X2 which is one of their latest budget chips, but it's a cut-down version of S905X4 so in theory that should be useful - they are still making the decision about whether to upstream S905X4 too, but the differences shouldn't be too significant so I hope they do. Regarless, it will be a slow process as their downstream code style is often old/outdated and overal quality is low so it takes many iterations of patches to raise standards to the point where the kernel maintainers will accept things. I'm also expecting them to focus on support for the core board systems only and make no attempt to upstream the media parts. That's a good/bad thing; it's it's the thing we need most, but their downstream drivers are extremely complicated with lots of features and the lack of anything upstream creates the opportunity to apply the "less is more" principle and implement only the capbilities we actually need. Anyway, it's early days and I don't expect to boot LE images on latest generation hardware anytime soon.

Quote from tomaszc

Some time ago, there was a post on LibreElec and Collabora Twitter about work on a driver for Mali T760 and newer. If the driver is created and working, will it be possible to hardware decode without HEVC, just using this driver ( something like hwdec=auto in mpv) and solve the video rewind issues? - I don't quite understand how currently HEVC uses GPU hardware decoding if we don't have drivers.

No. In the x86 world the "Graphics Card" sort of combines everything into one device. In the ARM world GPU and VDEC are totally separate things. In an Amlogic box the Mali GPU (Panfrost or Lima drivers which are upstream and work great) accelerates rendering of the Kodi GUI via OpenGLES (squares and triangles are being drawn on the screen via maths) and an IP block on the core SoC (S905 etc.) decodes video frames for rasterising to a DRM (digital rendering manager) device like an HDMI tranceiver.

Fixing HEVC is going to be a lot of work as the older and newer hardware generations are quite different. I'm not going to go into too many details just yet, but there is a plan of sorts forming on how to get some of the outstandinig issues resolved (and who will do the work). It's unlikely to be quick though, so we have to be a little patient.

The specs I found online suggest it has the SSV6051P WiFi chip. If true it is not supported and won't ever be - we have sources for the driver but they are ugly code (easily the worst legacy driver code we've seen) and will not compile on any kernel newer than Linux 4.11 without a major rewrite that nobody sane is going to volunteer for. Plan B is to use a USB WiFi stick (avoid Realtek ones). Plan C is a WiFi bridge that presents Ethernet to the box via a short cable. I use an old Apple Aïrport express like this during board/box testing as (even with boxes that have supported WiFi chips) it eliminates the need to configure WiFi to get online.

I've no idea where the reset button is, but the normal locations we see with cheap TV boxes are either between the air-holes/grille on the underside of the box, or down the bottom of the 3.5mm AV jack.

One of the USB ports is probably an OTG port that can be connected to a PC to flash the eMMC with an Android image via Amlogic burning tool .. but I have no advice on what image to use.

The message that appears on-screen is indeeed harmless and can be ignored. No harm in adding nomodeset to the boot config .. but we don't use grub unless it's a 32-bit BIOS (as indicated by the SYSLINUX header in the pic). Similar place to modify, but not actually grub.

It's a rainy Sunday here (doesn't happen often) so there is now a "meson-gxl-s905w-mecool-m8s-pro-w.dtb" device-tree and an untested IR keymap in the "box" image. See how it goes and report back.

"Allow hardware acceleration" does not mean "only allow" .. it means we will use it when it's technically possible. As GDPR-7 said, not all hardware will support all media/codec types for hardware decode, and when something is not possible we fall back to software (CPU) decode which will generate heat .. and that's when people regret choosing boxes with cooling fans instead of a large passive heatsink

Google restricts the number of Google API searches that can be made per-day with applications. Developers of registered Google API using apps can purchase access to higher numbers of searches, or they can request a free bump to higher tiers and then it's up to Google to grant the request. The net result is .. both the YouTube and Tubed add-ons are wildly more popular than the current tier of requests allowed, and when the free quota is used you see the warning. Neither add-on is going to pay for searches, so the workaround is for you to register with Google for a personal developer account, and then you can have your own API keys with their own quota. You will find instructions for this online. Once you get YouTube add-on working Tubed can/will use the same API key files. It sucks, but unless Google decides to grant Tubed a larger quota, there is nothing the developers (or LE, or Kodi) can do.

You can create a new SD card from https://chewitt.libreelec.tv/testing/LibreE…85.0-box.img.gz and as a starting point, set the dtb name to "meson-gxl-s905w-p281.dtb" in uEnv.ini. You may need to force recovery boot again for the SD card to be read. The SSV6051 WiFi chip is not supported in the upstream codebase that LE uses (and no hope of that changing) but Ethernet should work. The IR remote will need a keymap creating, but once you get the box booting the LE image it's not hard to capture the IR codes and then I can add that. If you do not have a USB keyboard to complete the first-run wizard with you, can always force SSH on by adding "ssh" to boot params in uEnv.ini.

NB: This is an LE11/Nexus (pre-Alpha) image. There are no LE10/Matrix images .. and this is LE not CE. The upstream codebase is still a little experimental, but works quite well on older GXL hardware.