Posts by fs-support_HK

    The whole boot strategy stuff in our environment is just a sequence of executing the bootcmd. This command simply does the following

    1. run set_bootargs; run kernel; run fdt

    So the whole magic lies in the variables set_bootargs, kernel and fdt. Each value is set depending on the boot strategy. If you just want to add an own script, you can simply call it in bootcmd as first call in front of run set_bootargs for example.

    There is also a variable preboot that we typically do not set. There you can also call your script. But please note the difference. The content of preboot is executed immediately at start, before the boot delay counts down (which is probably exactly what you want). The content of bootcmd is executed when the Linux system is started, which is considerably later.

    The hush parser that is used as command line interpreter in U-Boot supports simple control commands like the Bourne shell:

    if ... then ... else ... fi

    for ... do ... done

    while ... do ... done

    until ... do ... done

    It also has two test commands that can be used to evaluate expressions

    test for string compares

    itest for integer compares

    setexpr may also be useful to compute a value and store the result in a variable.

    You can call help test, help itest and help setexpr to get more information about these commands.

    Your F&S Support Team

    Just a side remark: If this is just a private project, everything is fine. But if you plan to sell this device to end customers, and you are using Bluetooth technology, then you are responsible for ensuring that the device is properly registered, certified and approved. This usually requires registering with the Bluetooth organization (SIG) and getting a QDID for the final device. To get a QDID, a test lab has to verify the compliance of hardware and software with the Bluetooth specification. This is typically not trivial and may even be quite expensive.

    This is completely different to using a USB Bluetooth device for example that is plugged into a USB port. Such a device is a separate standalone product that already has a valid certification of its own.

    The on-board WLAN/Bluetooth chip on the armStoneA9r2 is only part of a device. As the final certification must be done with the end product, it is always in your responsibility to do this certification. But of course we can support you when doing this.

    Your F&S Support Team

    In the changelog in the Readme text of every F&S release you can find the base versions of every package (linux kernel, u-boot, buildroot, yocto) that our versions are built on. For example if there is an entry ...

    NXP version rel_imx_5.4.70_2.3.2

    ... in the current fsimx8mm release, then this is based on the NXP kernel with tag rel_imx_5.4.70_2.3.2. The original NXP kernel git is available at


    So you can clone the original package and do a diff to see our changes.

    Your F&S Support Team

    The problem is more complex than it seems at the first look. It is not solved by replacing the timer variable in the Linux kernel by a 64-bit value. I think this was done quite a while ago. The problems are the interfaces to the outside. For example there needed to be new system calls that transfer new time values based on 64-bit types. And software in user space also needs to use these new system calls. The 64-bit calls are supported since glibc-2.32. So software that wants to use these calls also has to be compiled at least with glibc-2.32 or newer. But as far as I know, this is not done automatically, the software actually has to be modified to use the 64-bit timestamp variants. So not only the Linux kernel has to be fixed for the Y2038 problem, also all the user space software has to be fixed for the Y2038 problem.

    But even that is not enough. Also the file systems store time values, for example for the creation date or the last access. But the data structures in the directory or i-node entries are also defined a long time ago and can not easily be extended to use wider types. So also file systems have to be fixed for the Y2038 problem. This in turn has again an effect on the Linux kernel. When file systems are updated, also the Linux kernel needs to be updated again to support the new file system variants. Here is a table showing which file system has which limits. The table is taken from commit 9d14545bf9eed69fbd4af14b927a462324ea19 of the mainline Linux kernel. A similar list exists here:

    So where are we right now? The Linux kernel is supposed to be stable for Y2038 since 5.6 regarding the time value itself, the Virtual File System Layer (VFS), the system calls and all internal driver interfaces. The Y2038 patches have also been ported back to kernel 5.4. The last changes that I can see in the 5.4 branch that are labeled with y2038 are from 5.4.78. Current F&S releases on i.MX8 are based on 5.4.80, so these versions should be safe. Unfortunately there are no 5.4 releases for the i.MX6 boards yet. We are working on this, but it's not yet finished.

    The F&S toolchains for Buildroot based on gcc-8.3 are using glibc-2.32, so basically Buildroot is prepared to build Y2038-safe software. However if all packages in Buildroot are already updated to be Y2038-safe is a big question and I would doubt it. Yocto builds its own toolchain as part of the build process (it actually builds several toolchains). So checking the versions in Yocto is more complex. I can do this, if you really need this information. For the software packages in Yocot, it is the same question as for Buildroot.

    For the file systems, we typically use FAT and EXT4 on eMMC. As you can see, FAT is at least safe until year 2107, EXT4 is safe if the extra variant is used. On NAND we are safe, UBIFS is rather new and was using 64-bit time values right from the beginning.

    Is this all? You never know for sure. For example in kernel 5.10, there were some more changes to support a longer time range in the XFS file system. This has no effect unless you actually use XFS in your system. And of course if you simply use one single program in user space that is not converted yet, your whole system may still break in the year 2038.

    If you really want to be sure if your system is Y2038-safe, then you have to check every single program and every single library that you actually use. This is nearly impossible and therefore I believe that the chance is very high that it will still need some software updates before 2038 to fix further problems that pop up until then. So it is essential that you implement an update procedure in your device to be able to install newer versions of your software in the future. Having an update feature but not needing an update is far better than needing an update and not having an update feature.

    Your F&S Support Team

    Thanks for your response, but the question was what is the best strategy for modify u-boot to configure the imx6 IOMUX settings.

    Do I have to modify board/F+S/fsimx6ul/fsimx6ul.c file?

    Yes, this is a good place to do this.

    Do I have to copy board/F+S/fsimx6ul directory in other specific board directory with my own config items?

    No, this is not necessary. Just change our file. Then if we ever change something again, you'll automatically get the new changes when merging your code with our new code. If you have an extra file, you always have to take care to apply any changes that we did in our file to your extra file.

    How do I modify the default u-boot configuration?

    Some settings are modified via make menuconfig, some settings are directly given in include/configs/fsimx6.h.

    Your F&S Support Team

    Yes, showing an image on the display is basically possible since release fsimx6ul-B2019.11. However we want to add quite some more features for the display in the future, for example more image formats. So this version is only a first step and usage may change in the future. This is why we didn't put any emphasis on this feature in the past and the documentation is still rare.

    DIsplay Usage in U-Boot

    There are some new environment variables

    disppanel: Port and Name of a display

    dispmode: Timing parameters for the display

    dispflags: Additional flags


    The variable disppanel has the form <port>:<name>. <port> is one of the following values

    lcd Display is located on the parallel RGB port

    hdmi Display is located on the DVI/HDMI-Port (not supported yet)

    lvds0 Display is located on the first LVDS channel (not available on fsimx6ul)

    lvds1 Display is located on the second LVDS channel (not available on fsimx6ul)

    <name> is either a name from a list of predefined displays and then the parameters are taken from the internal entry. Or it is an own name and then the display parameters have to be given in dispmode and dispflags. At the moment only the following three Displays are predefined. These are the displays that we provide with our Starterkits.




    The easiest way is to use one of the predefined display. Then only one variable has to be set:

    1. setenv lcdpanel lcd:EDT-ET070080DH6

    For an own display, you simply take a freely defined name and add at least the dispmode variable.


    Variable dispmode contains pairs of the form <name>=<value>. They are seperated by commas and describe the display timings and clock polarities.

    clk: Pixelclock (in Hz, optional)

    rate: Refresh rate (in fps, default: 60 fps)

    hres: Horizontal Resolution (in pixels or clk-ticks)

    vres: Vertical Resolution (in rows)

    hfp: Horizontal Front Porch (in clk-ticks)

    hbp: Horizontal Back Porch (in clk-ticks)

    hsw: HSYNC Width (in clk-ticks)

    vfp: Vertical Front Porch (in rows)

    vbp: Vertical Back Porch (in rows)

    vsw: VSYNC Width (in rows)

    hsp: HSYNC Polarity: 0: Active Low, 1: Active High

    vsp: VSYNC Polarity: 0: Active Low, 1: Active High

    dep: DE Polarity: 0: Active Low, 1: Active High

    clkp: Pixelclock Polarity: 0: Latch on falling edge, 1: Latch on rising edge

    il: Interlaced: 0: No, 1: Yes (Not supported yet)


    1. setenv dispmode rate=60,hres=800,vres=480,...

    The parameters can be taken from the display data sheet. If you already have values for the Linux device tree, then you can use these:

    hactive -> hres

    vactive -> vres

    hfront-porch -> hfp

    hback-porch -> hbp

    vfront-porch -> vfp

    vback-porch -> vbp

    hsync-len -> hsw

    vsync-len -> vsw

    hsync-active -> hsp

    vsync-active -> vsp

    de-active -> dep

    pixelclk-active -> clkp


    Variable dispflags contains a list of flags, separated by commas. Flags are often meant for a specific display port. If a flag is given, the value is set. If it is not given, the value is unset. For now only flags for LVDS are defined.

    lvds2ch: LVDS display is in Dual-Channel-Mode (1st channel even pixels, 2nd channel odd pixels (not supported yet)

    lvdsdup: Both LVDS channels show the same image, i.e. it is a duplicated image on similar displays (not supported yet)

    lvds24: LVDS is using 24 bits per Pixel, four LVDS lanes (default: 18 bits per pixel, three LVDS lanes)

    lvdsjeida: LVDS data is using JEIDA mode (Default: SPWG) (only relevant in 24-bit mode)


    1. setenv dispflags lvds24,lvdsjeida

    Supply a boot image

    When you have defined your display as shown above (don't forget to use saveenv), then you'll see an F&S logo and the U-Boot version on the display on the next start. However this logo is *not* intended to be replaced with your logo. You can define your own (and even larger) logo (or other start image) in a completely independent way. This image can even fill the whole screen. There are gain two environment variables for this.

    splashimage: Address where the image to show is located in RAM

    splashprepare: Commands to be executed to get the image to RAM

    For now, the image must use the BMP format. First you have to think about where to store the image, so that it is available at the next start. For example use an own MTD partition in NAND. By setting the splashprepare variable, you load the image from this source to RAM and by setting the splashimage variable, you tell U-Boot that it should show a boot screen and where the image is located in RAM.


    We have a small MTD partition UserDef that is exactly meant for things like that. So if you use a BMP image with 8 Bit/Pixel and you have a display resolution of 800x480, then the image will fit in this UserDef partition. The following commands will store the image there and prepares the board to show this image at every start.

    1. tftp startscreen.bmp
    2. nand erase.part UserDef
    3. nand write $loadaddr UserDef $filesize
    4. setenv splashprepare nand read $loadaddr UserDef $filesize
    5. setenv splashimage $loadaddr
    6. saveenv

    The first command loads the image via TFTP. Then the second and third commands store the image in the UserDef partition. The fourth command stores a nand read sequence in the splashprepare variable that will load the image from the UserDef partition to $loadaddr in RAM. The fifth command sets the splashimage variable that tells U-Boot that there is an image at $loadaddr in RAM that should be displayed.

    As I said, this is only the beginning with display support in U-Boot. We have plans for quite some more stuff, for example that several displays can be activated at t eh same time and that also texts and graphic primitives can be shown. In addition the transition from U-Boot to Linux should be made seamless. At the moment, the boot screen vanishes when Linux starts.

    Our release is from April 2020. So this is not too old. You can not compare a manufacturer specific kernel with the latest mainline kernel.

    At the moment we are busy doing all the releases for our i.MX8 boards. These releases are based on kernel 5.4.70. If this is done, we want to update the i.MX6 boards to this version, too. However there are no specific release dates planned yet. The i.MX8 releases require lots of changes to have everything work as similar as possible to our other releases, so it is difficult to estimate when this is all done.

    Your F&S Support Team

    As I already assumed, 65MB of memory are used by the buffer cache and 62MB of it are still available as free memory. So I would say the system was not out of memory when this happened. At least not out of regular memory. There are other cases where memory may still have been short. For example there is the CMA region (Continuous Memory Allocator). Normal memory is allocated using the paging mechanism. So an arbitrary page in memory can be used and it is given a virtual address so that it can be part of a larger continuous memory region allocated by malloc() for example. But it is only continuous in the virtual address space. On the physical address space, it can be arbitrarily fragmented. Theoretically each page can be located somewhere else in physical memory and still the virtual addresses show one continuous region.

    The CMA region is different. Here also the physical address region has to be continuous. This is needed when the region is accessed by DMA, where the DMA only sees the physical addresses. So for example a (frame) buffer that can be shown on the display needs to be a continuous memory region in the physical address space, too, so that the display controller can send the data to the display via DMA. If the CMA region is exhausted or very fragmented, maybe the display driver can not allocate any large enough buffers anymore and will get into such a non-standard state. But this is just a guess.

    Maybe the CMA debugfs can be useful to prove or disprove this.…guide/mm/cma_debugfs.html

    If allocating (and freeing) a large block via debugfs works with a newly started system, but fails to work on a system that is running for many hours, than this could be an indication for the CMA running out of continuous memory.

    If this is actually the case, it may be your application or Qt that may be responsible. Probably there is a memory leak, some buffer that is allocated from time to time but never freed, causing the CMA pool to get more and more fragmented, so that at some point of time it is not possible anymore to allocate a rather large continuous memory block required for the display driver.

    Your F&S Support Team

    When you go to our web site, then to Products -> armStone -> armStoneMX8M, then you'll find a table. There you have a tab called "Documents" with all the documentation to this board. For example the "armStoneMX8M Hardware Documentation" will show you all connectors and voltages.

    Your F&S Support Team

    Unfortunately we can not decode this error message, too. The display driver including the GPU part is only partly available in source code in the Linux kernel, a big part of it is closed source and only available as binary libraries in the root filesystem.

    But the hint about the free memory sounds interesting. Do you still have the output of the free command from this case? Is it really only 4 MB of free RAM? Sometimes the output is misleading, as most free memory is used for the buffer cache to speed up file accesses. But such cache can be counted as free memory. When memory is needed, the least recently used pages from the buffer cache are simply thrown away and can be used for the new memory request.

    Your F&S Support Team

    When doing a software update in the field, often the whole root filesystem is replaced. However then also some board-specific settings like configuration files, calibration data, log files and so on are also lost. If you plan this correctly beforehand, then you can store this information in an own UBI volume that is not overwritten by the update. But sometimes such problems are only recognized when the update should be done and then it is too late and these files are already in the root filesystem.

    This article shows how you can save a couple of such files in the UserDef partition in NAND and restore them in Linux in the new environment. The UserDef partition is a small MTD partition that is available on most F&S boards by default. It is rather small (e.g. only 768KiB on our i.MX6 boards), but is often big enough to save the necessary data. Please note that on boards with Cortex-M CPU, this region may already be occupied by the Cortex-M program.

    The solution consists of two parts. One part is a script for U-Boot. It is meant to be integrated into your own update script. This part reads the files to be saved from the root filesystem (in the rootfs UBI volume on top of TargetFS) and concatenates them together to build one long data region. This is similar to what tar is doing. The resulting data region is then saved in the UserDef MTD partition. Then the regular update procedure can follow that installs the new root filesystem.

    The second part is a script that is run when the newly updated Linux system is started for the first time. It is located in /etc/init.d and simply loads the contents of the UserDef partition and stores the content under the original file names. Then it renames itself so that it is not run again on subsequent starts.


    - Board with NAND storage

    - Board with free UserDef (or other) partition

    - Root filesystem in ubifs

    - Root filesystem mounted read/write

    - Root filesystem using /etc/init.d for startup-scripts


    1. Add the code of saveconfig.txt to your own update script before the old root filesystem is overwritten. Replace "/root" in the assignment to variable path with the path to your own directory where the files to save are located. Replace "file1 file2 file3" with the names of the files to be saved. It is OK if not all files exist on a specific board. Those missing files will be skipped. So it is possible to have a single update script that will work in different board environments. Please remember that the sum of all file lengths and all the file names must not exceed the size of the UserDef partition.

      After that code, you can overwrite the rootfs volume as you are used to. Be aware that the rootfs partition is already mounted and the UBI structure is held in RAM. So it is not a good idea to erase the whole TargetFS partition with nand erase.part, because the UBI infrastructure will not see this and will still write the new data using the old pointers and structures from RAM. This will most probably result in a corrupted root filesystem. It is not a good idea to erase the whole UBI anyway, because then all erase counters for the wear leveling are lost. So this should be no issue. Just overwrite the rootfs UBI volume with the new image without erasing it first.
    2. In the S01restoreconfig.txt script, replace "/root" in the cd command with the path to the directory where the files should be stored again. You do not need to give any file names, the names are stored in UserDef, too, so the script will recover file names as well.

      Verify that the given /dev/mtdblock has the correct number for the UserDef partition. This may vary from board to board. You can see this in the boot messages, where Linux shows a list of all MTD partitions. The partition numbers are counted starting at zero, so if UserDef is shown in the second row, then it is mtdblock1.

      Store the script as /etc/init.d/S01restoreconfig in your new root filesystem that is installed with your update. The script will be executed when the system is started for the first time. Then the script will rename itself so that it is not called again on further boot processes. If you want to change this name, please remember to also update the line at the end of the script that does the renaming.

    Your F&S Support Team

    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