Posts by chewitt

Couple of things to do:

a) Please run "modetest | paste" on the 9400GT box (either image is fine, the output will be the same) and share the URL so we can see what DRM properties are advertised.

b) Save the current Legacy image file(s) in a folder called "depth-size-patch" so we know they contain that change. Now update to the latest Legacy image in my test share (which does not contain the patch). If the image works fine, the patch is irrelevant. If the image does not work, we know it's important. Let me know which is true?

There are probably Xorg properties that can be configured to reduce CPU load. This is all code archaeology for me though, and I'll need to do some reading. The goal is still to have the GBM image work though.

Quote from _emanuel_

the Dreambox's conventional boot loader can no longer handle such a kernel and the box simply freezes

The root cause is probably missing memory-region mappings in the device-tree file, combined with changes in kernel memory use which now allow or result in an in-use region being overwritten. If older Linux kernels <6 worked and newer ones >=6 don't, the trigger is probably a change in kernel memory features and usage, i.e. changes to defaults in kernel defconfig.

I forget who, but someone told me that Dreambox One/Two used signed boot firmware. That's the normal Amlogic approach for protecting boot (along with ARM OP-TEE for apps and firmware) and is widely used by e.g. Amazon, Freebox, and similar streaming services. It's not impossible, but it would be the first time I heard of a TPM chip used with Amlogic hardware. TPM chips add to the manufacturing cost (an expense the normal Amlogic signing approach avoids) and will be a physical/visible chip on the board. The net result is the same though; the Amlogic BL1 bootrom (in silicon) will only boot vendor signed (in software) code.

N150 hardware probably requires a newer kernel, so best to use LE13 nightlies for now. There's no firm ETA on LE13 release but I expect Kodi to ship Piers before DevCon in early April, so within in the next couple of months.

linux/arch/arm64/boot/dts/amlogic/meson-g12b-w400.dtsi at master · torvalds/linux

Linux kernel source tree. Contribute to torvalds/linux development by creating an account on GitHub.

github.com

The device-tree file used with Dreambox devices currently sets max speed for the SD card interface to 100MHz, so you're not going to observe anything near the marketing numbers on the cards. No need to over-spend. There are no known limits on SD card size, but I've never personally tested Amlogic hardware with anything larger than 32GB (as I only buy cheap cards for testing).

RPi boards have no external antenna connector so the sole option is disabling the onboard and using external USB WiFi. And while your phone works great, the RPi board doesn't, so the "but my other device is okay" argument is invalid. Reinstalling won't achieve anything with an OS like LE which uses embedded packaging to ensure the OS content on each device is identical. You can remake the connection, but that's not the problem.

Quote from sideffect

The last post from chewitt says it as never worked.

3D was implemented for the Videocore 3 GPU used on RPi0/1/2/3 (BCM2837) boards. RPi4 (BCM2711) has Videocore 4 and RPi5 (BCM2712) has Videocore 7 which are different GPU's and 3D has never been implemented for them. End of debate.

Matrix (LE10) uses python2, while Nexus (LE11), Omega (LE12), and Piers (LE13) use python3. Our distro packaging ensures the OS update is trivial, but the python change typically causes add-on crashes, so our official advice is to not do any kind of in-situ upgrade from a python2 version to python3 version.

In practice, and if you know your way around the LE and Kodi filesystem, you can drop an LE12 update file in /storage/.update, then stop Kodi, rename /storage/.kodi to /storage/.kodi-old, and reboot to update. This results in a clean LE12 environment, and it's then simple to stop Kodi, copy back essential bits from /storage/.kodi-old/userdata to /storage/.kodi/userdata, and restart Kodi. You can copy addon settings from the previous install, but you need to reinstall all add-ons from repos to get python3 compatible versions.

I've no idea what patches and changes _emanuel_ adds to his images (he is not pushlishing the sources to his GitHub account) but I doubt he deviates far from AMGLX.

It sounds like it falls back to the 5.1 'core' audio. Have you checked cables? - it requires high bandwidth and if the HDMI connection can't handle that it will cause fallback. Please also enable debug logging in Kodi, demonstrate the issue by playing something, and then run "pastekodi" over SSH and share the URL generated.

Some comments:

• Can't explain 10.0.0.0 without knowledge of the correct DHCP scope, or there's a rogue DHCP server in the network
• RPi WiFi is never brilliant so you probably need to move the device closer to the router
• The invalid-key error is a known but unresolved connection issue - signal strength is a factor (as above)
• The usual reason SSH password login fails is people enabling the disable password feature?
• Once you get in, there is intentionally no sudo or apt package manager (we are not Debian based)

In general WiFi on RPi boards is a bit rubbish, and while "invalid-key" is a genuine bug that needs to be resolved, it's influenced by signal strength. If running an Ethernet cable is truly impossible you may need to use an external USB WiFi dongle with a proper antenna that provides better range than the onboard card.

Quote from elmangomez

Is there an LE Matrix version that has a supporting kernel? Anything I can do to make it work on Matrix?

No, but you can self-build an image with a newer kernel and related kernel and intel firmware packages. There are instructions for self-building in the wiki, although it won't give you explicit directions on how to go around bumping packages. There's lots of prior art for that in the buildysystem though, so a little initiative and curiosity should get you over the line.

Plan B .. time to fathom the overly modified skin.

Use the first command and the change will be applied on each boot. No idea what the difference is, there's not much that changed in the release aside from Kodi and kernel bumps. I'm also using an RPi5 and haven't noticed anything.

No problems, the RAM size is irrelevant to Kodi.

echo 'modetest -M vc4 -w "32:Broadcast RGB:1"' > /storage/.config/autostart.sh

I've not commented my crib notes, but I think that's the command. If you want to test ad-hoc:

systemctl stop kodi
modetest -M vc4 -w 32:"Broadcast RGB":1
systemctl start kodi

Files are in /storage/.kodi/userdata .. If you are simply moving to a new SD card on the same hardware, take a backup in the LE settings add-on, clean install, then restore the backup.

If you want a dedicated vendor kernel image with all features working .. LE 9.0.2

If you want to experiment with upstream kernels which are less featured but generally usable as long as your media needs and expectations are not exotic, use the AMLGX image. You can manually migrate data like Kodi DB files between installs, but you cannot update in-place between LE 9.0.2 and LE 12 (or LE13 nightlies) as the boot files, kernel, kodi (everything basically) are different.

Read https://wiki.libreelec.tv/hardware/amlogic for more info and instructions.

EDIT: Current images in my test share have the previous patch reverted and something added that forces EGL_DEPTH_SIZE to zero (EGL_STENCIL_SIZE is already zero). As always, no guarantees my guesswork is correct. Please run tests again.

Just swap the SD card and you boot a whole new OS (with retroarch). Cores are emulators; there are lots of them so you only need to download and install the ones you need and/or are appropriate for your hardware.

Quote from 4k3or3et

When i set 23.98 on my Windows PC it show 23Hz

The firmware in the projector has some rounding logic for display then, and when Kodi sends 23.976 it's showing you 24Hz. The Windows PC may not be using 100% the same modeline as Linux (different code, different calculations) and this could explain why one OS results in the firmware rounding down to 23 and the other results in rounding up to 24. I was going to make a comment on this being possible in the previous post, but chose to wait and let you explain first.

The real-world test is: do you see periodic sync glitches during playback, or is playback smooth?. If you don't (and I suspect you don't with well prepared media) there's no issue.