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