Posts by chewitt

Forget the S805 device, it was never supported by OE/LE in the past and modern kernel support is making positive but glacial progress and is a long way from being easily usable. The S905 box might be somewhat useable; the choice is CE which should offer best support, or you accept the very "work in progress" state of modern kernel support in LE images.

NB: Users are obsessed with running from internal storage but this complicates the bejesus out of testing images which may or may not work and provides only marginal performance benefit. You'll need to restore the correct vendor u-boot to make further progress. There are a very limited number of people supporting Amlogic hardware in these forums and I have subzero interest in install2internal issues; that script is a complete waste of personal time.

To be clear, I'm not an expert low-level developer, so access to hardware might not get me a lot further than we currently are.

Amlogic hardware has an IP block called "ge2d" which handles the tonemapping separate from the vdec. It's supported in the vendor kernel, and partially supported in the mainline kernel, but not currently in a useful way.

You can cross-grade from Nightlies to my images. You cannot cross-grade from Oleg's images (balbes150) due to different boot config. I'm interested to know what resolutions and codecs are problematic. I'm not interested in TVH logs (someone else's problem).

One of their devs confirmed that Dreambox One/Two use encrypted boot, so "FIPs" are no-go and you will need to continue chainloading u-boot, or you switch to the vendor kernel and work with CE sources rather than mainline kernel and LE. I also learned some things about the M4 chip used for MCU functions. They won't share schematics for the boards, but are happy to answer Q's and might share selected pages if we ask them specific questions. I don't have the skillset to debug much more about the boot issue without access to hardware.

tavoc The images in Index of /testing/ might improve some of the switching behaviour (improve, not resolve). I'm not sure how to disable MPEG2 but I can have a poke around. Sadly the vdec isn't in brilliant shape.

I asked Q's in the freenode channel. I'll see if I get replies..

See the file list here (VIM3 is also a G12B device): amlogic-boot-fip/khadas-vim3 at master · LibreELEC/amlogic-boot-fip · GitHub .. this is what we need to build a signed mainline u-boot.

There is nothing wrong with the app, only the untrusted signature. It seems there is no alternative to paying for the Apple developer account so the image can be signed with a trusted cert.

Drives are mounted via udevil so you would need to clone the udev rule that mounts removable drives to /storage/.config/udev.rules.d and edit it to mount them somewhere else. NB: If you have two drives with the same LABEL the second one to mount will be LABEL-1 so they will not mount to the same name. You can't control probe order (which determines mount order) so it's best to ensure they have unique names.

Remove aany changes from /storage/.kodi/.smb/user.conf and /storage/.config/samba.conf .. and on the Windows box you should be able to select Avahi/Bonjour/ZeroConf network browsing to find the LE Samba share correctly. Win10 always wants to authenticate connections so you will need to enable authentication and set the user/pass details. If that doesn't work, enable SMB client debug logging in Kodi on the Windows side and share the log.

Please try Dropbox - LibreELEC.USB-SD.Creator.macOS.dmg - Simplify your life it has tweaks that I am working on for the USB/SD app to run on Catalina which has broadly the same requirements as Big Sur. The image and app are signed, but not with an Apple-trusted cert, so you will need to visit the security settings to allow that etc.

The drive should spin down into a low-power mode automatically and you can change the params of this with "hdparm" but you cannot fully turn off the drive; unless you have "smart" power sockets that can be controlled through software.

I'd also be stunned if it had 4GB RAM, as I've never seen/heard on a P281 (S905W) device with more than 1GB.

CE is probably a better option as P281 devices are usually ultra cost-engineered (worst-spec RAM, worst-spec WiFi, 10/100 Ethernet, etc.) so you will probably need the vendor kernel for driver support.

The FIPs contain RAM timing data (acs.bin) so if this is wrong the box doesn't boot, which is not impossible to recover from but needs you to short emmc pins to prevent [wrong] vendor u-boot from being found/used. If I want to experiment I will take a backup of emmc then zero emmc. The box will then boot the experimental signed u-boot from USB/SD card, and worst case if nothing works I can put vendor u-boot on an SD/USB to recover the system. If you can get u-boot sources it's simple to extract the FIPs. Alternatively, if they will not share the sources, please loop me into an email conversation with the developers and I can explain which files I want.

Do you see the same behaviour in the LE10 beta?

Please fork u-boot on GitHub and push changes. It is sometimes hard to follow your descriptions (lots of enthusiasm, but light on technical detail) so commits in a branch are always good to review