Problem displaying X throught the LVDS

Ok, there are some things to explain.

1. Why did the old kernel not start?

Well, fsimx6-V2.1 was still based on kernel 3.0.35. The step to fsimx6-V3.0 brought a newer kernel, 4.1.15. One of the major changes that went with this new kernel was the support and usage of device trees. This represented a major change of how the whole board support was done and this also had quite some influence on the end user. This was the reason why we gave this release a new major number and not just increased the minor version behind the dot. It definitely *is* a major change. Supporting device trees also needs a different way of starting the kernel. The old kernel only needed the kernel image, but the new version needs the kernel image *and* the device tree image. This means also U-Boot needs to know about this, because it needs to provide a pointer to the device tree instead of a pointer to the ATAGS structure that was used before. Unfortunately this is a compile time decision in U-Boot. This means you can either compile U-Boot to support the old variant of starting the kernel, or the new variant of starting the kernel. As we now need the new variant, this automatically means that such an U-Boot is not capable of starting an old kernel anymore.

You now have two options: Either downgrade U-Boot and continue to use your old system, or update your system to the new way of things.

2. Why is there no output on the LVDS display?

The old version fsimx6-V2.x started all available displays. The idea was that independent of what display the user has connected, he should see something. However we realized that not all users were aware of the fact that the system had actually up to four displays running at the same time. They had their display, but there were also other framebuffers for other displays in the background and the board did actually send out data to these displays, which resulted in a much higher system bus and CPU load than was actually needed and had therefore a much higher power consumption than needed. It would have been possible to switch off these other displays, but most users didn't do this and therefore had all displays running even in their final software.

So when the step to the new kernel and device trees came, we also reconsidered the way how displays are configured. Now only one display is active by default and this is the display where most of our customers order their starter kits with. And this is usually the digital RGB port. Only on boards where this port is not available (like armStoneA9r2), this is by default the LVDS port.

So what I believe is that you simply have the display output on the digital RGB port, not on the LVDS port. This is why you do not see any output. You have to modify the device tree to switch to LVDS port. This is rather simple. Just select a different display for CONFIG_ARMSTONEA9_MXCFB0 (see armstonea9q.dts). Then recompile the device tree and install the resulting device tree image on your board.

3. Why is the platform name different, armstonea9 vs. armstonea9q?

The i.MX6 CPU is available in different types. As Solo, DualLite, Dual and Quad. (There are even more versions like Solo-X and UltraLite, but we have these other versions in separate releases, so we can restrict our view on these four versions for now.) When looking at these four versions, Solo and DualLite are rather similar and Dual and Quad are rather similar. But Solo/DualLite have quite some differences to Dual/Quad. In the old kernel we could hide these differences nonetheless, but for the new kernel these two groups actually need a different device tree, which is something we can not completely hide. So we need one device tree for Solo/DualLite, which we call armstonea9dl.dtb, and a different device tree for Dual/Quad, which we call armstonea9q.dtb. But of course in all other places we want to stay as similar as possible in all our i.MX6 versions. So for example in our installation script we use the platform name as base to determine the device tree name. We simply load the file $platform.dtb. So if we need different device trees on these two different platforms, we also need to name the platforms differently. This is why the platform for Solo/DualLite is now called armstonea9dl and for Dual/Quad it is now called armstonea9q.

4. Qt and X11

When preparing a release with the new kernel 4.1.15, it showed that NXP did not have a fully working support for Qt5 under X11 anymore. Qt5 is still available of course, but only when running directly on the framebuffer, not on top of X11 anymore. So our new Qt5 configuration is without X11, just Qt5 on the framebuffer. In 99% of the cases this is the better solution, because especially in embedded systems you usually only have one specific application and therefore do not have the need for other, X11 based applications in parallel. And then leaving X11 completely out reduces the root filesystem size considerably, which also speeds up the boot time. And it is also quicker when rendering.

On the other hand our standard root filesystem image (fsimx6_std_defconfig) is still based on X11. So if you use this root filesystem with your precompiled application, it will not work because there is no support for Qt in this X11 image. And if you build a root filesystem with our fsimx6_qt5_defconfig, then your precompiled application will not work because it will look for X11, which is not there anymore in this case. So you actually have to re-compile your application on top of a new Qt5 based root filesystem.

5. How to proceed?

For a quick solution I would recommend downgrading U-Boot to the version of fsimx6-V2.1 and continue using your old system. Please note that you should also erase the UBootEnv in this case, because some settings are different in the new environment which may clash with the older version. However erasing UBootEnv also erases the MAC address of the board. So please note down the address (environment variable ethaddr) and set it again after you have downgraded U-Boot. The final six digits of the MAC address are also printed on the bar code sticker on the board, the first six digits are always 00:05:51 for F&S. So you can also look up the number from the sticker if you like.

For the long term view, you should consider updating your software to the newest version. For example we are planning to update our regular system to kernel 4.9 soon. It will still take a few weeks, but if you wait until then, you can completely skip kernel 4.1. and can directly go to 4.9. On the other hand it may be easier to port to the current version now as the step is not so big as going directly to 4.9. In any case I would recommend reading the FirstSteps documentation of the current version as it helps understanding how the current version is used. And also the Readme.txt files of the releases fsimx6-V3.0 and fsimx6-V3.1 may help because they explain all the differences to the previous versions.

Your F&S Support Team