Posts by chewitt

It's the first time someone shows up with an S905W2 board and it's hard cum impossible to diagnose these things without seeing the UART (serial console) output from the box. That requires a UART cable and cracking the box open to connect it, which often involves soldering pins to the board. I'm always game for that - but most users aren't?

Quote from roterdrachen

Will this device be supported by the LibreELEC team?

I'm confident it will be supported. I'm less confident on when or how quickly it might be supported. LE will not be using vendor-kernels so we are dependent on the upstream kernel state for RK3588

Quote from HomerJau

I noticed ffmpeg 5 was released a couple days back. Do you know if this adds the HDR support needed by Kodi?

I'm not aware of there being "Kodi" related changes for HDR iin FFMpeg of any version (other than perhaps software HDR > SDR conversion which probably sucks due to 4K software decodiing). HDR is more about Linux DRM properties than codecs and decoding. NB: Kodi 20 is using FFMpeg 4.4 with a move to 5.0 in the early stages of investigation; Kodi has been using some deprecated APIs in places and 5.0 removes them completely so it's not a straight bump like 4.3 > 4.4.

The image I shared had similar changes already applied .. I hadn't pushed the patches to repos. Nice to confirm that the Ethernet works with the normal conventions and has good speed (would be nice to solve the IRQ splat though).

I think I understand the LED configuration now. 4K has no LEDs when powered OFF, blue when powered ON, red when panic is flagged. 4K+ has no LEDs when powered OFF, blue remains off when powered ON, red when panic is flagged.

https://discourse.osmc.tv/t/vero-4k-fried-cpu/86267 <= I don't see two LEDs, it looks like single multi-colour one, although it looks more like an IR sensor than anything else. Is the IR sensor only via the extension cable at the back I wonder?

Can you dump the factory device-tree with dtc to pastebin or a file?

Original Vero (S905X) box FCC shows the X96 connection https://fccid.io/2AI57VERO/Exte…ographs-3243007

https://chewitt.libreelec.tv/testing/LibreE…arm-10.85.0.tar <= I set the p230 style external PHY setup for Ethernet and changed the LED config around. I'd like to see what this looks like if possible.

CONFIG_EXTCON=y

CONFIG_EXTCON_AXP288=m

From 30 seconds of "git grep" .. ^ You need a custom image with those options added to the kernel build config.

I'd be interested in what dmesg shows with an update to https://chewitt.libreelec.tv/testing/LibreE…arm-10.85.0.tar and a switch to the dts that I created "meson-gxl-s905d-vero4k-plus.dtb" .. I pushed new images to https://chewitt.libreelec.tv/testing/ - this time they have the dtb files present.

I have debug output for MPEG2 and can replicate "audio, no video" playback easily. In short .. frames go into the decoder and nothing comes out. It will need someone with way more coding knowledge than me to figure out what's up.

I spotted a comment from Sam Nazarco (owner of OSMC) in their forums talked about the 4K+ having Gbit "muxed to the internal PHY" so I'm not sure what's been done inside the box but if you're booting p231 fine that would corroborate the statement. Interesting spot on the OID but not too surprising as Amediatech is one of the main ODM box suppliers (the other large ones being SEI Robotics and Videostrong).

Latest "box" image in https://chewitt.libreelec.tv/testing/ has my attempt at 4K/4K+ device trees, see:

WIP: arm64: dts: meson: add support for OSMC Vero 4K/4K+ · chewitt/linux@8439d7e

The OSMC Vero 4K and 4K+ devices are based on the Amlogic P231 S905D reference design. The Vero 4K has 10/100 Ethernet and a prominent &quot;+&quot; power…

github.com

I've asked Sam to share the original dts files to remove guesswork. I've seen comments that suggest there's a red power LED somewhere on both boxes and the reset button is at the end of the CVBS/AV jack according to the board pics lodged with the FCC.

MPEG2 needs driver fixes. It's been flagged. It will take time.

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.