Posts by fs-support_HK

    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

    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, 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 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


    - 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


    - No changes


    - No changes


    - No changes


    - 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

    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 disppanel 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