Cubox i4 Pro

  • vpeter exact same problem here.

    1. that kernel fixes, but will there be a build of 8.1.x with that kernel?

    2. is there a reason why the fixes in the build you link to can't be in mainline libreElec? it's dissapointing that openElec doesn't have this problem when i much prefer libreElec...

    thanks! ;)

  • 1) I'm building this images for some time. And will probably in future.

    2) Because there are two different Linux versions used. Some time back decision was to use more modern kernel to allow docker. But obviously this path didn't went well.

  • 1. Thanks! :)

    2. What advantage to allow docker? Maybe better if libreelec uses a kernel that allows best hardware support for supported architectures...

    cheers.

  • 2) To allow running some extra sw on same machine. There was multiple requests for this. But now probably no one is using this :(

    To build image with 3.14 kernel

    Code
    PROJECT=imx6 ARCH=arm LINUX_VERSION=3.14-sr make image
  • vpeter thanks. using a kernel that enables unneded extra junk to be run but cripples kodi on some architectures is totally against the idea of "just enough os for kodi"! libreElec should refocus on their mission statement.

  • vpeter thanks. using a kernel that enables unneded extra junk to be run but cripples kodi on some architectures is totally against the idea of "just enough os for kodi"! libreElec should refocus on their mission statement.

    Well, this problem happens to only some users. For me all versions works perfectly. You just need correct TV :huh:

  • The radical Linux graphics rework/changes being brewed for Kodi Leia should (maybe) allow iMX6 to move up to a mainline kernel so there's not much appetite for further fiddling on 3.14 and 4.4 versions. If things pan out, they will be thoroughly obsolete.

  • If imx6 hardware is able to run on a mainline kernel and use a more modern code stack the platform as a whole will benefit from other changes and improvements to Kodi and Linux graphics. Right now Kodi is the top layer of a "house of cards" that balances precariously on a vendor hacked Linux kernel. Our long standing challenge and general beef with SolidRun is that there are unresolved issues and the sole developer they have supporting their community efforts never appears to fix anything that benefits us, and never upstreams or publishes any of his patches. I have no idea whether moving up to a mainline kernel will "fix" your issue or others, but imx6 things either change in the near future or we throw support under a bus and reverse over it a few times to make sure it's properly dead, then we go focus our energies on other more supportable silicon.

    IMHO .. stick with vpeter's images for now. The first two? OE 8.0 releases for imx6 didn't even boot (bad images) which should give you an indication of how much testing was done before release.

  • chewitt couldn't agree more re solidrun, i definitely would never have bought a cubox if i knew all the trouble and lack of support i was getting, but now i have it, so, need to try to keep it working usefully. ;) thanks for your replies.


  • Well, it is not really solidrun's fault for this situation. imx6 soc just doesn't have everything mainlined regarding graphics because Freescale Semiconductor (now part of NXP) behaves just like other manufacturers and keeps old Linux version stable. Meaning they maintain it's own Linux fork. Actually solidrun did great job with their own fork. But this is 3.14. From what I hear things progress to newer versions.

    Some time back I decided to use newer kernel from Xbian project which works well but it has some quirks. It works for most people but for some not. Just like cec thing on Rpi (it works for most users but there are few who are using my builds with little newer libcec library).

    Extra problem is that (very, very small) community around imx6 soc newer come together. Or at least I don't see this. Obviously I mean skilled devs. That's why we have different Linux forks with different problems. If all few people would work on one thing the situation would be better (I'm sure in this).

  • yeah. what it boils down to is i'll be _much_ more picky when it comes to choosing an soc architecture next time i buy.

    LTS kernel has just moved to 6 years support so embedded, soc, etc, manufacturers can have support for the useful life of a device, but this means nothing if the manufacturers aren't interested in keeping things supported...

    i agree with part of what chewitt was saying here in that it's much better to choose a platform based on how much it's drivers etc are in mainline, not in manufacturer forks. in factg i'd now say that is worth much more than most other factors.

  • However, going forward we will not adopt new SoC platforms without mainline support or a clear and achievable path towards it.

    makes a lot of sense, also as a buying guide if you want to build a minimal media hub with any life span.

    personally i will do a lot more reasearch beyond just current capabilities next time. live and learn. ;)