Posts by jernej

Quote from Dr.Pablo

The libreelec works normaly until I turn-off the television. This last operation turns-off the banana-pi, but unfortunately like a cut-off of the power supply, without activating a process for power-off!

Actually I want that the banana-pi remains turned-on while turning-off the Sony-television.

Is this issue known?

Why do you think it's not properly shut down? Shutting down board when TV is powered off and vice versa is by design. If you don't want this behaviour, then either disable HDMI-CEC on your TV or change CEC settings under input settings in Kodi (currently I can't give you detailed instructions).

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.

H3 supports booting only from micro SD card or eMMC (where Android is installed). You don't need to do anything special for booting from SD card, just burn image and insert it - SD card has higher priority than eMMC.

You can try with Beelink X2 image, but no promises - I don't know if it is compatible. Only currently available images are for LibreELEC 10 which has Kodi 19 (either beta1 from download page or nightly images). There is no image with older Kodi.

Quote from offbeat

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.

You should also check CPU frequency. Governor lowers frequency during low load.

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

offbeat CEC is indeed a bit flaky at the moment. You can test above suggestion if you want. It's unlikely we'll be able to make it behave perfectly before final release. It's big PITA. Crashlogs should help.

Quote from nema32

I should be able to build/test any patches if that would help.

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.

Quote from roel

I tried a few things yesterday, installs fine, my needed add-ons work, although the streaming buffers a lot. I don't know if it's related to the Tritium H3 or the mpeg-dash stream. We always had problems with these streams, but no freezing or repeatedly buffering. When I switched back to my khadas vim1 running leia everything was OK'isch using the same add-on.

I tested streaming on H5 version and it worked fine at that time, but it used HLS protocol. It could be protocol related. Note that Tritium boards only have 100 Mbps ethernet via internal PHY - I already had compatibility issues with that.

Quote from roel

Couldn't log in with samba, but maybe i didn't try enough. Before shutting down the device I checked the LE settings and there seems to be a choice now to login with or without pasword. but I didn't try it anymore. I know it nevers gone happen but a nfs server is way more trouble free.

SMB1 is not supported anymore and afaik you must use username/password with SMB2/3. Anyway, no worries. I'm mostly interested if driver works - everything on top of that is same for all devices.

Great, I'm happy that it works for you. Fixes will be included in next beta and I'll send respective fixes to Linux and Crust.

Quote from offbeat

2) No more CEC errors in dmesg and cec-client. I will test ir further later, no access to capable TV at the moment.

Preferred way to check CEC on mainline Linux is to stop Kodi (systemctl stop kodi) and run cec-ctl --playback -S. It should print some TV properties (if it is connected).

Quote from offbeat

3) Suspend/resume and poweroff/poweron worked perfectly while connected to TV. In headless mode though suspend rarely works, mostly fails due to GPU driver error, resulting either instant wakeup, or suspend/crash/smthelse without ability to wake using remote.
Headless poweroff/poweron using remote worked 100% during my tests

Good, that's in line with other devices. I noticed that instant wakeup on few occasions too but currently I'm very happy that it works so well as it does. Poking GPU drivers is the last thing I want to do.

Quote from offbeat

Here goes, Beelink GS1 last stock Android, firmware 106N0, kernel 3.10.65

Thanks. Note that there is no need to use both methods - both should give exactly the same result, which they did. 4 means external 32k oscillator is unusable, which is what we see on mainline. IMO it's best just to disable it and use internal, less precise oscillator. Here is another test image: LibreELEC-H6.arm-10.0-devel-20210330172558-ba292b4-beelink-gs1-pm-and-int-32k-osc.img.gz (burn it, don't update). At least RTC should be quiet now and maybe CEC and suspend/resume will work too. Let me know.

offbeat Another dev tested that image, but for him it didn't work (same behaviour as yours), so unfortunately I can't do anything here. You would need to open issue in crust repo and actively cooperate with developer (solder contacts for serial console, turn on debugging options in crust, build various images and test them). LE build system is not really optimized for such steps, so this could be a bit tedious. However, if you decide to go through with it, I can help (but please open new topic for this).

Regarding RTC - it would be helpful, if you could read address 0x07000004 from Android. This is usually done from root shell using devmem or devmem2. Sometimes busybox has this applet (just run busybox and check output for it). However, sometimes Android is locked down and direct memory access is not possible. In that case, you could check if Allwinner debug interface is still in place (/sys/class/sunxi_dump). If it is, you can execute these commands as root:

echo "0x07000004,0x07000008" > /sys/class/sunxi_dump/dump
cat /sys/class/sunxi_dump/dump

