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

    Also, did some quick unscientific power usage checks on Beelink GS1, tested consumption at 230V wall socket using Voltcraft Energy Logger 4000.

    1) ~0.0W in shutdown state (with Crust running on co-processor).

    2) ~0.0W in suspended state (with Crust running, yey).

    3) 2.4W running, idle on Kodi homescreen. Kodi IS wasting too much CPU in idle mode though, shouldn't be more than a single digit percent of a low frequency state CPU core, not ~35-40% like at the moment.

    4) 2.7W playing 1080p60 H264 video from the SD card.

    5) 5.3W playing video + 100% load on all quad cores using 'openssl speed'

    I'd say, as soon as GPU driver and suspend/resume process is stable enough for a particular Alwinner board, default remote power button could be remapped from poweroff to suspend. That would result so much smoother and pleasant user experience, since suspend/resume is almost instant and power usage is insignificant as well.

    Quote from jernej

    Please test this patch: http://ix.io/2UF5 (just put it in projects/Allwinner/patches/linux/). CEC still works for me after switching input sources.

    I didn't see effect. Any easy way to tell the patch was applied on the image I tested? (I used latest master, btw)

    [edit] I checked the relevant file, and indeed it was patched. so yeah, there wasn't any effect on behavior, unfortunately.

    Edited once, last by nema32 (April 1, 2021 at 4:26 AM).

    Quote from jernej

    BTW, Crust/Linux fixes were just merged for GS1.

    Superb, thanks!

    Another issue I see is that GS1 doesn't seem to be running GPU at full speed.
    I've enabled debug OSD in Kodi, held remote right button to keep Kodi scrolling/redrawing, and tested in both stock Android (latest Kodi 19 APK) and Libreelec.

    Android animations are fluid, easily capping at screens 60FPS rate. Libreelec animations are rather jerky, FPS counter only goes to ~20FPS.

    Kernel log says GPU is running at 432Mhz, if I'm intepreting things right. Google sources say Mali T720 in H6 can be run at 600.. 650 up until 700 Mhz.
    There doesn't seem to be any way to control GPU frequency/voltage dynamicaly, devfreq API is missing.

    Code
    [    0.281057] vdd-gpu: supplied by vcc-5v
[    7.221561] panfrost 1800000.gpu: clock rate = 432000000
[    7.221586] panfrost 1800000.gpu: bus_clock rate = 200000000
[    7.314868] panfrost 1800000.gpu: mali-t720 id 0x720 major 0x1 minor 0x1 status 0x0
[    7.314880] panfrost 1800000.gpu: features: 00000000,10309e40, issues: 00000000,21054400
[    7.314885] panfrost 1800000.gpu: Features: L2:0x07110206 Shader:0x00000000 Tiler:0x00000809 Mem:0x1 MMU:0x00002821 AS:0xf JS:0x7
[    7.314889] panfrost 1800000.gpu: shader_present=0x3 l2_present=0x1
[    7.425222] [drm] Initialized panfrost 1.1.0 20180908 for 1800000.gpu on minor 1
    • Official Post
    Quote from offbeat

    Another issue I see is that GS1 doesn't seem to be running GPU at full speed.

    Yes, devfreq for GPU is missing because all attempts to make it work failed. GPU always locks up after some time due to unknown reason. 432 MHz is default frequency in HW and it's good compromise between speed and consumption/heat. Note that Android uses different GPU driver (closed source from ARM), which is probably better optimized than mesa.

    • Official Post

    I'm not 100% sure, but if I recall correctly, testing there was done systematically with some script where it seemed to work, but after additional testing with Kodi, problems were observed. Note that these problems are not necessary obvious immediately. This was tested and discussed internally in LE team chat...

    Quote from nema32

    This issue appears to be the same as the one I mentioned. I built 9.2.0, and 9.8 (38764c8) and can verify that 9.2.0 doesn't work, and that 38764c8 does work after the TV gets turned on. It doesn't work after changing input source to something else then back to the TV though.

    I intend to do a bisect to find the patch which caused this difference, hopefully I'll have something before the weekend. And perhaps it will also lead towards refreshing after changing input source too (though I admit to not fooling with Input/HDMI-CEC options to investigate).

    BTW, nice build system. worked fine with Devuan 3.0.

    I have very similare issue with my pineA64 plus.

    CEC does not work on new 10. Builds not even official beta. As jernej said these are now using hw cec method.

    So i have built a linux pc to build old images.

    What i have found is:

    An old image from 2020 aug 19. Has almost perfect working CEC. Even tv restart is fine.

    The cec lib version is 4.0.5

    One image from 2020 November CEC works until tv is restarted then the mentioned issue.

    That image has CEC 4.0.7.

    I have no idea how or is possible to build new image with that 4.0.5 CEC lib.

    Or might be not that easy?

    Edited 2 times, last by norberto_ (April 6, 2021 at 8:07 PM).

    image for pinea64 (librelec10) is totally unstable; would boot, hang during setup screen, would start again, after some 10-20 seconds screen would start to shift from left to right and hang.

    are there any repositories left with the older images? thanks.

    • Official Post
    Quote from kapqa

    image for pinea64 (librelec10) is totally unstable; would boot, hang during setup screen, would start again, after some 10-20 seconds screen

    Something like that was fixed about a week ago. Which image did you try? Try latest nightly image.

    Quote from kapqa

    are there any repositories left with the older images? thanks.

    Only latest nightly and beta1 images are available, but beta1 won't work for you.

    A few more things about GS1 suspend.

    Now that RTC is working, suspend/resume tests can be scripted using "rtcwake"... which isn't included in Libreelec, so had to to edit util-linux config, build and copy in binary.

    Code
    for i in $(seq 100); do
echo "Suspend #$i"
./rtcwake -m mem -u -s 3
sleep 10
done

    100 iterations of rtcwake worked just fine, panfrost refused to suspend every now and then, but system stayed alive.
    Which got me thinking, why the hell suspending from Kodi is getting box to unwakeable state on panfrost failure?

    It turns out, systemd suspend is trying to enter deep sleep first (echo mem > /sys/power/state), and if it fails, enters lighter software-only sleep mode (echo freeze > /sys/power/state). Can't really wake up from "freeze" on GS1: no physical button, no wake-on-lan, control isn't transferred to Crust. Not sure if kernel is still processing IR in "freeze" mode, in case it does, some key remap may help.

    Anyway, for now solution is to force systemd to suspend using "mem" method only. OS won't go to unwakeable state then, even if GPU fails to suspend.

    Code
    /storage/.config/sleep.conf.d/sleep.conf
[Sleep]
SuspendState=mem

    jernej , perhaps it can be added to global /etc/systemd/sleep.conf for Crust supported boards?

    Quote from jernej

    Something like that was fixed about a week ago. Which image did you try? Try latest nightly image.

    Only latest nightly and beta1 images are available, but beta1 won't work for you.

    thanks, i have 2 images here, one is nightly-20210407 i am testing now;

    the original libreelec for pine a64 had separate images for 512 and 1gb/2gb a64 versions?

    ok, sadly i have not saved probably enough of those earlier images, that could now come in handy.

    the nightly would function, however it would not connect to any repositories "could not connect to repository" > maybe there is an issue with the ethernet?