Nightly images for A64, H3, H5, H6 and R40 boards

I still have a Tanix TX6 clone (T95 Max), is there any way yet to get IR wake working on LE?

Just wondered on the latest status etc.

Hello,

I’ve been searching all over the web for these old images (opilite):
Latest prebuilt images [2016/10/26] / latest update [2017/2/21] - Openelec OrangePi -

jernej
Do you maybe still have a backup of them?

I’m trying to bring my old opi back to life

Quote from Eli2k

Hello,

I’ve been searching all over the web for these old images (opilite):
http://www.orangepi.org/orangepibbsen/…thread&tid=1075

jernej
Do you maybe still have a backup of them?

I’m trying to bring my old opi back to life

NVM, I was able to compile it from source and it works pretty well

I've created a repo with instructions if somebody wants to try and recreate an image

jernej I saw there were some commits in your fork branch allwinner-h616. Can you please let me know if they are working well?

Quote from jernej

I did quick check on x96-mate clone board and fixed some obvious issues. Now basic H616 support should work.

Please test:

Images: https://jernej.libreelec.tv/images/h616/

PR: https://github.com/LibreELEC/LibreELEC.tv/pull/11799

Thanks for the H616 work! I tested on an Orange Pi Zero3 (H618, 4 GiB, AXP313A). Display, HDMI audio and Panfrost work fine, but with cpufreq enabled the board is unstable:

• Your test image hangs within about a minute of boot: RCU stall with CPU3 not responding even to NMIs, i2c-0: mv64xxx: I2C bus locked (the AXP313A bus), and an Ethernet TX timeout just before.
• A local build of the PR head oopses 14 s into boot on CPU3, inside zstd decompression for squashfs, with obviously corrupted register values (e.g. lr : 0xebfa28af2645a26c), which looks like the CPU computing garbage rather than a software bug.

Booting with cpufreq.off=1 is stable, and so is pinning the CPU at its top OPP (1.416 GHz on this chip), so the problem is frequency switching rather than the OPP voltages.

The AXP313A regulator ops have no set_ramp_delay and the driver declares no ramp delay, so the regulator core assumes the new CPU voltage is reached instantly and raises the clock right away. Adding a ramp delay to the CPU rail in the Zero3 DT fixes it:

reg_dcdc2: dcdc2 {
        ...
        regulator-name = "vdd-cpu";
+       regulator-ramp-delay = <2500>;
};

With that, the same local build runs stable with the default schedutil governor: 37,664 frequency transitions without a single hang or oops. 2500 uV/us is the value the H6 boards use for their CPU rail.

I can share the patch and full UART logs if useful.

Thanks
Asai, Shigeaki

Quote from jernej

Please provide DT patch and I'll incorporate it into PR.

I also fixed deinterlacing, the only remaining issue I could find for H616. I'll push it later with your fix.

Thanks! Here is the patch. It's the same change I tested with a local build of the PR head: the unpatched build oopses or hangs within a minute, and with this patch it stays stable with schedutil (37664 frequency transitions).

jernej i tested on vontar h618 (transpeed-h618-8k-t clone) and the box also hangs after a couple of minutes of booting up.

jernej Thanks for the update! With the AXP313A ramp delay fix, my Orange Pi Zero3 runs fine with your latest image: no freezes, and H.264/H.265 videos played for 5 minutes without issues.

jernej thanks for the rapid fix. Now it seems more stable on my vontar h618 box. Been testing for about one hour and still working well. However, the analog audio got distorted and the ethernet port is not working. Hope these will be fixed soon. Once again thanks for bringing up these h618 boxes!

jernej sorry for late response

Quote

LibreELEC:~ # devmem 0x0300622C 32
0x02920504