Posts by chewitt

https://github.com/xbmc/xbmc/pull/26238 might be involved. Team Kodi decided to not backport the fix to Omega because of the last-minute timing of the latest Omega release (it had already been built) and because if a little inconvenience inspires more people to workaround the issue by creating secure shares instead of insecure ones, that's a good thing.

I remembered that I have an Xstreamer Ultra2 board in my collection. It's an Atom/ION board with a GT520 (Fermi) card which is a little more recent than the 9400GT you have. It boots both images (GBM and Legacy) to the Kodi home screen without needing an xorg.conf or kodi.conf file creating. It does require some nVidia firmware blobs extracted from the vendor driver to silence a couple of system log messages and provide firmware for decoding. I created https://github.com/LibreELEC/nouveau-firmware earlier to address that, and the commits in my nouveau branch are revised to use it and remove VAAPI support.

The GBM image detects libva support and tries to use it during playback, and fails. Rebuilding without VAAPI support allows software decode playback to work. There is no VDPAU support because mesa reports ERROR: Feature gallium-vdpau cannot be enabled: VDPAU state tracker requires X11 support. during compile. I'll have a chat about VDPAU with mesa devs, but GBM without hardware decode makes no sense, so for now, further effort on GBM (Nouveau) stops.

The X11 image is also now built without VAAPI support and VDPAU is detected and attempted. All 1080p and H264 media I've tried currently fails with VDPAU::Open: requested picture dimensions (1920, 1088) exceed hardware capabilities ( 0, 0) but some 720p/SD resolution MPEG4 media is being hardware decoded properly. I'll have to query the error with Kodi folks.

LE requires two partitions to run from and /flash and /storage must be separate. As you can now drop the 'Nouveau' image that should make things easier for testing. Please remove any config that's been added to boot params or /storage or make a clean install so you are using a default image. Also focus only on the 9400GT card for now. I appreciate the old cards work on Slackware, but your Slackware install is using significantly older software versions and bisecting to find the breaking changes will be a major effort, so that's deferred to a future date.

NB: I've pushed an image that matches GitHub commits a few seconds ago. Please check all is okay with the Legacy image after the cleanup or fresh start.

LE10/11 use 'arm' userspace and LE12 uses 'aarch64' userspace. The LE11 settings add-on is not showing an update because there is no 'arm' update. This also stops users from blindly updating and experiencing crashes due to arch-incompatible binary add-ons.

To do an in-place update you will need to first uninstall all binary add-ons (keeping their config). Then manually download (wget) the LE12.0.2 .tar update file to /storage/.update and reboot to update. Once the update completes you can reinstall binary addons (to use aarch64 versions).

Install the multimedia tools add-on and user alsamixer from the SSH console to reduce output volume. Pops and Clicks are normally the result of signals being overdriven.

Hmm.. I'll see if I can update the LE12 branch with the same patches. LE13 will be along soon enough and is quite stable though.

Please use an LE13 nightly from https://test.libreelec.tv or the test image here https://chewitt.libreelec.tv/testing/

SMB services are on by default to facilitate log collection in the event the users device doesn't successfully boot to the Kodi home screen. This is considered low risk because on first boot there are no sources configured and thus no cleartext passwords being stored and exposed anywhere. After the user adds SMB/NFS sources and add-ons that store credentials (and Kodi or the add-on stores them in cleartext) the risk profile of the installation has changed.

I think the most sensible option is to make Samba shares configurable through the LE settings add-on. Samba can then be started by default and with the logfile share defined and default enabled. Then if users want to enable other pre-defined (but default disabled) share locations they need to visit Samba settings to toggle the state. This will ensure the Kodi userdata folder is not default exposed, thus mitigating the risk of exposure from plaintext stored credentials. The logic of that is a good balance between security and usability and I'll be happy to accept your changes to add that capability to the add-on.

NB: If you want to also address Kodi storing credentials in plaintext, send code changes to upstream Kodi. The solution to this needs to be simple and work for all currently supported Kodi OS platforms and other distros, not just for Linux on LE.

If you need better wireless on legacy kernels it's often better to acquire a wireless bridge device. You can get something on Amazon that powers itself from USB and presents an Ethernet interface to the box which requires no WiFi drivers, and being an external device the reception/range is typically better.

Perhaps try with --install-test-programs=true instead?

NB: It's modetest not testmode

The log doesn't show any Ethernet related errors so next step is to open up the box and take pics of the board inside so we can see what Ethernet chip is being used. It probably needs something based on Q200 (as Q201 is for 10/100 designs) but with a different Ethernet PHY chip described in device-tree.

formats: C8 RG16 XR15 AR15 XR24 AR24 XB30 AB30 XB24 AB24 XB4H AB4H

The 9400GT is advertising AR24 which the default format Kodi tries to use.

AR24:  NVIDIA_BLOCK_LINEAR_2D,HEIGHT=0,KIND=122,GEN=1,SECTOR=1,COMPRESSION=0(0x30000000057a010)

And AR24 supports NVIDIA_BLOCK_LINEAR_2D scanout.

EDIT: I'm interested to know what kernel, mesa, and X11 versions are used on the Slackware install that works with the 6100 card?

Also, if the 6100 slackware install has modetest? or drm_info -j ? .. please run it and pastebin the output.

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.