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

    Взаимодействие с другими людьми

    Quote from robvh

    If you have an ssh connection, use ir-keytable -t then point your remote and click. The scan codes should get printed if the remote is recognized.

    Look in /usr/lib/udev/rc_keymaps for a toml file with matching name, or grep one of the scan codes and look for matching files.

    Put matching filename into /storage/.config/rc_maps.cfg like so

    echo "* * x96max.toml" >/storage/.config/rc_maps.cfg

    Read more about remotes and keymaps in Infra-Red Remotes - LibreELEC.wiki

    Is there an x96max.toml file in /usr/lib/udev/rc_keymaps, or does it need to be created?

    • Official Post
    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 jernej

    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).

    Burned test image to SD card, booted, burned to eMMC. Had a rather limited access to TV during this weekend, so enabled SSH and tested using shell and remote.
    1) Cold boot via power toggle and issuing 'systemctl suspend' = box reboots in a few seconds. Subsequent 'systemctl suspend' seems to suspend the box, remote power button doesn't wake it up.

    2) Cold boot and 'systemctl poweroff' (or remote power button) = box reboots in a few seconds. Subsequent 'systemctl poweroff' (or remote power button) shutdowns the box, remote power button doesn't wake it up.

    BTW, poweroff take quite some time, ~15-20 seconds on cold boot, all the shutdown jobs run instantly and then its sitting there, waiting for something.. Wonder if its related to sun6i-rtc/cec-dw_hdmi oscillator problems. Here is a journalctl log captured on poweroff:

    Quote from jernej

    Anyway, I see 32 kHz oscillator - that long component under 24 MHz crystal. I have no clue why it doesn't work.

    Any way I can rule out (or confirm) hardware problem? Perhaps I can try booting stock android, not sure it supports CEC though, or RTC clock. Any other modules depend on this oscillator?

    Quote from robvh

    If you have an ssh connection, use ir-keytable -t then point your remote and click. The scan codes should get printed if the remote is recognized.

    Look in /usr/lib/udev/rc_keymaps for a toml file with matching name, or grep one of the scan codes and look for matching files.

    Put matching filename into /storage/.config/rc_maps.cfg like so

    echo "* * x96max.toml" >/storage/.config/rc_maps.cfg

    Read more about remotes and keymaps in Infra-Red Remotes - LibreELEC.wiki

    So, you mean to say that i should be able to use my MCE remote with the built-in CIR receiver on the board?

    I am basically conversant with lirc but haven't been as big of a user for the last 10 years or so.

    Quote from Timpanogos Slim

    So, you mean to say that i should be able to use my MCE remote with the built-in CIR receiver on the board?

    I am basically conversant with lirc but haven't been as big of a user for the last 10 years or so.

    The Wiki page points out that you do not have to activate lirc, because the kernel now translates IR events. You just have to tell the kernel about you (MCE) remote. This is accomplished with the rc_maps.cfg file. Anyway, read the Wiki page. Look in /usr/lib/udev/rc_keymaps if there is (already) a toml file for your remote. Otherwise, construct one yourself.

    • Official Post

    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:

    Code
    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.

    Quote from jernej

    Regarding RTC - it would be helpful, if you could read address 0x07000004 from Android.

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

    Code
    # busybox devmem 0x07000004
0x00000004
# echo "0x07000004,0x07000008" > /sys/class/sunxi_dump/dump
# cat /sys/class/sunxi_dump/dump
0x0000000007000000:            0x00000004 0x0000000f

    I see you had some relevant discussions when merging RTC support for H6. Re: [linux-sunxi] [PATCH v2 0/3] Add basic support for RTC on Allwinner H6 SoC - Jernej Škrabec

    Also, other user had this problem on GS1 Beelink GS1 Allwinner H6 - General Chat - Armbian forum

    So even if it is a hardware problem, whole batch has it then.

    Quote from jernej

    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)

    Sounds easy enough, could do it in a week or two, no access to required hardware atm.

    Regarding Tritium H3,

    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.

    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.

    • Official Post
    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.

    Quote from jernej

    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.

    1) RTC is fixed, time is saved between warm startups/reboots, nice!

    Code
    # cold 
Feb 02 15:29:47 LibreELEC kernel: sun6i-rtc 7000000.rtc: registered as rtc0
Feb 02 15:29:47 LibreELEC kernel: sun6i-rtc 7000000.rtc: setting system clock to 1970-01-01T00:00:03 UTC (3)
Feb 02 15:29:47 LibreELEC kernel: sun6i-rtc 7000000.rtc: RTC enabled

# warm
Mar 30 17:20:41 LibreELEC kernel: sun6i-rtc 7000000.rtc: registered as rtc0
Mar 30 17:20:41 LibreELEC kernel: sun6i-rtc 7000000.rtc: setting system clock to 2021-03-30T17:20:37 UTC (1617124837)
Mar 30 17:20:41 LibreELEC kernel: sun6i-rtc 7000000.rtc: RTC enabled

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

    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

    Code
    Mar 30 17:12:22 LibreELEC kernel: OOM killer disabled.
Mar 30 17:12:22 LibreELEC kernel: Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
Mar 30 17:12:22 LibreELEC kernel: printk: Suspending console(s) (use no_console_suspend to debug)
Mar 30 17:12:22 LibreELEC kernel: PM: dpm_run_callback(): platform_pm_suspend+0x0/0x70 returns -16
Mar 30 17:12:22 LibreELEC kernel: PM: Device 1800000.gpu failed to suspend: error -16
Mar 30 17:12:22 LibreELEC kernel: PM: Some devices failed to suspend, or early wake event detected
Mar 30 17:12:22 LibreELEC kernel: OOM killer enabled.
Mar 30 17:12:22 LibreELEC kernel: Restarting tasks ... done.

    Thank you!

    • Official Post

    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.

    • Official Post
    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.

    Quote from jernej

    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.

    I will investigate further with other streaming sites and from my server. Probably it's only related to the mpeg-dash streams.

    Quote from jernej

    SMB1 is not supported anymore and afaik you must use username/password with SMB2/3

    I know, it's because on my khadas vim1 and firefly M1 I have to login also with username and pasword and there it works. On the tritium not I get the response "check your credentials" while I'm sure username and password are correct. But as I said, maybe I didn't try enough. SSH works though.

    Quote from jernej

    Preferred way to check CEC on mainline Linux is to stop Kodi (systemctl stop kodi) and run cec-ctl --playback -S.

    Tested Beelink GS1 CEC with a capable TV, command line scan and power on / standby are working just fine.

    Kodi CEC plugin integration isn't yet stable though:

    1) Bootup always brings up TV, shutdown mostly puts TV to standby, but sometimes Kodi crashes on shutdown and fails to send standby CEC command to TV. Didn't have time to check crash logs yet, only saw gdb core process before shutdown in htop.

    2) When it comes to suspend, there is like 50%/50% chance to standby TV as well. Perhaps suspend is too fast and doesn't wait for the result of CEC command?