Posts by chewitt

You will probably need to force recovery boot via whatever method works on your box, e.g. holding in a reset button when power is applied to the box and releasing after a few seconds (so-called toothpick method) etc.

https://www.raspberrypi.com/software/ <= Click here. Download the imager app for your OS. Create an SD card - LibreELEC is in the list of OS that you can choose/install to the SD card.

Your box has banned add-ons intalled. You are welcome to remove them from the box - if you want further support in this forum.

Random Q .. are you sure that you have the Vero 4k plus? .. You've used the p231 dts as the base and this uses internal PHY (should be 10/100) where the plus (according to the website) has Gigabit which would be using the external PHY and p230 would be the right dts base. I think you have the 4k (non-plus) model. I'm no expert on OSMC hardware though

Thanks. Can I ask you to drop the sd-uhs* caps from the node and repeat the 'after' test. Although things are 'detected' I'm not sure it makes any difference and it's always best to submit minimal changes upstream.

dtb_name=/dtb/meson-sm1-a95xf3-air.dtb

drop the @@ from dtb_name, like ^ this, the other line is fine/unchanged.

BerryBoot has a long-running negative reputation with LE project staff because it runs it's own kernel instead of ours, which leads to weird problems. The iissues magically resolve themselves when BB is replaced with NOOBS/PINN which work fine.

Create a USB or SD card from https://chewitt.libreelec.tv/testing/LibreE…85.0-box.img.gz the same way as you made any other LE or CE image (Etcher, Win32Diskimager, the LE app, dd on Linux, etc.). Then set the correct dtb name in uEnv.ini.

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.