Posts by fs-support_HK

    Let me give some background information.


    The reason why the releases are really complicated this time is the fact that we do not think that NXP's way of grouping and installing the boot loader software makes much sense for an open platform like ours, where there are many different applications by many different customers. NXP always assumes that the user is the manufacturer of the whole hardware and also the developer of the whole software. For example if a manufacturer produces a sound bar for a TV, then he does everything from the hardware, over the OS, right to the application software. Then it does not matter if the software is slightly more complicated to install, it is just one software and it will work somehow and the software people know all the details anyway.


    But in our case we just do a small part of the hardware and also only the OS part of the software. Our customers do the rest, and we do not have control over this remaining process. So we have a completely different situation. Our customers are not familiar with all the Linux and U-Boot internals. They want to write their high-level application software and do not want to bother about any low-level stuff. So it actually does matter if installation is complicated.


    So why is it complicated? On i.MX8, there are quite a lot more files involved when booting the system compared to i.MX6. There is an ARM Trusted Firmware (ATF), there are DRAM timings, there is a DRAM Training Firmware and may be even a Trusted Execution Environment (TEE). Then we need a board configuration file. The new platforms are using eMMC for booting, too, which makes a method with hardware jumpers that we used with NAND in the past impossible. We now have to actually store the board identity somewhere in eMMC or NAND. There may be an additional HDMI firmware, and on i.MX8X, there are even more files like a SECO firmware and an SCU firmware. And so on and on.


    This is all stuff that a regular customer is not interested in. It should simply work. But if we used the NXP way of installing software, all our customers would have to deal with all this low-level stuff. This would include downloading additional repositories, copying files from here to there and calling several build commands, just to get the image for the boot loader done. And as you can see, I also mentioned DRAM settings. The DRAM controller is far more complex now on i.MX8 as it can also handle DDR4 and LPDDR4. This means actually every RAM type, every RAM size and every board type with a different signal routing needs its own configuration. This would result in a separate boot loader for every single version of a board. Different RAM chip, different boot loader. Different RAM size, different boot loader. Different PicoCore or efus module, different boot loader. We would end up having literally hundreds of boot loaders for all our different combinations. This is not manageable, it does not make sense.


    So we thought a lot about this and tried to do it better. And we were successful. We use a rather different approach now. Where "different" is only with respect to NXP. In fact it is rather similar to the way of installing software on our i.MX6 platforms, where a small piece of software called NBoot is always pre-installed on the board. This is how it will be on the i.MX8 boards in the future again. There is this pre-installed NBoot, and all the additional low-level stuff I mentioned is now included there and the customer does not have to care about it. He can build his U-Boot and Linux software exactly like before. Completely simple.


    But what is looking so simple in the end was a tough piece of work to implement. We now have it done for i.MX8MM and are doing our tests right now. After that we can pack the first release. Then we will move on to the other i.MX8 variants, where we only expect minor modifications. Unfortunately i.MX8X is one of the more complex variants with regard to the boot process, so I'm not sure if it will be right the next one or if we have other CPU variants first that are more similar to the i.MX8MM. We have to discuss this internally how we proceed. But be assured that we'll keep in mind that you are waiting for it. We'll try as fast as we can. But two months are gone rather quickly.


    I know this information is not very satisfying, but you also have to understand that it does not make sense to do any final releases with documentation and everything, that we also have to support for a long time, when the whole installation process will change again in the near future. So we waited until everything is available. This is the case now. The big implementation is done, Now we only have to do the releases, one after the other.


    So please have some more patience.


    Your F&S Support Team

    No, you can create a regular Qt application like on any desktop. You do not need "Qt for Device Creation". Each module has its own list of licenses. If you are in Buildroot and check all the packages in package/qt5 (they are listed in the makefiles with .mk extension), then you will see that each has a different set. And there are even differences between the versions. For example:


    If you use Qt-5.6, then you have the following licenses for the following modules (I only list a few):


    qt5wayland: GPL-3.0 or LGPL-2.1 with exception or LGLP-3.0, GFDL-1.3 (docs)

    qt5charts: -

    qt5quickcontrols: GPL-2.0 or GPL-3.0 or LGPL-3.0, GFDL-1.3 (docs)

    qt5quickcontrols2: GPL-3.0 or LGPL-3.0, GFDL-1.3 (docs)


    This means if you only need qt5wayland, you can use LGPL-2.1 or LGPL-3.0. If you also need qt5quickcontrols and/or qt5quickcontrols2, then you can only use LGPL-3.0. But you can not use qt5charts, not even with a full OpenSource project, because it is only available with the commercial license.


    If you use Qt-5.12, then the set of licenses is slightly different:


    qt5wayland: GPL-2.0+ or LGPL-3.0, GPL-3.0 with exception(tools) , GFDL-1.3 (docs)

    qt5charts: GPL-3.0

    qt5quickcontrols: GPL-2.0 or GPL-3.0 or LGPL-3.0, GFDL-1.3 (docs)

    qt5quickcontrols2: GPL-3.0 or LGPL-3.0, GFDL-1.3 (docs)


    This means the LGPL-2.1 was dropped from qt5wayland, you have to use LGPL-3.0 now, even if you do not need qt5quickcontrols and qt5quickcontrols2. You still can't use qt5charts under this license, but you can use qt5charts at least in a full OpenSource project, because it is available under GPL-3.0 now.


    So it is very important to know what Qt5 modules you will actually need. And you cannot use some modules if you want to stay with LGPL.


    This licensing system may also force you to stay on an older Qt version. For example if you began your software with LGPL-2.0 and Qt-5.6 and you used qt5wayland, then you can not update easily to Qt-5.12, because there you would be forced to use LGPL-3.0, which may contradict the license obligations of other (non-Qt) modules in your software. Sou you would have to stay on Qt-5.6.


    Please note that Qt has changed the licensing conditions a few months ago with regard to LTS versions (e.g. Qt-5.15) and Qt-6. If you want to use the commercial license, this can only be done by a subscription now. So you need to pay regularly and most important the license will get void if you stop paying. So you have to renew your subscription every year as long as you want to sell your devices. This is quite a risk as you do not know how the subscription fees will develop in the future. In our point of view this is a big drawback for Qt now.


    As you see, the licensing is quite complex. And if you'll ask people from Qt, they will always direct you to the commercial license, of course because they want to earn money. This is perfectly OK if you can live with the license fee. And of course it is easier, you do not have to care about what you may use or not. But if you want to stay free of costs, you have to be very careful about what you actually use.


    To summarize:


    - If you want to be OpenSource, there is no big problem. Most packages are available under the GPL. Exceptions may exist, like qt5chart above.

    - If you want to be ClosedSource and stay free of costs under LGPL, you are restricted to those modules available under LGPL.

    - If you want to be ClosedSource and use all modules, you need the commercial license.


    Your F&S Support Team

    Meanwhile I have few questions (more will follow).

    1. Most important one and very confusing to me. I haven't yet grasped the process development for Embedded Linux. In MCU apps you develop code, compile, flash to MCU, test and then flash in serial production. I am not sure how it is done with Linux. So I have Linux Kernel, Buildroot (or Yocto,...) FS, FDT (which I will have to adapt to my peripherals later) and Uboot. I need to develop GUI application - let's say with Qt, custom FDT. How I then join everything together into 1 binary to use in serial production? Do I (simplified description) first upload System Software to devboard using Uboot and application via network, set up everything and then download all binaries via Uboot+TFTP and get image, which is to be used in serial production programming. Or how everything is integrated together? I haven't seen this described anywhere and it seems it isn't addressed in any of your workshops.

    Buildroot and Yocto as configured in our example configurations only provide the runtime environment. So you need an additional step to build your own application software and add it to the system. There are different options to do this.


    1. Add your own application to Buildroot/Yocto as an additional package and include it in the root filesystem
      Here you add your own application as a package to Buildroot or Yocto and use their build process to also build your application. As such a package, the build process will automatically include your application in the root filesystem. Obviously this is only an option if Buildroot's or Yocto's build system is capable enough of building your application. And it restricts you to command line compilation. So it is not meant to be used together with an IDE.
    2. Compile your application separately, but still add it to the root filesystem
      Here you can compile your software in any way you like. Most importantly you can also use an IDE, where you can test and debug your application. The only thing you have to be aware is that you have to compile and link against the libraries of Buildroot/Yocto. This basically means you have to use the toolchain that is provided by these environments. Yocto builds its own toolchain and you have to refer to this toolchain in your IDE.
      Buildroot does not build an own toolchain but uses our provided toolchain instead. However it still creates some wrappers in output/host/bin that can (and should) be used instead of the globally installed toolchain because these wrappers will take care of all include and library paths so that they point to Buildroot's versions.
      Then when you are done with development, you simply copy your software to the root filesystem. In Buildroot, you can simply add a script file that is run at the end of the build process (in Buildroot's menuconfig) and use this script to copy all necessary files to the root filesystem in output/target. The resulting root filesystem image contains everything that is in this directory. In Yocto, you need a small recipe to do a similar thing.
    3. Compile and install separately
      In this version, you compile your software as in step 2. But instead of finally copying the software to the root filesystem, you create a separate image file for your application. Then you store this image separately on the board, e.g. in an own partition or as an own UBI volume. At runtime, this image is then mounted separately (e.g. via /etc/fstab) as an own directory or as an overlay on top of the root filesystem.

    Each method has its own pros and cons.

    2. Developing GUI. It seems that with F&S our only option is to use Qt. Since this option requires licensing I am asking, if there are any FOSS options, which can be used in commercial applications and still supported by F&S platform.

    There are more options available. The GUI can either use Wayland or render directly to the framebuffer. X11 was available for previous boards, but NXP does not have any X11 support with i.MX8 CPUs anymore. So Wayland is usually the way to go. But on top of this, you are free to use your environment. For example GTK+ is also possible, or Enlightenment or DirectFB.


    But even if you go with Qt, you are not necessarily required to buy a commercial license, as long as you restrict your software to Qt modules that are also released under the LGPL. This typically happens after a couple of years. If you do not need the newest 3D stuff and the newest internet protocols, this may still be sufficient for a pleasant application.

    3. Building FDT. Are there any guides how to build FDT with specific HW - for example I don't think my currently used display (NT35521_OLED) is supported in any of the device trees in 20201106 fsimx8mm-B2020.08-pre.tar.bz2. How to add more devices - like touchscreen, I2S sound sink... I assume Linux drivers are required for all such devices (unless some slow peripherals, with which we can work directly over (serial) data buses).

    The PicoCoreMX8MM is still rather new and we are still in some kind of transition so that the software will work as similar as possible to our previous boards. Normally you only have to set the display timings that you take from the data sheet and replace them in the device tree. That is not too difficult and we can assist you with this if required. In the future there will also be an option where you can configure the display in U-Boot by setting some environment variables, but we are still working on this.


    For devices that we have in our device tree but that you do not need, there is sometimes a #define that you can comment out and then the device is disabled. Or you simply comment out the appropriate device nodes. For any extra hardware on your carrier board, you have to add appropriate nodes to the device tree. The necessary properties are explained in Documentation/devicetree/bindings in the Linux source code tree. Again, we can assist you if you have any specific problems.

    4. Buildroot and Yocto. Which one to choose - what are the factors for the selection (as far as I know Yocto is newer).

    There is no older or newer, both systems are updated on a regular basis. Buildroot gets an update every three months, Yocto every six months. However we can not follow every release of the upstream packages, so our update steps are a little bit slower.


    From our point of view, Buildroot is much easier to use. You have a menu driven configuration system. If you ever have configured a Linux kernel, then you know this. It is the same system on Buildroot. So you see all available packages, you select all packages that you need and deselect all packages that you don't. Then save your configuration and finally say "make". Buildroot now fetches all source packages from all over the world, applies some patches to support cross compilation and then builds all the packages. Finally it generates an image with all these components. This is the root filesystem that you download to you board. If you need an additional package or want to remove a package, go to menuconfig, tick or untick the package, call "make" again and you have the new image (well, there are some constraints here and there, but you get the idea). Most importantly you do not need to know anything about the build process at all. Just call make. For all parts where you are supposed to change something, there are appropriate hooks that you can use easily. Even if you want to add your own package, you simply read the Buildroot documentation which needs about 4 hours. Then you know how to do this.


    Yocto is different. Of course the basic idea is similar. You define what packages you need and Yocto will download and build them all and creates a root filesystem image at the end. However Yocto has its own build system called bitbake. This is driven by so-called recipes, small script files, that tell bitbake what to download and how to build. Unfortunately these recipes are used for everything. So even adding or removing a package needs some modification in one or more of these recipes. You do not even get an overview of what packages are currently part of your final image. You can only list all the recipes that are involved. So modifying anything in Yocto requires a) knowledge of the recipe script language and b) a full understanding of the build process, so that you know where to modify a variable or where to add a small script function. Our own experience has shown that you need at least two weeks of training until you are capable of doing anything other than building some sample images.


    Our goal is always to make it as easy as possible for our customers to work with our boards. This is why our primary system is Buildroot. New releases from our software are available for Buildroot first and for Yocto later.


    There are two things that may force you to use Yocto. First, support for the big web browsers, i.e. Chromium or Firefox, is only available in Yocto, not in Buildroot. There is a small HTML5 browser called Midori, but of course with quite less features. And second, Yocto is doing one thing better than Buildroot. Before building the root filesystem image, it creates a repository of all the binary packages that it has compiled. The image is then actually built from this repository. This means that if you need several different versions of your image, for example for different variants of your device, you simply define a big Yocto configuration that contains all the packages that may ever be needed by any variant, and then you simply pull in different subsets of these packages in your different filesystem images. And theoretically you can even use this package repository on a server so that your boards can download additional packages at runtime in the field, like on any desktop Linux distribution.


    So the decision between Yocto and Buildroot would go like this:

    • Do I need any of the packages that are only provided by Yocto? Then use Yocto.
    • Do I need any of the unique features of Yocto like the package repository? Then use Yocto.
    • Otherwise use Buildroot.

    Your F&S Support Team

    With this 5.4 release, we will join i.MX6, i.MX7ULP and i.MX8 to use the same code base and we will try to make the i.MX8 code work more in the F&S way of doing things, i.e. the way that our customers are used to. This requires some basic modifications (compared to the NXP way of doing things) in how we boot our systems, especially because some new boards will boot from eMMC only, so that our previous NBoot will not work in the same way anymore. Kernel is already ported to the new version, Buildroot and Yocto still require updates and of course U-Boot and the boot environment in general will still need some work. And of course a lot of fine tuning and testing of the device drivers. So we do not expect a regular release before November.

    I'm a little bit confused by the mode list from the xrand output. This seems to be a rather generic list, not a list that is assembled from the EDID data of this specific display. So my guess would point to a problem when reading the EDID data. Unfortunately I do not have the full boot messages, so I can not tell if there is something going wrong.


    How did you get the EDID specificiations that you listed above? Was this some output of a Linux command on our board?


    Your F&S Support Team

    In the past, on the fsimx6 platform, the backlight was only switched on once at start. But is was not switched at all when the display was disabled and/or enabled at runtime. Strictly speaking, this was not correct. But making this work requires a matching name between backlight and display, which is done by the fb-names entry. This entry already existed in the past, but the name(s) given there did not match the internally generated framebuffer names, because the framebuffer names were based on some hardware units of the CPU, namely the IPU number and the display port number on the IPU. In our device tree, you do not have to care about IPU and display port. You just need to set the MXCFB_* macros and everything else is determined automatically. Unfortunately it was not possible to also create an appropriate name for the backlight in this concept, so the name never matched. So actually all backlights were always enabled, which was why it happened to work for you.


    We changed this in the new version. Now the internal framebuffer names are named after their function, so the framebuffer used for LCD is named "lcd", the framebuffer used for HDMI is named "hdmi" and so on. Now, the mapping is rather simple and the switching actually works. But this means that a backlight correctly stays disabled if the corresponding display framebuffer is not active. This is why the backlight was off in your scenario when using the new version.


    Our default device tree maps this backlight to the LVDS display(s), but you use it for the LCD display. This is perfectly OK, but you needed to change this mapping accordingly to make it work.


    Your F&S Support Team

    Do you use this backlight with an LVDS display or is the display connected to the RGB-LCD port? In the latter case, you have to change the following line in the backlight_ldb node from

    Code
    1. fb-names = "ldb0", "ldb1";

    to

    Code
    1. fb-names = "lcd";

    And maybe it makes sense to change the node name, too, because otherwise it would be misleading.


    Your F&S Support Team

    The default loadaddr has changed from kernel 4.1 (fsimx6-V3.1) to 4.9 (fsimx6-B2020.04). Now it is 11000000 (previously 10800000) and the device tree is loaded to 12000000 (previously 11000000). When you still have the old settings, you most probably did not erase the U-Boot environment when upgrading U-Boot. Issue the following commands in U-Boot


    nand erase.part UBootEnv

    reset


    Now you should have the correct default settings and the kernel will boot. Of course if you had set some own variables, you have to do this again now.


    The reason for this change is that the new kernel image uses more space when unzipped. With the old settings, it will overwrite the device tree that is stored behind it, which causes the kernel to fail. This is why it still works with your kernel that is slightly smaller.


    Thanks for pointing out the problem with the clock settings. This is in fact a bad setting in the armstonea9qdl.dtsi device tree. I have attached a small patch that will fix this. Apply to the source code with the following command

    Code
    1. patch -p1 < 0001-Fix-audio-clock-settings-in-armstonea9qdl.dtsi.patch

    Please note the less-than character for input redirection.


    Your F&S Support Team

    i.MX6 Linux Release B2020.04 (Buildroot)


    This is a maintenance release for fsimx6. fsimx6 is the software for all boards from F&S that are based on the i.MX6 Solo, DualLite, Dual or Quad CPU from NXP (or i.MX6 for short). Currently this consists of the boards efusA9, armStoneA9, armStoneA9r2, PicoMODA9, NetDCUA9, QBlissA9 and QBlissA9r2. More boards may be added to this family in the future. All these boards can work with software that is created from this release package.


    The release consists of two files:


    fsimx6-B2020.04.tar.bz2

    This is the main release itself containing all sources, the binary images, the documentation, examples and the toolchain.


    sdcard-fsimx6-B2020.04.tar.bz2

    If you copy the contents of this archive to an SD card, you can install our precompiled standard system in a very straightforward and comfortable way on the board. The SD card archive is meant for people who just want to try a release first without having to download the quite large main archive. Its content is also contained in the main release archive, so if you want to download the main archive anyway, you don't need to bother with the SD card archive.


    These tar archives are compressed with bzip2. So to see the files, you first have to unpack the archives

    Code
    1. tar xvf fsimx6-B2020.04.tar.bz2

    This will create a directory fsimx6-B2020.04 that contains all the files of the release.


    Please read the file doc/FSiMX6_FirstSteps_eng.pdf. It describes the first steps when working with the board and gives references to further reading.



    Release Notes for fsimx6-B2020.04


    Here are some highlights of this release.


    1. New framebuffer names and display backlight handling


    The framebuffer devices are now internally named after the function, i.e. "lcd", "hdmi", "ldb0", "ldb1". And the display backlights also switch on and off together with the display driver. This was different in the past.


    Please note that this adds some additional on-off cycles when starting the X-Server. This is because the X-Server reconfigures the display several times and each time the display is switched off temporarily.


    You can add property unblank_delay to an mxcfb node to hide any unwanted display content before the display shows the regular image.

    Code
    1. mxcfb0: fb@0 {
    2. compatible = "fsl,mxc_sdc_fb";
    3. late_init = <0>;
    4. unblank_delay = <50>; /* 50ms delay */
    5. ...
    6. };

    We also fixed a bug in this release, where a backlight brightness of 0 was not handled correctly if the PWM brightness uses inverted logic. It is fixed by adding the new property "keep-power" to the underlying PWM port in the device tree. We have added this to all PWM nodes now.



    2. Video playback also possible without camera


    Previously, hardware accelerated video playback with gstreamer was only possible when also a camera was configured in the device tree. We fixed this. Now playback is always possible, also without a camera setting.



    3. Update to Buildroot 2019.05.3


    We have updated to the newer release Buildroot 2019.05.3 that has some more security and bug fixes.



    4. New toolchain fs-toolchain-8.3-armv7ahf


    It showed that Qt5-webengine will not compile with a toolchain before gcc-8.0. So we have updated the toolchain again. Please use this new toolchain together with the code of this release.


    Remark: When changing the toolchain, you should always clear the compiler cache, e.g.

    Code
    1. rm -r ~/.ccache ~/.ccache-buildroot

    Otherwise the compiler may mix up precompiled code from the cache with newly compiled code, causing strange runtime errors.



    5. Add support for A/D-Converter ADS1118


    Thanks to a customer, we now have support for the A/D-Converter ADS1118.



    6. Default LVDS display replaced


    The ChiMei LVDS display that F&S used to ship with some Starter Kits is not available anymore. We will ship a different display from now on. Therefore we also changed the default settings for LVDS in the Linux device trees so that upcoming customers will have a working display.


    If you still need the previous settings, simply remove the two comment slashes at the beginning of the following line in the device tree and re-build the device tree. Then the old settings will be active again.

    Code
    1. //#define DISPLAY_LVDS_CHIMEI

    This change was actually already part of the previous release but we missed to mention it in the README text back then. We added a comment in the forum, but we repeat it here, just to be sure.



    7. Improved LinuxOnFSBoards.pdf documentation


    We have further added content to the generic Linux documentation. Now everything up to and including chapter 6 with the F&S specific U-Boot enhancements is rather complete. But the chapters behind that are still work in progress and need more attention in the future.


    -----------------------------------------------------------------------------------


    The following list shows the most noticable changes in this release in more detail since our last regular i.MX6 release. Please note that the source code is also used for other platforms. This is why you will also find references to other CPU types and F&S boards here in the changelog.


    nbootimx6ul_41.bin (VN41) (20.02.2019)

    Supported Boards: efusA9, armStoneA9, armStoneA9r2, PicoMODA9, NetDCUA9, QBlissA9, QBlissA9r2


    NBoot for i.MX6 shares the source code with other i.MX6 CPU variants like i.MX6UL and i.MX6SX, therefore versions are counted consecutively.


    [VN38]

    • 0003890: Add SD boot fuse settings

    [VN39]

    • 0004117: Reset sendsize after USB upload
    • 0004116: Disable warning in emfast driver
    • 0004115: Add info output over USB
    • 0004114: Change checksum calculation to use neon processor

    [VN40]

    • 0004196: Change spread spectrum settings for better EMC
    • 0004197: Set VCFL_ON to input, pin is driven high in ROM loader
    • 0004195: Verify image if 'x' is pressed when security enabled

    [VN41]

    • 0004210: Add super secure version with disabled menu
    • 0004211: Move SDP disable fuse settings to separate function


    u-boot-2018.03-fsimx6-B2020.04 (14.04.2020)

    Supported boards: armStoneA9, armStoneA9r2, efusA9, PicoMODA9, NetDCUA9, QBlissA9, QBlissA9r2, armStoneA5

    Not tested: efusA9X, PicoCOMA9X, PicoCoreMX6SX, efusA7UL, PicoCOM1.2, PicoCoreMX6UL, NetDCUA5, PicoCOMA5

    • Add support for RGB adapter on fsimx6ul
    • Add basic support for ethernet switch MV88E6071
    • Add register offset 0x00 or 0x10 to mv88e61xx.c driver
    • Fix parsing of mii devices in mii command
    • Better argument parsing and error handling in mdio.c
    • include: update log2 header from the Linux kernel
    • Handle self-clearing Port Reset bit in ehci-hcd
    • Fix function to find nearest High Speed parent in usb.c
    • Improve USB device detection, add variable usb_connect_time
    • Port drivers/crypto/fsl from NXP UBoot 2018.03
    • Add support for FS_SECURE_BOOT
    • Add defconfigs for FS_SECURE_BOOT
    • Add FS_SECURE_BOOT authenticate images
    • Improve display support for PicoCoreMX6UL
    • Fix SPI initialization in fsimx6sx.c
    • Improve board_display_set_power in fsimx6sx.c/fsimx6ul.c
    • Fix fsimx6sx.c lcd settings for PicoCoreMX6SX/PicoCOMA9x
    • Improve the M4 ram reservation for imx6sx
    • Allow percentage sizes and hex numbers in mmc hwpartition
    • Port drivers/crypto/fsl from NXP UBoot 2018.03
    • Add support for FS_SECURE_BOOT
    • Add defconfigs for FS_SECURE_BOOT
    • Add FS_SECURE_BOOT authenticate images
    • Rename F&S Secure Boot defconfigs
    • Improve verification process of FS_SECURE_BOOT
    • Improve F&S secure boot defconfigs
    • Update fsvybrid infrastructure
    • Fix MAC address handling on fsvybrid


    linux-4.9.88-fsimx6-B2020.04 (14.04.2020)

    Supported boards: armStoneA9, armStoneA9r2, efusA9, PicoMODA9, NetDCUA9, QBlissA9, QBlissA9r2, armStoneA5

    Not tested: efusA9X, PicoCOMA9X, PicoCoreMX6SX, PicoCoreMX7ULP, efusA7UL, PicoCOM1.2, PicoCoreMX6UL, NetDCUA5, PicoCOMA5

    • Add support for mipi display YTC310KLAA
    • Add YTC310KLAA mipi display to fsimx7ulp
    • imx6ull: VDD_SOC_CAP -> changed voltage from 1.175V to 1.25V
    • Add PWM_A to PicoCoreMX6SX device-tree
    • Improve picocoremx6ul.dts - add defines for HW units
    • Improve picocoremx6sx.dts - increment board revision
    • Improve F&S i.MX6SX/UL device-trees - Update Copyright
    • fec_main: Do not init MII bus in case of fixed link
    • Add DP83848 Ethernet PHY to fsimx6ul_defconfig
    • Improve fsimx7ulp VLLS state by turning of LPDDR-IOs correctly
    • Add audio support for imx7ULP via rpmsg-audio
    • Fix DT for efusA9, QBlissA9 and QBlissA9r2 for ft5x06_ts.c
    • Add mainline patches to remove compiler warnings with gcc-8
    • Remove compiler warnings with gcc-8 in F&S specific files
    • Fix clock enabling in pxp_dma_v3.c, add to fsimx6ul
    • Support gstreamer imxv4l2sink with PXP on fsimx6sx
    • Add RTC IRQ settings on efusA9 and efusA9X
    • Add check for valid memory-region to auxcore-driver
    • Improve fsimx6sx/fsimx6ul device-trees
    • Improve picocoremx6sx device tree - fix bl_pwm
    • Improve PicoCoreMX6SX/UL device-tree - VLCD_ON pin
    • Remove rpmsg message from efusa9x.dts
    • Add missing RTS/CTS for UART_C on PicoCoreMX6SX
    • Fix Ubis crashes after resume from suspend
    • Fix ov564x_mipi devicetree entry
    • Improve mxs-dma driver by adding runtime_suspend support
    • Improve USB settings of picocoremx7ulp.dts
    • Improve picocoremx7ulp device-tree
    • Add support for mipi display TM050JDHG33
    • Improve picocoremx7ulp devicetree, set new default MIPI display
    • Improve picocormx7ulp lpi2c5 node
    • Add LVDS clock source and audio clock speed selection to fsimx6 boards
    • Fix video output dependency from enabled camera on imx6 boards
    • Fix clock problems on Vybrid
    • Rename VF610_PAD_PTA28__ESDHC1_DATA2 to VF610_PAD_PTA28__ESDHC1_DAT2
    • Make fsvybrid_defconfig more similar to other fs... defconfigs
    • Add F&S NAND driver vf610_nfc_fus
    • Add support for UART, ETH, LEDs and audio to armStoneA5
    • Add optional clock to sdhci-esdhc-imx.c
    • Improve imx-uart driver
    • Fix USB device port settings on fsvybrid
    • Fix indentation in mxs-dma-ext.c to avoid compiler warning
    • Handle several fb references in PWM backlight driver
    • Use meaningful framebuffer names im mxc_ipuv3_fb.c
    • Add device tree property unblank_delay to mxc_ipuv3_fb.c
    • Handle initial state in pwm_bl.c more consistently
    • Do not switch ldb regulator too often on i.MX6 platforms
    • Fix mxcfb driver probe fail
    • Fix wrong framebuffer name in devicetree for picomoda9
    • Add support for LCD-MI0700AJT
    • Add support for armstonea9r2 revision 1.20
    • Fix wrong framebuffer name in devicetree for picocoremx6ul & efusa7ull
    • Add support for A/D-Converter ADS1118
    • Improve pwm-imx driver - invert polarity via register
    • Improve pwm-imx driver - invert polarity via register
    • Support both PWM polarities for all F&S boards
    • Update TI wireless driver wlxxxx to kernel 4.9.217
    • Remove debug messages in Vybrid NAND driver

    buildroot-2019.05.3-fsimx6-B2020.04 (14.04.2020)

    Supported boards: armStoneA9, armStoneA9r2, efusA9, PicoMODA9, NetDCUA9, QBlissA9, QBlissA9r2, armStoneA5

    Not tested: efusA9X, PicoCOMA9X, PicoCoreMX6SX, PicoCoreMX7ULP, efusA7UL, PicoCOM1.2, PicoCoreMX6UL, NetDCUA5, PicoCOMA5

    • Fix Qt5 webengine build
    • Switch to fs-toolchain-8.3-armv7ahf for F&S boards
    • Add rpmsg-audio alsamixer config
    • Add fsimx6sx/fsimx6ul wayland defconfig
    • Add startup script for weston
    • Replace package silex-wlan-fs with newer version
    • Keep bluez5_utils-headers on same version as bluez5_utils
    • Do not install S50telnet by default, only if requested
    • Add spi-tools to F&S defconfigs
    • Rework of fsimx7ulp_std_defconfig
    • Add fsimx7ulp_wayland_defconfig
    • Improve rootfs_ext2_size of fsimx7ulp_std_defconfig
    • Rework of fsimx7ulp_qt5_defconfig
    • Add support for fsimx7ulp_qt5_weston_defconfig
    • Add default weston.ini file
    • Update fsvybrid support to kernel 4.9.88
    • Update to buildroot-2019.05.3


    Examples
    • No changes


    Toolchain

    fs-toolchain-8.3-armv7ahf.tar.bz2 for Linux

    • Based on gcc-8.3
    • Support for C and C++
    • Includes glibc-2.29 (compiled for ARM code)
    • With binutils-2.32
    • Hardware floating point
    • Native Posix Thread Library (NPTL)
    • Full support for C++14 and OpenMP 4.5
    • Basic support for C++17
    • Experimental support for C++2a


    Documentation
    • Update to version 4.1 of FSiMX6_FirstSteps_eng.pdf
    • Update to version 0.5 of LinuxOnFSBoards_eng.pdf


    Please download the hardware documentation directly from our website. Then you always have the newest version.


    Your F&S Support Team

    Are you sure that it is the GPIO driver that does the harm and not the effect of setting the GPIO. For example if the GPIO switches something on, then maybe the power supply is not stable enough, the voltage drops and *this* is the reason why the board stops responding. Just as an idea.


    Your F&S Support Team

    I think this is intended behavior. Let me explain.


    When a board is shut down with poweroff, all filesystems are unmounted and all drivers are stopped. Then the system issues a special "Wait for Interrupt" instruction and the SoC will drive a power-off signal. However only a few of our new PicoCore boards are actually capable of shutting down the power as a result to this signal, and this also needs help from the baseboard to actually cut off the power supply. Most F&S boards can not do this, the efusA9 being one of them. So in these cases, the board simply remains in the "Wait for Interrupt" state. If the watchdog is not used, then this state will remain forever, unless you have some other interrupt source active. However if the watchdog is active, then it can not be switched off again. This means the watchdog will trigger an interrupt after some time, which is after 128 seconds in our case (the maximum delay that is possible with the i.MX6 watchdog hardware). If the board would be powered off, then you would never see this interrupt. But as it isn't powered off, the system properly reacts to this interrupt an reboots.


    So if you really want to stop the board, you have to make sure that the board is actually powered off, for example by switching your power supply with a GPIO. Otherwise you will always have a reboot if you have the watchdog active.


    Your F&S Support Team

    Ok, try the following. In the device tree efusa9x.dts, replace the node


    with

    Code
    1. backlight_lcd {
    2. compatible = "pwm-backlight";
    3. pwms = <&pwm6 0 5000000 0>;
    4. power-supply = <&reg_ldb_bl>;
    5. brightness-levels = <0 1 5 10 18 28 41 56
    6. 73 92 113 137 163 192 222 255>;
    7. default-brightness-level = <14>;
    8. fb-names = "mxs-lcdif0";
    9. };

    This copies the relevant stuff from backlight_ldb to backlight_lcd and enables the backlight_lcd in any case. Please note that also all #ifs around the node are gone. Then rebuild the device tree (in case of Buildroot this is make linux-rebuild all) and store it on the board.

    When we use the LCD display on efus, we usually have a RGB adapter attached. for example the ADP-EDT1. This adapter then also handles the backlight with the help of a PCA9632 chip accessed via I2C. This is why we have associated the pins BL_CTRL (Pin 87) and BL_VBL_ON (Pin 89) with LVDS. I believe you are doing it differently. Can you explain a little bit more in detail where your backlight is connected and whether you are using such an RGB adapter or not.

    Quote

    To verify it I created a boot logo for the kernel (our company logo on white background).

    I also tried to send a raw image to /dev/fb0.

    Misusing the Tux-Logo for a company logo is the wrong way of doing things. The Tux will appear as often as you have cores in the system. So for example on a Quad-Core-CPU, you will have four Tux-Logos shown. This is not what you want.


    The first option to show such a logo is in U-Boot. When you are using B2019.11, then this feature is available.


    The second option is to have a Splash Screen in Linux. There is already a package in Buildroot that allows doing this, even with an additional progress bar. We have a documentation that shows how this is is done.

    By default, i.e. on the (text) console, automatic blanking actually *is* active. The console will be blanked after 10 minutes of inactivity and will be switched on again by a mouse movement or an arbitrary key. (The key has to come from a connected keyboard, sending a character from the terminal program through the serial line does of course not trigger unblanking).


    So it is actually the result of the GUI if screen-blanking is switched off. Then it is also the job of the GUI to switch it back on. Qt has appropriate settings, X11 has the x11screensaver, other GUIs should have similar functions for screensavers, too.


    Your F&S Support Team

    If your image is coming from a filesystem for example on USB stick or SD card, then you can also read the file in parts to RAM and then store each part on eMMC. Then you do not need to split up the file beforehand.


    The generic form of the load command is:

    Code
    1. load <device> <n> <ramaddr> <filename> <bytes> <offset>

    For example if you have 512MB of RAM, you can load your image in chunks of 256MB (0x10000000 bytes or 0x80000 sectors).

    Code
    1. load usb 0 $loadaddr emmc.img 10000000 0
    2. mmc write $loadaddr 0 80000
    3. load usb 0 $loadaddr emmc.img 10000000 10000000
    4. mmc write $loadaddr 80000 80000
    5. load usb 0 $loadaddr emmc.img 10000000 20000000
    6. mmc write $loadaddr 100000 80000
    7. load usb 0 $loadaddr emmc.img 10000000 30000000
    8. mmc write $loadaddr 180000 80000
    9. ...

    Please note that this is slightly more complicated if you use an SD card because you have to switch mmc devices in between.


    See also chapters "5.8.5 High-Level Read From Filesystem" and "5.9.3 Save to SD Card or eMMC" in the current Linux on F&S boards documentation. Chapters "5.10.2 Copy an External SD Card to Local eMMC" and "5.10.3 Copy Individual Files From USB Stick to Local eMMC" show similar examples in more detail.