Support for A10/A20

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

  • You can't use dtc anymore, there is a problem with changes of syntax. You should use on a arm system:

    Code
    make dtbs 

    to create all dtb's or

    Code
    make sun4i-a10-cubiebaord.dtb
  • It seems I'm also late to the party...

    Firstly, kudos to @jernej for all the work!!

    I have PengPod 1000 based on AllWinner A10 lying around doing nothing. I was stoked when I learned about efforts being put into supporting it.

    I'll do what I can to help with testing. I tried the mele image and it didn't work out of the box... Unfortunately the board comes only with a mini HDMI output. When I get such a cable I will try again with an external display.

  • 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

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

  • 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?

  • 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?

    When I got it back in... I think it was 2013, there were some debian/ubuntu based images that I successfully used, but unfortunately they are no longer available. If I have time I'll try running some generic armv7 image, but if you have the knowledge and are willing to play around with libreelec, I think it's worth trying a inet1 dtb file,

    PengPod 1000 - linux-sunxi.org -> here it says they the boards are somewhat similar

    InstallingDebianOn/Allwinner - Debian Wiki -> here they mention the sun4i-a10-inet1.dtb file (but I have no idea how to get hold of it)

    In any case - thank you very much!

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

    Thanks for the info! Do I have to compile it myself or is can I download the image from somewhere?

  • @StaticallyLinked, I guess you are seeing that a specific Armbian inet image is not available. This paste hastebin shows why I think Armbian will boot inet1 without further compile, but perhaps I am over optimistic. Good luck.

    Thank you for all your posts! The last one got me searching again for the dtb file and I found it over at kali.

    After trying again I realized I had a screen issue all along (which invalidates all my tests), but I fixed it and after that I realized I probably need to do this, since my battery is dead (it's been dead for a long time, but I thought if I just plug the power cord it would work... the way a notebook does... but in this case it just shows the battery animation for a couple of seconds and turns itself off).

  • I'm interested in this inet1 stuff. The problem is with these tablets is that you should know which protocol the display is using. This should be defined in the dts to get it working. I don't have the knowledge to create such a dts, so a example of a working dts for a tablet would be a good starting point.

  • Guys, I'm considering removing A20 support from master branch, which would also mean no more nightly images and certainly no stable images once LE10 is released. I tested olinuxino micro A20 board today and there is a ton of kernel related issues. In order to fix them I would need to spend considerable amount of time studying various HW cores which I don't want (A20 HW is pretty different in comparison to any other currently supported AW SoC).

    Observerd issues:

    - HDMI audio driver crashes at resolution switch

    - HDMI audio sometimes doesn't work

    - HDMI EDID is sometimes read incorrectly (fall back to 1024x768 and no audio)

    - HW video decoding crashes (out of memory) during interlaced H264 video playback

    - after playback, Kodi GUI may become corrupted (GPU driver issue? Kodi bug? who knows)

    In my opinion, above issues make images unusable, except in some not so common cases. Additionally, SoC is very weak and memory has limited bandwith. Even a bit newer H3 is much better supported and has none of the described problems.

    If there is someone who wants to fix above and possibly other issues, I will be glad to keep A20 port alive or resurrect it later.

  • Guys, I'm considering removing A20 support from master branch

    sad to hear, but I guess the strength of the A20 in 2020 is the native SATA port, not a main driver for LE.

    So switching to a H3 or H6 makes sense.

    Just as a side note the battery of my inet f97ii nearly blew up, my tablet got split in two parts and the batt was like a cussion. Thank god nothing happened.

    Just to be aware of ageing cheap lipo cells.