Note that CEC should not depend on that oscillator (it's switched to another source in clock driver) but maybe there is some internal connection we are not aware of.

Timpanogos Slim Note that suspend/resume handler is running independently of ARM cores on his own coprocessor. It has it's own implementation of IR commands decoder, so whatever you do in Linux, it won't have any effect on suspend/resume IR remote handling. This means that currently it's not possible to change default IR wake up code.

offbeat Please test this image: LibreELEC-H6.arm-10.0-devel-20210328122614-ba292b4-beelink-gs1-pm-test.img.gz Note that you should not try to update but burn it freshly. Most types of update don't update bootloader which is responsible for loading suspend/resume firmware (this firmware is embedded in bootloader).

EDIT: One LE developer tested this and it worked for him.

Quote from offbeat

Here is a photo of my PCB, revision 2.0 Imgur: The magic of the Internet

Almost the same as the one published in Beelink GS1 - linux-sunxi.org , although some chips are diferent.

Thanks! This is same revision. eMMC is different but that is not unusual and doesn't really matter because it's autodetected. Anyway, I see 32 kHz oscillator - that long component under 24 MHz crystal. I have no clue why it doesn't work.

Quote from offbeat

Should I open bugreport there, or can I help in any other way?

You can open bug report but without directly involving in debugging process I doubt it will be solved. Crust developer also doesn't have that box. You can try to build and test this branch: Commits · jernejsk/LibreELEC.tv · GitHub

Quote from 2can

Also, is there a procedure to just upgrade LibreELEC and leave Storage partition in place?

Updating - LibreELEC.wiki

EDIT: A64 GPU fix is already merged, it will be available in next nightly images.

Quote from mike2002

With my Orange pi PC, I got an out of memory during browsing my Recently added movies : http://ix.io/2TkX

Please test tomorrow nightly image. It will have mesa 21.0.1 which fixes memory leak in lima. More info: lima: fix max sampler views (!9172) · Merge Requests · Mesa / mesa · GitLab

Quote from nema32

I should be able to build/test any patches if that would help.

I'll let you know. Currently I'm still trying to find out what to change. That part of code change considerably between 5.8 and 5.10.

Quote from nema32

Does this issue give any indication of the similar problem of it failing to reset when changing input source back to the pi? eg, quick jaunt to the tuner "Disconnecting Anynet device...", then change the input back, and it's non-functional for hdmi-CEC. I doubt the fix you're mulling will address both issues, as all the "good" results only worked when the TV came back from powered off state.

To be honest, I don't know. CEC is PITA to get it right and I don't know single platform where it works good in all cases. It also depends on TV...

Quote from offbeat

There are some issues with RTC, getting spam in dmesg.

Quote from offbeat

HDMI-CEC seems to be failing, more spam in dmesg:Doesn't wake up after suspend, using stock IR remote power button

Strange. I don't have this box but other developers do. Nobody reported such issues. This would suggest that external 32 kHz oscillator is missing. I'm pretty sure at least some GS1 boxes have it. Can you open your box and make high quality image (so all markings are readable and all components distinguishable)? It's possible that this is another revision and they changed few things.

Quote from offbeat

Doesn't wake up after suspend, using stock IR remote power button

Sadly Beelink GS1 is the only H6 board without proper suspend/resume support. One of our developers couldn't make it work.

Quote from Timpanogos Slim

Will have to sort out exactly how to do that though.

During playback, press anything so OSD shows. Select settings, deinterlacing and switch it to off.

Quote from Timpanogos Slim

By MCE remote do you mean the kind that come with a USB dongle?

Yes, they usually come with USB IR adapter. Any IR remote that speaks RC6 MCE should work.

Quote from Timpanogos Slim

I also have some of the IR remotes that come with random chinese android tv boxes

These usually speak NEC and won't work.

Timpanogos Slim btw, are you able to share that failing HEVC sample? I would like to add it to my collection so next time I'm working on HEVC decoding I could test it and hopefully fix the issue.

Quote from 2can

Yes, that also works, and the UI is more responsive than the version lower-gpu-clk you've shared before

Thanks! I'll send fix soon.

Quote from levitsky86

I was very surprised that there was no RC written on the newer 20210320 version (means its final?).

Yes, nightly images now use Kodi 19.0 final.

2can Can you please test LibreELEC-A64.arm-10.0-devel-20210326183118-32b3089-pine64-plus-gpu-432-MHz.img.gz ? Only change is that GPU is now clocked at 432 MHz, which is supposed to be highest safe clock rate (nightly images run at 576 MHz and previous test image at 297 MHz). If this works, I'll open PR with fix. Please also tell how smooth/sluggish UI navigation feels.

2can Please test this image: LibreELEC-A64.arm-10.0-devel-20210325222737-32b3089-pine64-plus-lower-gpu-clk.img.gz

No, not really. This is Allwinner subforum which doesn't have passtrough enabled by default. You should provide link generated by pastekodi command in that other thread.