Posts by Inkyfingers

    I think it's worth trying a inet1 ... In any case - thank you very much!

    Welcome, an inet1 image has compiled successfully, named, LibreELEC-A10.arm-9.80-devel-20201025105102-6552c51-inet1.img.gz


    That is compiled from a (historical) point from which I do not yet have a Cubieboard image to test.

    To concentrate on the positive ....

    I will be glad to keep A20 port alive or resurrect it later.

    That would be great, thank you. Reading recent testing results on the Nightly images for A20, A64, H3, H5, H6 and R40 boards thread, is it the case that a number of recent commits have led to this situation?


    It would be good if your proposed port could be taken at a point just before any such troublesome commits and, if at all possible, in the most stable possible position. I think all the Allwinner early adopters would appreciate the port you propose, thanks jernej.

    I think it's worth trying a inet1 dtb file

    I can confirm sun4i-a10-inet1.dtb exists on a current Armbian image. I noticed that "the board differs slightly". So you could think about just booting Armbian to test it and/or following my recipe above.


    inet1 appears to be supported within libreelec sources and should compile.


    We plan to do a compile overnight Sunday.

    I think the main problem is the dtb.

    I'm sorry to hear neither image has worked for you - it's frustrating testing an image with an incorrect dtb.


    We have now compiled a Cubieboard A10 image from LibreELEC sources. Thinking of compiling a PengPod image, in a quick search, I have not found all needed resources.


    What experience have you had of running a Linux distro on it? Have you any evidence that it is supported elsewhere?

    What happened above is that I compiled a blob (.dtb) from Projects · U-Boot / U-Boot · GitLab which, according to Linux mainlining effort - linux-sunxi.org, could be expected to be good for kernel 4.4, with work on hdmi audio showing as work in progress for A10, along with all the other Allwinner boards supported by LibreELEC.


    Update


    Homework and lockdown have led to slow progress. With a Class 10, A1, SD card and proper power supply, I can report that LibreELEC (using this 8 month old image) is running well. Sound is rich, display of content is good, in looking for defects, any seen are at the level of recording or streaming defects. Credit to the Lima driver devs creating such flexibility.

    Damage to the UI is seen, very much less random than first reported. The interface is usable.


    cubieboard.dtb


    Following your suggestion, roel with thanks, we booted Armbian. As it turned out the task was easier than expected. Credit and thanks to Armbian, we found in /boot/dtb-5.8.5-sunxi, sun4i-a10-cubieboard.dtb which we transferred to the LibreELEC SD card (adjusting libreelec/extlinux/extlinux.conf to suit).


    LibreELEC was tested before and after adding 'correct' sun4i-a10-cubieboard.dtb. Power and decent SD card were the more significant factors.

    LED activity, without blob seemed random, with the blob, LED in line with /sys/class/leds/triggers.

    Hi, roel thank you for those ideas.


    I have now made some progress cross-compiling. I have an image which boots using my sun4i-mainline-cubieboard.dtb, but kodi fails to start.

    I have serial output

    [ 4.900510] #0: sun4i-hdmi

    [ 4.908784] #1: sun4i-codec

    [ 4.940005] Run /init as init process


    On monitor, hangs at:

    Started target Kodi Mediacentre Interface

    Reached target Kodi Mediacentre Interface

    ... waits 2 minutes and restarts


    In the logs below I see this mismatch:

    Serial output:

    [ 4.900510] #0: sun4i-hdmi

    Kodi.log:

    ERROR: CAESinkALSA::Initialize - failed to initialize device "hdmi:CARD=allwinnerhdmi,DEV=0"


    It seems quite pertinent to the reason kernel 5.x fails to do hdmi-sound atm.

    If I am able to help, I would be interested if further testing, I guess it is a kernel patching job, I read that greater minds than mine are on the case already.:thumbup:

    kodi.log  serial output

    I am here after digging out my early A10 1 GB Cubieboard for my grandson and an interweb search for Media Centre + Cubieboard. Sorry we are so late for the call for testers but many thanks for providing this image. Credit and kudos jernej and to all.


    Image tested, "Mele A1000": LibreELEC-A10.arm-9.80-devel-20200216105054-0b8cbed-mele.img.gz


    I am very pleased to report we have kodi running on a 1GB A10 cubieboard and I am working through the user manual. I am being slow to access full functionality. We have notes suggesting the sound and display were unreliable in first tests. The problems are not fully reproducible.


    Issues met


    Booting with a mouse attached led to "characteristic" display trouble, with no mouse we had substantial improvement.


    Power. First tests included with SATA attached. Later tests no SATA, checked output voltage of my power packs. I have ordered another power source.

    I have not eliminated the possibility that voltage dropping under load contributes to poor performance, stalling and card corruption.


    In our first tests, first-boot was with Ethernet attached. I would have assumed this was best. Due to suspected card corruption in early tests, I first booted my current good SD card independently. Ethernet introduced when asked for by "first user" wizard. Wi-fi failed (probably unsupported stick) and avoided.


    Display.


    We sometimes saw evidence of damaged display, in the form of a horizontal wriggle, wave or shake. I have not concluded if this is a fully negative thing, or an advanced feature advising user they are at an edge of inoperability.

    Valid animation is seen. Weather is displayed in an array of 3 rows. Arrow keys select row up and row down. With bottom row selected, hitting down arrow causes a shake or negative animation, tells user this is an invalid keystroke.

    Borderline display error. A video is left running. Hit Escape to UI. The video still just seen through transparency of UI. Keyboard strokes appear to damage the UI display. This user avoids this behaviour and assumes we are at the edge of inoperability.

    Before sound was fixed, most keystrokes led to a violent shake. This seemed wrong, caused user to fix up sound.


    This fits with 'other stuff going on' and insufficient resources to generate the display correctly, but the disturbance has the character of a deliberate animation.


    Sound.


    I introduced a /STORAGE/.asoundrc, initially to try to get sound to hdmi (not possible).


    The use of a valid .asoundrc seemed to improve display. This .asoundrc seems to give clear analog and clear display.




    Settings -> System -> Audio offers 3 options:

    ALSA: sun4i-codec, CDC PCM Codec-0

    ALSA: On-board SPDIF, spdif-dit-hifi dit-hifi-0

    PULSE: Default, Bluetooth Audio (PULSEAUDIO)

    Selection 1 is in use.



    At time of writing I would like to test a correct dtb. I have not been able to convert

    sun4i-a10-cubieboard.dts

    to a dtb using dtc, Version: DTC 1.4.7 due to reported syntax errors. Working on that, or some other method.


    Thanks again.