Le Potato SBC (Libre Computer ​AML-S905X-CC)

  • On Armbian Le Potato forum I get a hint about the MAC address and it works.

    It can be manually inserted in /etc/network/interfaces file

    Code
    hwaddress ether xx:xx:xx:xx:xx:xx

    I ssh into libreelec and that file don't exist.

  • @cata474 You are right, the file does not exist in LE. Don't worry, I'm compiling 8.2.2.2 now which should fix both booting and random MAC address. If testing goes well, I'll upload it tonight.

  • Purely out of interest, what is the benefit of using a “Le Potato” board over any other S905X based device? (I can imagine a static hardware platform is more appealing to LE devs, similar to the rpi in the sense it is a known quantity.)

    Is the LE build for it able to run a mainline kernel? I have seen websites advertising the board as capable of using the 4.9 LTS kernel and others stating mainline 4.13. Is this true or just wishful thinking/bold marketing?

    Thanks very much.

  • Adr3nal1n SBCs like Le Potato, Odroid-C2 and perhaps Khadas VIM have usually better vendor support than cheap boxes. As you also mentioned, you get a "static" hardware.

    I am not advocating for or against any concrete SBC, everyone should judge their needs.

    As for mainline Linux, it is possible to run mainline kernel on S905/905X/912 but the mail limitation for LibreELEC is lack of hardware video decoding support.

  • Ah I see, thank you kszaq for the info and for your continued work on the Amlogic LE builds.

    Your LE 8 builds have allowed me to swap out the lounge RPi3 for a generic Chinese S905X device without my wife even noticing and with the added benefit I can also now enjoy smooth playback of HEVC content.

  • kszaq: Is it possible to use LePotato's composite out with your build? If not, are you (or anybody else) aware of a – preferably Linux-based – Kodi implementation that allows this?

    Thanks in advance for any help!

  • Manuel It should be possible but I cannot test if for the moment. What you need to do is replace this line in boot.ini:

    Code
    setenv libretech "no_console_suspend logo=osd1,loaded,0x3f800000,${hdmimode} vout=${hdmimode},enable hdmimode=${hdmimode} cvbsmode=nocvbs consoleblank=0"

    with

    Code
    setenv libretech "no_console_suspend logo=osd1,loaded,0x3f800000,576cvbs vout=576cvbs,enable hdmimode=${hdmimode} cvbsmode=576cvbs consoleblank=0"
  • Well, that does indeed work. Is "576cvbs" PAL progressive? Is there also an interlaced mode? I'm using this on an old CRT TV and at least on the Raspberry Pi I used before, interlaced produced a much better picture.

    Are these modes/parameters documented anywhere? I searched for "setenv libretech" but couldn't find anything useful.

    Is there also a Kodi 18 build available for this board? AFAIK the Amazon video plugins don't work in 17, right?

  • Is "576cvbs" PAL progressive?

    As far as I can tell it's PAL interlaced.

    Are these modes/parameters documented anywhere? I searched for "setenv libretech" but couldn't find anything useful.

    No, this is a custom boot configuration file based on what was already provided for Odroid-C2.

    Is there also a Kodi 18 build available for this board? AFAIK the Amazon video plugins don't work in 17, right?

    Yes, GDPR-2 provides builds for LePotato based on LE master + community patches.

  • I have dug out my Le Potato and put a fresh install of the Alpha version on. It ran ok for a couple of hours before locking up the same as happened when tried the old kszaq version used to, and I packed it away.

  • I have dug out my Le Potato and put a fresh install of the Alpha version on. It ran ok for a couple of hours before locking up the same as happened when tried the old kszaq version used to, and I packed it away.

    The following folder will have a fixed LE 8.2.5-Bootloader test .img.gz for Le Potato:

    Google Drive

  • Tested the latest Alpha version (v8.90.006 ALPHA) on my Le Potato as I'd put it away in a cupboard again and managed to get it to freeze within a couple of minutes by testing copying so guess its bootloader hasn't had the potential fix applied to it.

    As all the Raspberry Pi's I used are on the stable versions I've tried the Bootloader test version from the wrxtasy link and it has only been a few hours but everything I've tried to trigger it to crash which included copying around 10GB worth of files from NFS mount which would previously have caused it to crash within a minute worked fine, and even managed to watch a film at the same time.

    Going to continue to test, but its survived where it's fallen over previously so far.