Posts by chewitt

WP2 will boot from Android/WeOS using the "box" image or if you overwrite WeOS, using the WP2 board image. All has been written in the wiki docs. Kodi will output the GUI at 1080p max (hard silicon limit) but video can be ouput at 4K with caveats: upstream code for S905 only supports 4K with 8-bit HEVC; because S905 doesn't support 10-bit, 4K H264 was never implemented in upstream drivers, and there is currently no HDR>SDR conversion. I would position any S905 device as 1080p max; you might find some content works at 4K, but most 4K media these days is HEVC/10-bit/HDR so it won't output or look right.

You'll probably need to make a custom LE "board" image that uses https://github.com/LibreELEC/amlo…ter/beelink-gt1 so the board is using the correct FIP sources for upstream u-boot support. Those are extracted (by me) from the original Beelink u-boot sources. This will also allow you to boot u-boot with the correct board dts. Use the GT1 (non-ultimate) dts in extlinux.conf as this supports the QCA9337 wifi chip; the ultimate dts expects a Broadcom device.

Kodi feature requests should be made through the Kodi forums; there is a dedicated section for them.

Create a backup of the old system. Make a new clean install and then restore the backup or simply mount the old drive and copy/sync the data over as needed. It's usually a faster and more reliable approach since by-design you start out with a working new install.

The 1GB size of the card is not important. What does matter is that it's an older and slower card. Modern high speed cards use different voltages and if that part of setup isn't handled correctly within u-boot the SD card won't be detected when the kernel loads. The older card does not support the higher-speed modes and thus sidesteps the issue. Depending on your perspective this is either vendor u-boot failing to setup the card correctly, or the kernel mmc drivers failing to handle the state u-boot put the card in. I'm in the blame u-boot camp since the Amlogic code quality isn't brilliant. It's all been hacked to work togther.. and we're not using one half of the hackfest.

I have zero interest in trying to investigate or improve compat with some random Android ROM that people have loaded. Reverting back to the factory image seems to be the pre-requisite.

Owner and permissions are never an issue as 'the' user in the OS is root and we deliberately execute bash and call the script to avoid the need for users include a shebang or make the script executable. And.. the problem was already resolved.

Install the "Turn Off" screensaver from the Kodi repo. It turns the screen off instead of just showing a full-screen black image.

------------ /sys/devices/virtual/amhdmitx/amhdmitx0/rawedid ------------
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

^ That from the CE dump confirms that there is bad (zero) EDID data on the HDMI connection. The difference between the vendor kernel and mainline is that the vendor kernel includes a bunch of forced defaults which allow things to work. The upstream kernel doesn't, so there is no active video or audio connection. If you've tried other cables and TVs then I'd guess something got damaged in the HDMI socket.

The one thing you can try is configuring the box to use an edid.bin file, and substitute the edid.bin captured from another device.

edid-decode /sys/devices/platform/soc/d0100000.vpu/drm/card0/card0-HDMI-A-1/edid | paste

Remove the override from uEnv.ini and reboot, then run ^ that and share the URL please. If the output from the main command is null, you need to check the HDMI cables and connection (unplug and change cable, use a different port on the TV etc.) .. as that's the single most likely cause of not seeing EDID data.

#!/bin/bash
(
sleep 10
echo "17" > /sys/class/gpio/export
echo "out" > /sys/class/gpio/gpio17/direction
echo "1" > /sys/class/gpio/gpio17/value
)&

^ see if that works then? .. if it does there's a timing issue and you should switch to a system.d service and schedule the events properly in the userspace boot sequence (autostart.sh is a rather blunt tool).

SSD drives fail differently to mechanical HDD drives. The management firmware can persistently mark memory areas; so in the current boot cells can go bad causing a cascade of problems, but on reboot those gone-bad areas are marked bad so capacity reduced but problems are avoided .. until more cells go bad. In my experience once cells start failing reliability only heads in a downwards direction.

LE automatically fsck's any filesystems marked dirty on boot, so if a drive (and thus partitions and filesystems had issues) we attempt cleanup and this might keep things working. In this respect our distro packaging into two files (KERNEL and SYSTEM) means as long as those files are intact a reboot often does a "clean" start; but equally if those files are damaged you have a total boot failure.

Kingspec are a budget SSD manufacturer so I would have lower expectations on drive lifespan compared to e.g. Samsung EVO 'pro' drives, and I would expect less-developed firmware which increases the probability of low-level issues where the entire drive behaves bad or has problem interactions with BIOS etc.

To me, the log looks like a dying drive. Make sure you have a backup of any important config.

If you want to share logs use the built-in "paste" function AND share a complete debug log not just the snippet of non-debug log that you think is important.

Status Update: Drinking morning coffee and trying to work up some enthusiasm for Intel CPU hardware. I'm struggling..

I'd start with repeating the setup on a clean SD card and the current LE12 nightly .. it will have updated kernel + ffmpeg + kodi and is what devs are working on (LE11 is not under active development now). Also, when you say "crashes out" does HTPC lock up (hard crash) or simply video stops and it drops back to the home screen (soft crash)?

Make sure the Wireless Regulatory Domain matches your country (or what the router is configured as). No idea why BT is not probing... but then I have low/no real knowledge of Allwinner hardware.

Perhaps background the content in the script and insert a sleep period to see if it's timing related and a delay will fix?

Quote from sedlin

Still there is another issue - no audio at all. Is there similar kernel boot parameter for audio?

Nope. Audio depends on the EDID data from the HDMI connection which is clearly missing. Please run "pastekodi" over SSH and share the URL so we can see if there are errors in the boot log.

video=HDMI-A-1:1920x1080M@60

You can try adding that ^ to kernel boot params in uEnv.ini to force output to 1080@60 .. but if the resolution is not auto-detected the normal reason is bad/broken EDID data from the TV/Monitor on the HDMI connection or a bad HDMI cable, or (rarely, but possible) broken pins in the HDMI connector.