Saturday, 7 June 2014

I.MX6 Debian Jessie (GPU/VPU) 3.10.17_GA

Given that we a finally have a GA release of the 3.10.17 kernel and BSP from Freescale (although there also is a 3.10.31 alpha release in the pipleline). Here is an upgraded the Debian Jessie rootfs. You can download it from here and my previous 2 posts (here and here) cover installation and configurations step. Furthermore you require a kernel based on this release with the appropriate dts file for your i.mx6 device. This is a barebone rootfs with gpu/vpu support  and as previously stated I use this rootfs mainly for development. I haven't observed any major changes since the 3.10.17 beta release.

32 comments:

  1. Hi Jasbir. I got your 12.x preview image running some time ago. Know I want to try this new rootfs of yours. I have a fundamental question though. Do I need an additional kernel if I want to boot this image ? You say "Furthermore you require a kernel base on this...". Or does this mean that if I want to make my own image I need to get a so-and-so based kernel ?

    ReplyDelete
    Replies
    1. Hi, kernel dependents on which device you are deploying to? If it is a GK802 then see the comment by Haakon Stende (below) for deployment.

      Delete
  2. I have made a lxde version og the rootfs.
    http://stende.no-ip.info/imx6/rootfs/3.10.30/jessie-lxde-3.10.17_GA-libs.tar.xz with kernel sources for 3.10.30 in /usr/src/linux from https://github.com/linux4kix/linux-linaro-stable-mx6

    For GK802 users I have made an installer script:
    http://stende.no-ip.info/imx6/gk802/3.10.30/scripts/mk_jessie-lxde_gk802.sh

    hste

    ReplyDelete
    Replies
    1. Hi Haakon,

      I've looked at your rootfs and I have a couple of newby questions. Do I need to have the same kernel version as the rootfs? Also, I'm unsure how to setup the dtb and uBoot. Do I simply replace the dtb file on your rootfs with my wandboard dtb file (and change uEnv.txt)? When I install uBoot it seems to want the dtb on a seperate boot partiton. Any help is appriciated. I'm using the Wandboard-Quad, rev C1.

      Delete
    2. Hello,

      Just wanted to give an update. So I used your rootfs with a Yocto kernel, dtb, and uBoot for Wandboard rev C1 (all 3.10.17). The system boots and I am able to login and LXDE is up and running.

      I am however having an issue with hardware acceleration. When I look into the Xorg.0.log file I am given a familiar error of:
      EE) AIGLX error: dlopen of /usr/lib/arm-linux-gnueabi/dri/vivante_dri.so failed...
      Which causes X to go back to software rendering.

      After searching the internet I found that replacing the file (or adding it) does not fix the issue since this file does not export extensions. I am able to run glxgears and I get ~45 FPS on 1920x1080. I know dri is not needed but my FPS is low which confirms no hardware acceleration.

      The glxgears only runs under X11 and when I use the two provided scripts to change to fb or wayland then glxgears no longer runs.
      Lastly, just to check, I swapped your kernel for the Yocto kernel I was using and the system was able to boot to the graphical logon screen but locks up once I start to type. This is most likely something I did wrong here but just an FYI.

      Any advice is appreciated, also thanks in advance for this rootfs; it has helped out a lot!

      Delete
  3. Hi,
    first, this image is awesome! It worked perfectly on my cubox-i4-pro using patched 3.0.35 kernel!
    I have been trying to get 3d acceleration working with opensuse but I get X.Org freezing real bad. The interesting part is thta I am too using xserver 1.14. Do you know if the xserver included in your image has been patched, and alos what patches have been applied?

    ReplyDelete
    Replies
    1. Hi,
      For the latest Debian release no specific patches have been applied to xserver.

      Delete
  4. Hi,

    after a dist-upgrade (and a ./switch_to_fb.sh;ldconfig) the examples from gpu-viv-bin-mx6q-3.10.17-1.0.0-hfp/opt/viv_samples/vdk/ (eg tutorial7) stopped working.
    They just run less then a second and show nothing on the screen.
    Is this image meant to be dist-upgradable?

    ReplyDelete
    Replies
    1. The reason seems to be newer library versions in testing than the delivered vivante libs are compatible to.
      (I installed a jessie version with snapshots from June 7th and it worked again)
      Do you know a place, from where the libs can be obtained as source code?

      Delete
    2. Hi,

      I wasn't expecting a dist-upgradable to always work, What xorg-server version does it report?

      Delete
    3. What would you suggest for dealing with upgrades? Pinning all the xorg packages? Anything else?

      Delete
    4. Short term is to pin the xorg packages.

      Delete
  5. Hi,
    I found that some of your rootfs (jessie and xubuntu13.04) have common mistake in "etc/udev/rules.d/10-imx.rules": first line (which is comment) misses # symbol, thus comment interpreted as part of config.

    ReplyDelete
    Replies
    1. Thanks for finding that!

      Delete
    2. BTW, I tried a lot of kernels and rootfs and I'm stuck with one problem:

      (II) VIVANTE(0): FB Start = 0x75e9d000 FB Base = 0x75e9d000 FB Offset = (nil)
      (WW) VIVANTE(0): Fixup RGB ordering
      (WW) VIVANTE(0): must be after RGB ordering fixed
      (II) VIVANTE(0): test Initializing EXA
      (II) EXA(0): Driver allocated offscreen pixmaps
      (II) EXA(0): Driver registered support for the following operations:
      (II) Solid
      (II) Copy
      (II) Composite (RENDER acceleration)
      (II) UploadToScreen
      (EE) VIVANTE(0): internal error: GPU Ctx Init Failed
      (EE) VIVANTE(0): internal error: initExaLayer failed in VivScreenInit()
      (WW) VIVANTE(0): xf86SetBlackWhitePixels
      (WW) VIVANTE(0): finished xf86SetBlackWhitePixels
      (WW) VIVANTE(0): Calling xf86SetBackingStore
      (==) VIVANTE(0): Backing store disabled
      (==) VIVANTE(0): DPMS enabled

      I did checked sources and found that "GPU Ctx Init Failed" printed by xorg vivante_drv, after that xorg server crashes with sigfault, so no X session is started. I don't know why this error happens.

      What I have:
      - wandboard with imx6q
      - wandboard kernel 3.10.17_ga built from sources
      - graphic libs (libGL*, libGLES*) from yokto 1.6 for 3.10.17 kernel
      - different rootfs: your debian jessie and xubuntu 13.04, my built yokto 1.5/1.6

      in all cases X server doesn't start and crashes. Did you faced such issue earlier? Some ideas?

      Delete
    3. my fault: my script was copying libGAL*, libGL* and other libs to wrong locations. Fixed and crash gone.

      Delete
    4. I think that posting instructions here will be a bad idea, because building a rootfs from scratch isn't simple and requires many actions. You can check build scripts form Jasbir here: http://stende.no-ip.info/files/
      They may require some additional tweaking, but they are good starting point.

      Delete
    5. Another hint: when you'll finish read Jasbir's scripts, you can move forward and google for "imx6 arch". Jasbir's scripts aren't complete and missing some things: libdrm2 must be patched and then X should be rebuilt against that patched libdrm2, for example. You will find Arch forum threads that are discussing how to run Arch on imx6 boards and there will be links on github for build scripts.

      Second hint: dive into yocto project which is officially supported by freescale. Since some system libs need a patching (as I said Jasbir's scripts missing that) this is a main reason why freescale doesn't officially support distros other than yocto: debian and ubuntu distributed mainly as binaries and any modifications require extra efforts. Yocto project distributed mainly as sources and its build system provides flexible tools to create own versions of distro by supplying own scripts/patches to overlay project's configuration and build your own custom system. Examining yocto project is a longer and harder way, because it will require learning of Bitbake build system and reading of lot bitbake scripts, but this will provide you most complete vision how to build your own system for imx boards.

      Good luck.

      Delete
  6. As per stunpix comments if you want to build a rootfs from scratch then its quite involved and I wouldn't suggest you attempt it if your inexperienced.

    If you require a customised rootfs for a commercial project then I provide support.

    ReplyDelete
  7. Hello,

    I am new to embedded Linux and have a few questions about building everything for my Wandboard-Quad rev C1. I'm not interested in building/creating a rootfs but I'd like to know how to assemble things together to get my board running with hard float and be able to run/create OpenCL apps. I'd also like to have a desktop GUI (something similar to Gnome) running as well.

    Do I follow this site: https://eewiki.net/display/linuxonarm/Wandboard to the letter and simply use your rootfs instead of downloading the one he says?

    His build of Linux is 3.17, from what I gather, will this create an issue with the 3.10.17 rootfs you have?

    I keep running into issues of either getting the code from Freescale and there isn't a DTB for Wandboard quad or not knowing exactly where to write items to the SD card:
    I.e:
    - Is the DTB written to the rootfs or somewhere else? If rootfs how to tell uBoot?
    - Is the kernel written to rootfs or somewhere else?
    - Will a kernel know where to look in your rootfs to know how to launch desktop GUI?

    Again, I know these are basic questions but being completely new to embedded Linux (Linux in general) I am getting a bit confused here.

    Also, thank you for the work you've done putting this rootfs together. It seems getting OpenCL and OpenGL along with Vivante drivers and X11 running together is a harsh challenge.

    ReplyDelete
    Replies
    1. OK, so I used your rootfs with the instructions found in my original post. When I 'startx' I get an error of ...no screens found... and saying it cannot find the vivante modules. Also, when I enter 'service lightdm start' I get an OK but the system just returns to the command prompt. I'm sure I'm doing something wrong here.

      Delete
    2. Hi,

      You can get the wandboard kernel through this link http://wiki.wandboard.org/index.php/Wandboard_Linux_Kernel_3.10.17_Status.

      If your trying to get OpenCL and/or OpenGL support then you might be disappointed. The i.mx6 supports OpenCL EP (Embedded Profile) which is a light version and in my experience it very limited. Officially the i.mx6 support EGL/ELES, there is some unofficial OpenGL support but its not a full implementation.

      Delete
    3. Thank you for your response!

      I am going to be using OpenCL EP for some number crunching like FFTs and regression testing along with some simple parallel equations (massive addition/subtraction/multiplication/division). I'm not interested in anything graphics related. From your experience is OpenCL EP adequate for these operations?

      Delete
    4. The OpenCL EP implementation is very limited, the kernel size has to be small and there is no support for 'atomics'. In my opinion I would say don't use it unless your willing to invest a large amount time trying to work around the limitations or your usecase is fairly trivial.

      Delete
  8. OK, thank you! I'll investigate some other options.

    ReplyDelete
  9. I am wondering whether it is possible to build a working version of KODI (XBMC) with your rootfs? Do you have any experience with this?

    ReplyDelete
  10. I'm considering using this for our custom imx6 board. Our current OS is based on https://eewiki.net/display/linuxonarm/Wandboard , as it's quite similar to a Wandboard Dual. Unfortunately there's still no GPU acceleration on mainline linux.

    My goal is a stable system with 1) package management (Debian/Ubuntu) and 2) GPU acceleration able to handle JFX: https://wiki.openjdk.java.net/display/OpenJFX/OpenJFX+on+Freescale+i.MX6

    I'd be happy for opinions on this. Would it work? Anyone have experience with JFX on imx6?

    ReplyDelete
    Replies
    1. JFX can easily light up 2 cores on the imx6 so one of the first items to consider is whether your application is graphically lightweight or not? This may lead you to having to re-engineer your application so it that is better optimised for an embedded platform. Another point to note is that JFX isn't fully polished for ARM so some features may not work as expected. In short it's difficult to fully answer to question without knowing more about your application and what level of performance you expect to achieve.

      Delete
    2. I think I phrased my question badly. The JFX application isn't my task, but I'm sure it can be modified if need be - at the moment we're running it non-accelerated and it's just unacceptably slow.

      My question was rather:
      If we migrate from 3.19 mainline to 3.10.17_GA, are we likely to get 1)a stable system, with 2)package management, capable of 3)GPU-accelerated JFX? We already have (1) and (2) today with mainline.
      Or are there any issues you know of that would prevents this? I'm trying to avoid going down a dead end.

      Delete
    3. 1) 3.10_17_GA is relatively stable but replaced by 3.14.28. These are FSL releases so you can raise defects against it with FSL. However they don't contain later kernel features or drivers which can mean you have to backport code across.

      2) For 3.10.17/3.14.28 would need to roll your own package management.

      3. GPU-accelerated JFX, You will you get 'acceleration' however if you may not meet your performance expectations (and potentially lead to a dead end). Unfortunately there is a tendency to expect PC like performance on this processor without first understanding its capabilities and the graphics stack involved.

      Delete
    4. 1) 3.10_17_GA is relatively stable but replaced by 3.14.28. These are FSL releases so you can raise defects against it with FSL. However they don't contain later kernel features or drivers which can mean you have to backport code across.

      2) For 3.10.17/3.14.28 would need to roll your own package management.

      3. GPU-accelerated JFX, You will you get 'acceleration' however if you may not meet your performance expectations (and potentially lead to a dead end). Unfortunately there is a tendency to expect PC like performance on this processor without first understanding its capabilities and the graphics stack involved.

      Delete
  11. This comment has been removed by the author.

    ReplyDelete