Posts by fs-support_HK

    The IP address can be saved in an U-Boot environment variable. If you set ipaddr in U-Boot, then you can pass this to the Linux command line so that it is correctly set from the beginning if you do not call DHCP functions. So you can use the same image for all boards and just have to set this variable differently.


    Your F&S Support Team

    Just to make sure, you actually measure the voltage on the pin, you do not simply read back the value by software? Because in your configuration, you will *not* see the real pin value when reading the value-file in sysfs. To be possible to do this, you have to add 0x40000000 to your hex value, i.e. 0x400030b0. This enables the so-called SION flag which loops back the general purpose output signal to the general purpose input signal. Then you will also see your own output value as input value. By default this is not the case on any i.MX6 CPU.


    Also be careful if you actually have the sound Codec still included in your circuit. The default function of this pin is I2S_SYNC. We configure the sound Codec chip to be the clock master, So this signal is an output on the external Codec and an input on the CPU. If the Codec is not properly reset by a power cycle, then the Codec might still drive this line actively. A warm start like calling reboot might not be enough to bring back the Codec to a passive state. So make sure that the line is not driven by some other device.



    Your F&S Support Team

    Can't you simply create different build directories with different setups? The fact that you have many layers included in your source tree does not automatically mean that you need to include these packages in your configuration.


    Or how about this approach: Configure Yocto to build the sum of all packages that you need on any of your targets. Then create recipes for separate rootfs images, one for each of your targets. Each rootfs image only pulls in those (binary) packages of the generic build that are needed on this specific target.


    I think this approach has the advantage that most basic packages are actually exactly the same on all targets, reducing the support requirements. For example if one of the packages needs a security fix, you change it once in the source tree and then you can update all targets with one simple rebuild. This will update all rootfs images in one go. Or when moving to newer package versions (e.g. a newer Yocto), you also get an update for all of your platforms in one go.


    I only see problems with this approach if the configuration requirements for two targets actually contradict each other. For example if two targets need gstreamer, but one target must support media format X and the other is not allowed to show even the slightest sign of format X. But even then it might be easier to build two different versions of this single package instead of building completely different setup environments.


    Your F&S Support Team

    Vybrid Linux Releases V2.2.1 and V2.1.1


    We have uploaded two new Linux versions for all boards and modules based on the Vybrid CPU to our server, i.e. the fsvybrid architecture: armStoneA5, PicoCOMA5 and NetDCUA5. These releases are running on all platforms of this architecture at the same time. So you can download the same binaries for NBoot, U-Boot, Linux kernel and Buildroot root filesystem to any of the Vybrid boards and it will run.


    Each release consists of two files:


    fsvybrid-V2.2.1.tar.bz2 (or fsvybrid-V2.1.1.tar.bz2)

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


    sdcard-fsvybrid-V2.2.1.tar.bz2 (or sdcard-fsvybrid-V2.1.1.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 fsvybrid-V2.2.1.tar.bz2

    This will create a directory fsvybrid-V2.2.1 that contains all the files of the release.


    Please read the file doc/Vybrid_FirstSteps_eng.pdf. It lists the meaning of all files and shows how to install and use everything.



    Release Notes


    This is a patch release with minor changes.


    The 4-wire touch controller that was used on armStoneA5, PicoCOMA5 and NetDCUA5 is end of life and is not available anymore. F&S has therefore replaced it with a newer controller. This results in new board revisions that are now called armStoneA5.2, PicoCOMA5.2 and NetDCUA5.2.


    This release adds the new touch driver to the Linux package and modifies the board support code so that the new driver is activated on the new board revisions.


    Please note that you only need to take action if you use the on-board 4-wire touch controller. In that case you just have to replace the Linux kernel (uImage), that's all. Everything else can stay as before. However you most probably need a new set of touch calibration data for the new controller.


    Please note that compared to the previous release fsvybrid-V2.2 (or fsvybrid-V2.1), just the Linux source package, the uImage binary, install-sources.sh and of course the Readme.txt are updated. And we have included a newer NBoot version. All other files remain unchanged. This means that also all the documents are still the original ones. Please visit http://www.fs-net.de to download the newest documents.


    As there were no changes in U-Boot and Buildroot, the new board revisions will still show up as "armStoneA5", "PicoCOMA5" and "NetDCUA5". (without ".2" appended). This makes sure that no existing software will break just because of different names.


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


    The following list shows the most noticable changes in this release in more detail since our last Vybrid release fsvybrid-V2.2 (or fsvybrid-V2.1). Please note that the source code is partly 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. Some of these changes have already been part of other releases for other boards.



    nbootvyb115_15.bin (VN15)


    Supported Boards: PicoCOMA5, armStoneA5, NetDCUA5, CUBEA5, PicoMODA5, PicoMOD1.2


    NBootVybrid - V10 (Released 2014-07-11)


    - 0002342: Change UART debug port for PicoMOD1.2


    NBootVybrid - V11 (Released 2014-09-01)


    - 0002342: Add external clock detection for enet phy's


    NBootVybrid - V12 (Released 2014-12-05)


    - Change to new compiler

    - Reorder structure for less warnings

    - Add support for new F&S MfgTool

    - Add support for some customer specific boards


    NBootVybrid - V13 (Released 2015-08-12)


    - 0002715: Remove non working serial number string descriptor

    - 0002716: Change stack layout

    - 0002717: Add customer specific power LED init

    - 0002718: Enable spread spectrum for all boards

    - 0002719: Change memstest stepsize for better test coverage

    - 0002720: Add customer specific serial number fuse settings

    - 0002721: Add serial number invalidation check

    - 0002722: Change customer specific IOMUX init

    - 0002723: Add customer specific LED functions


    NBootVybrid - V14 (Released 2017-04-03)


    - 0003188: Move printf() to from uart.c separate file

    - 0003189: Longer delay for 'x' and 'r'

    - 0003190: Use nand debug menu from iMX6

    - 0003191: Add USB MSD flash down-/upload for debug purpose

    - 0003192: Initialize g_cCommand to 0

    - 0003193: Change USBD init routines

    - 0003194: Use blx instead of bx for printf call in abort handlers

    - 0003195: Change memtest to check all memory locations

    - 0003196: Remove unused DCACHE code

    - 0003197: Add check for MMU tabele corruption in USBD DMAdescriptor setup


    NBootVybrid - V15 (Released 2019-07-26)


    - 0003995: Add password protection option

    - 0003996: Add ECC check after startup

    - 0003997: Improve bootdevice detection

    - 0003994: Improve DDR initialization sequence



    u-boot


    - No changes



    linux-3.0.15-fsvybrid-V2.1.1 (15.10.2021) (relative to fsvybrid-V2.1)


    Supported Boards: armStoneA5 (incl. armStoneA5.2), PicoCOMA5 (incl. armStoneA5.2), NetDCUA5 (including NetDCUA5.2)


    - Add support for 4-wire-touch controller TSC2004

    - Add support for PicoCOMA5.2, NetDCUA5.2, armStoneA5.2

    - On armStoneA5, fix pendown state on local SX8655 touch



    linux-3.0.15-fsvybrid-V2.2.1 (21.10.2021) (relative to fsvybrid-V2.2)


    Supported Boards: armStoneA5 (incl. armStoneA5.2), PicoCOMA5 (incl. armStoneA5.2), NetDCUA5 (including NetDCUA5.2)


    - Revert uevent helper to /sbin/hotplug on cubea5_defconfig

    - On armStoneA5, fix pendown state on local SX8655 touch

    - Add support for 4-wire-touch controller TSC2004

    - Add support for PicoCOMA5.2, NetDCUA5.2, armStoneA5.2



    buildroot

    - No changes



    Examples


    - No changes



    Toolchain


    - No changes



    Documentation


    - No changes



    Your F&S Support Team

    The basic idea is to go to NBoot, erase everything with 'E', download the Linux bootloader U-Boot and save it to the board. Then start U-Boot and install the remaining Linux images. You can download precompiled images from our website, this is the sdcard tar archive. If you unpack the archive and save the contained files to the top directory of a USB stick or SD card, U-Boot can install them automatically. Finally you have to set the MAC address by saving it to environment variable ethaddr, and if you have two ethernet ports, the next higher address to eth1addr. The MAC address is on the barcode sticker on the module.


    The whole process of installing Linux is explained in detail in the documentation NetDCUA5 Linux First Steps. For working with Linux in general, there is a documentation Linux on F&S Boards. But please note that the Linux on NetDCUA5 (Vybrid) is quite old and some features mentioned in the latter documentation may not be available there. So this is not really representative for a current Linux system on a current F&S board (i.MX6, i.MX8). So maybe evaluation of Linux for a new project should better be done on a more up-to-date board.


    To actually work with Linux, you have to use a Linux PC or at least a Linux virtual machine. We have a document Advices for Linux on PC that tells how the Linux machine can be configured. We also have predefined development VMs for Virtual Box that make this step rather simple. Again you need a rather old machine for the old Linux, so I would take the Fedora 21 machine. Then you have to download the main release tar archive, that is also available on our website next to the sdcard archive. The newest release at the moment is fsvybrid-V2.2, but there will be a version fsvybrid-V2.2.1 soon with some fixes for newer board revisions. This archive contains the Linux source code, documentation, toolchain, examples and also the precompiled images. This is needed to build your own applications and system environment.


    Going from a Windows board to Linux and back to Windows is possible. Just go again to NBoot, erase everything with 'E', download EBoot, save it and then you are back again in the Windows environment. However buying a Linux board and converting it to Windows is not legally possible because Linux boards have no Windows license.


    Your F&S Support Team

    It seems like you have written the image to the wrong sector number. Are you sure that 14000 is the correct number? You can call mc part

    in U-Boot to get the start sector number. Unfortunately the sector number is given in decimal, but you need a hexadecimal value for the mmc write command, so you have to convert the number first. In our example in our documentation LinuxOnFSBoards in chapter 5.11.2 we have a start sector number of 0x14001, not 0x14000. This would explain the failure in your case.


    But you also have to take care that the image size matches the partition size. It is no problem if the partition is bigger than the image that is written there, but the other way round is fatal. So you must not write an image to a partition that is larger than the partition size. Then you have to resize the partition first, either by writing a new MBR, or by using a partitioning tool like fdisk first.


    Your F&S Support Team

    There is a command mtdparts in U-Boot that allows to add and remove MTD partitions. But in fact this command only modifies the environment variable that is also called mtdparts. So you may modify the variable directly, if you want. The list of MTD partitions is automatically added to the device tree after it is loaded to RAM before Linux is started. This is why you don't find any entries in the device tree source, but actually Linux sees appropriate entries after they are added by U-Boot. So you don't have to care about that, it will magically work by itself.


    When changing the MTD partitions, make sure that nothing at the beginning of the NAND is changed up to and including U-Boot and the U-Boot environment. Especially if your intention is to resize the UserDef partition, sorry, this is not possible. The starting block number of U-Boot is hard-coded in NBoot, so if you move anything to a different place, the system will not start anymore. But behind U-Boot, you are free to rename, resize, delete and add partitions as you like. On the other hand if you want to have wear leveling and automatic block refreshs, you should consider adding more volumes to the UBI on top of TargetFS instead of adding new MTD partitions.


    Your F&S Support Team

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


    Code
    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


    git://source.codeaurora.org/external/imx/linux-imx.git


    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: https://kernelnewbies.org/y2038/vfs



    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



    disppanel

    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.


    EDT-ET070080DH6

    ChiMei-G070Y2-L01

    Jinghua-J070WVTC0211


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

    Code
    1. setenv disppanel lcd:EDT-ET070080DH6


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


    dispmode

    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)


    Example:

    Code
    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


    dispflags

    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)


    Example:

    Code
    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.


    Example:


    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.

    Code
    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.


    https://www.kernel.org/doc/htm…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