Posts by chewitt

Yup, my WP2 image: LibreELEC-AMLGX.arm-10.0.0-wetek-play2.img.gz which has the magic header in the 512th sector of the image, so if you write the image to an SD card using something like etcher it should boot (mainline u-boot) on the box.

There are two issues:

a) I'm still jetlagged and a bit distracted after vacation, which means I forgot something rather important

b) You've erased u-boot

GXL (S905X) and newer boxes look for a magic boot header in the 1st sector of emmc or 512th sector of emmc or SD or USB, but older GXBB boxes like WP2 only look for it in the 1st sector of emmc (or 512th sector of SD or USB). The problem is, the first sector is also where the MBR partitioning data lives, so you have the choice of partitions and no-boot, or boot and no-paritions. Amlogic "vendor" u-boot implements a custom offset-MBR partition scheme to workaround the design mistake (which is corrected from GXL onwards).

If you connect the UART cable (WeTek did ship them with the box) you'll see it endlessly looping with something like:

"GXBB:BL1:08dafd:0a8993;FEAT:EDFC318C;POC:3;RCY:0;EMMC:800;NAND:81;SD:0;READ:0;CHK:0;"

It's not bricked. It simply means it cannot find the magic boot header. The normal way out of this is to write the "wetek-play2" image to an SD card and leave it connected. It will then boot from SD and you can tweak things to store data on emmc if desired. In your case the SD slot will not permanently latch/retain the card, but you'll need to figure out a temporary way to hold/fix the card in for long enough to boot from SD and perform some remedial steps. I would start by zero'ing the emmc (the z option in emmctool) and then "dd" u-boot.bin.sd.bin-wetek-play2 directly to /dev/mmcblk1 (no offsets, seeks, etc.). This will put mainline u-boot and the magic boot header in the 1st sector, so the box will boot from emmc, and u-boot should find the "wetek-play2" image on a connected USB stick.

The alternative is putting the original vendor image back by writing Dropbox - backup-wp2.img.gz - Simplify your life directly to /dev/mmcblk1 and then rebooting. This is a raw backup of my box taken a couple of years ago .. but should work.

Apologies again .. I'd completely forgotten that GXBB has the extra hoop to jump through.

Please explain in technical detail how you have diagnosed the problem. I'm not disputing PMF might be involved, but we need to discern facts from enthusiastic opinions and hunches before we attempt to engage upstream Engineers.

Quote from Pindarm

Installed v. 10.0.0 on my Rpi4, but no sign of HDR playback. Did I misunderstand something? Can this version play HDR files?

HDR works fine here for 6+ months now so if you're having problems, it's a Layer-8/PEBKAC issue.

WP2:~ # modetest | grep connected
31    0    connected    composite-1        0x0        2    32
34    33    connected    HDMI-A-1           1600x900        27    33

^ from an Amlogic device .. "composite-1" is present. Allwinner also uses the kernel DRM framework so something similar should output. The Amlogic section in the wiki is not relevant (old kernels).

See if this commit works for playback ffmpeg: use JC branch (at working commit) for testing · chewitt/LibreELEC.tv@4325503 · GitHub (will need you to build your own image).

Backup only supports local storage. If you want to write to a remote share, setup a systemd kernel mount to locally mount the remote share, then write the backup to the "local" folder.

I think jernej has something in his Allwinner images for flashing things to emmc, but "emmctool" only exists in my Amlogic images; hence you cannot find it to use.

cd /storage
wget https://chewitt.libreelec.tv/testing/LibreELEC-AMLGX.arm-10.0.0-wetek-play2.img.gz
emmctool w LibreELEC-AMLGX.arm-10.0.0-wetek-play2.img.gz

^ that downloads the file, writes it to emmc, expands the storage partition, changes disk labels, then sets extlinux.conf to boot from the new disk labels (so SD boot still works).

I doubt the audience in this forum will have an opinion on Android support (not our focus). You'd be better off asking in the Radxa forum.

jock2 I'm not aware of any guides for writing wireless drivers, but I'm not sure anyone could do a worse job than the original

The internal port might be worth trying .. I always forget about it. If not, perhaps hold the card in with a woodworking clamp (not too tight) to boot and then download/overwrite the eMMC with LibreELEC-AMLGX.arm-10.0.0-wetek-play2.img.gz. Once you flash mainline u-boot you'll be able to boot/run the LE10 image from eMMC fine (seems to work okay for me) although the current state of Amlogic in LE10 is far from perfect.

I'm not sure if the WP2 checks all USB ports or just the OTG port during boot, so experiment.

I don't include or support the community scripts for instaling stuff to emmc with vendor u-boot; my knowledge of it all is poor and the scripts often cause problems. If you boot from the "box" image you can download the "wetek-play2" image and write it to emmc (replacing vendor u-boot with mainline which I understand more) using "emmctool" .. but I'd caution against doing that unless you're comfortable with how to restore it back to the original WeTek code again should you not like it. IMHO there's not a huge difference between running from a decent SD card and eMMC.

Work has started on delinterlacing. It won't be a quick feature to add, but it will come.

Write Dropbox - bootsector.img - Simplify your life to the USB drive using any image writing tool (etcher etc.) and it will erase all partitions and allow the disk to be prepared (reimaged for LE) again. To be clear, this will nuke all content on the drive.

"devel" is the image tag for an ad-hoc built image .. not a scheduled nightly

In LE the xrandr command is only present on devices running Xorg/X11 windowing (Generic x86_64 devices) but ARM SoC devices "run on the framebuffer" with no windowing system. Other distros, e.g. Armbian are desktop focussed and will use X11. The nearest equivalent is forcing kernel DRM output modes, which can be done via boot params in extlinux.conf.

I don't have experience with SCART devices, but the standard resolution I've seen with RCA outputs (single cable) in the past is 480p/i and it's cousin the Component output (three cables) is the same but can also run at 720p and 1080p/i. Current Kodi skins are designed for a minimum 720p screen resolution but most (not all, but most) will handle 480p if needed, but lower than that I'd expect to see visual problems as none of the skin designers will be testing low resolutions. Similarly.. I doubt any of our maintainers are testing RCA/Composite output so YMMV.

Right now there's really only one developer working on Rockchip (others had to step back for personal reasons) and people have lives outside of fiddling with kernel drivers and their own sense of skillsets and where focus needs to be. There's also a lot of collaboration happening on hardware video decoders (V4L2-requests needs to work on three different SoCs we support) so it makes sense to be involved and contribute there. Meanwhile PCM audio is working and good-enough until time frees up for other things.