DCUTerm Windows 10 Support

NetDCUUSBLoader and DCUTermi are both working with Windows10.

Does the "Connected at high-speed" message appear to indicate the USB connection?

Does the "Waiting for EBoot, U-Boot, NBoot, M4 Image..." message appear after pressing 'd'` for serial download?

You can also use the free terminal program Teraterm under windows. It has a menu entry "Send file..." and there is a checkmark "binary" to activate binary transfer.

In Linux you can use programs like picocom or minicom. Use the terminal program to start the download with 'd', then use a second shell and then copy the uboot.nb0 file to the serial device /dev/ttyS<x>. You should still see the dots in the terminal program.

If you just want to replace an existing U-Boot, you can also do this from U-Boot itself. Just download the file, e.g. by tftp and save it to the UBoot MTD partition:

Your F&S Support Team

For a bitwise copy in linux use the 'dd' tool.
If you have established serial connection e.g. with one of the applications mentioned above and pressed 'd' for download simply one command is needed to get the stuff done.
For example let's get a file uboot.nb0 that's located in your home folder to your board and let's assume your terminal is on /dev/ttyS1 type:

Now you should see the download progress.

Best Regards
Your F&S Support Team

Please select action
'd' -> Serial download of bootloader
'u' -> USB download Eboot/UBoot
'E' -> Erase flash
'B' -> Show bad blocks
Use NetDCUUsbLoader for USB download
USB download ..
ERR: UNKNOWN SETUP Packet Type
Setup Info: 0 , 0<<< ---- ERR: UNKNOWN SETUP Packet Type
Setup Info: 0 , 0<<< ---- ERR: UNKNOWN SETUP Packet Type
Setup Info: 0 , 0<<< ---- ERR: UNKNOWN SETUP Packet Type
Setup Info: 0 , 0<<< ----

I also moved to Windows 10 recently, i disabled from UEFI the digital signature checking for drivers.
The driver present with the NetDCU loader is not working when USB download is activated from Tera Term.
If i try to make Windows decide for the proper driver, no driver is found and remain a unrecognized device.

If i force the driver on the device, the diagnostic on windows driver property is as following, (translated in english)

"Unable to load the device (Code 10).
USB Address request set failed"

So i tried to use the serial boot (that for me never worked also before), if i send the .nb0 using teraterm (problems also with dcuterm), it starts going crazy, showing the same "Please select action" header during program time.
Below some log (everytime is different), but serial connection is fine.
Do you have some reliable guide to permit Windows 10 users to properly load u-boot? Also because we are all changing computer and older Windows are no more available.
Check below some crazy report also from serial loading:

Please select action
'd' -> Serial download of bootloader
'u' -> USB download Eboot/UBoot
'E' -> Erase flash
'B' -> Show bad blocks
Use NetDCUUsbLoader for USB download
start to download ...
#####################################################################################################file len=104122
'f' -> Save image to flash

Please select action
'd' -> Serial download of bootloader
'u' -> USB download Eboot/UBoot
'E' -> Erase flash
'B' -> Show bad blocks
Use NetDCUUsbLoader for USB download
There is no data for download into Nandflash

Please select action
'd' -> Serial download of bootloader
'u' -> USB download Eboot/UBoot
'E' -> Erase flash
'B' -> Show bad blocks
Use NetDCUUsbLoader for USB download
................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................Done

Please select action
'd' -> Serial download of bootloader
'u' -> USB download Eboot/UBoot
'E' -> Erase flash
'B' -> Show bad blocks
Use NetDCUUsbLoader for USB download
start to download ...
#####################################################################file len=70990
'f' -> Save image to flash

This seems to be a very old nboot version prior to V21. You have to update to a current nboot (V32 is current).
Please give the full serial output so I can see which nboot you are using.
Then I can give you some instructions for the update process.

Never went to nano boot menu, at the time we started using your boards, F&S replied that we should not change it, so we just put the uboot but nboot given by you is unchanged.
Also uboot and operative system was customized by us at that time, so it is difficult for us to move to new uboot / operative system.
Is it possible to load a new nboot without changing behaviour of old uboot/os?

Installing a new nboot should not affect U-Boot and OS.
From the messages I can see that the nboot is around 3 years old.
You have to change the nboot in order to get decent functionality.
Please give the version of the installed nboot so I can give you the instructions for updating the nboot.

I cannot at the moment, as that board was in a customer factory and now i am back in office.
Our problem is: we have hundreds of these boards around the world and various technicians are making assistance to that with not much computer expertise or equipment.
So for us is just a mess to do that, we cannot change firmware every 3 months...we have boards with different firmware, and as you declared some of them does not have "Decent functionality" in case we will need to reprogram on field.

VERY IMPORTANT!

If you use software based on one of the releases of the V1.x series, then do *not* update NBoot (because there is no simple way to downgrade again). For fsimx6-V1.x, you need an NBoot from before VN20, the best is VN17. Only if you use software from release fsimx6-V2.0 or newer, you must use a newer NBoot, at the moment VN29 or newer is recommended. This was all explained in the release notes to fsimx6-V2.0.

Nonetheless keep in mind that the NAND code of fsimx6-V1.x is much less reliable than on newer versions and we do not take any responsibility for lost data if you still use this old version. We have newer versions with more stability available, so it is your responsibility to update your devices accordingly.

When you are using the old NBoot, please keep in mind that lower case 'd' and upper case 'D' have different meaning. Lower case 'd' is for downloading the main bootloader U-Boot and it expects a large file (512KB), upper case 'D' is for downloading a new NBoot and it expects a small file (64KB). You can see different characters while downloading, one is with '.......', one is with '######'. You have both variants above, which shows that you do not consequently use the right character.

The correct sequence to update U-Boot is: press lower case 'd', start "Transfer binary file" in DCUTerm/Teraterm, wait for download to complete, press 'f' to save. The garbage appears if you forget to press 'd' before selecting the file to download.

Your F&S Support Team

I kindly ask again: there is a simple way to upgrade firmware with USB with Windows 10? We are in 2017 and as working with multiple cards around the world we cannot give that kind of assistance and it is not our fault if you previously supplied bugged code or now making different uncompatible software versions that are not easy to upgrade.
I think we are not asking much, but as this is the situation we will look after for another board productor that will give a more professional and reliable upgrade system.

Let me explain again.

In the past we had several releases for i.MX6 (usually called fsimx6):

• V0.1 and V0.2 for QBlissA9 only (the V0.x series). This was 2012.
• V1.0, V1.1, V1.2 (the V1.x series). This was 2013.
• V2.0, V2.1 (the V2.x series). This was 2015.
• V3.0. This was 2016. In the next few days there will be a new V3.1. (The 3.x series).

Between V1.1 and V2.0, we totally re-implemented the NAND flash access that made everything much more stable and reliable than before. This unfortunately also required a different NBoot. Such version steps that require a specific NBoot are very rare, actually this was the only case in the whole history of i.MX releases. The important thing is that you do not mix up versions from before and after. But it's still rather simple:

• If you have software based on release V0.x or V1.x: use NBoot < VN20
• If you have software based on release V2.x or V3.x: use NBoot >= VN20

I do not know what software you use in the field. So if you use software in the field that is based on a release before V2.0, then you also need the old NBoot. The output that you showed in the posting above, where there is the 'u' command available, *is* an old board with an old NBoot. We do not ship boards with this old NBoot anymore for quite some years now. So if you have these boards out in the field, our advise is *not* to update NBoot, because it is rather difficult to downgrade NBoot again once you are on a version >= VN20. Actually if you do use this old version on a regular basis, then you are most probably aware of this fact because we do ship our boards with a newer NBoot and you have to downgrade NBoot every time.

On the other hand if you just have an old board and want to install newer software (based on releases V2.0 or later), then you must upgrade NBoot first. Download NBoot VN17, because this was the last old NBoot release and it is a kind of "link" between old and new NBoot versions. It is basically an old NBoot, but already knows the format of the newer NBoot images and can install them. So update the board to this NBoot VN17. When this is on your board, you can update to every NBoot version >VN20. The newest version at the time of writing is VN35 (which may not be on the server yet), but VN29 or VN32 is OK, too.

Regarding update via USB cable. Actually NBoot and UBoot can be updated via USB connection. You need the NetDCUUSBLoader tool on the PC side. Select the file that you want to download. Then go to the board and start NBoot. Now simply start the download in NetDCUUSBLoader. (Well, in the old NBoot, you have to press 'u' first, this is not necessary in the current NBoot versions anymore). However the main Linux images (kernel, device tree, rootfs) must be installed in U-Boot. And U-Boot does not support a direct USB cable connection. In U-Boot, you can download files via Network (TFTP, NFS) or from an SD card or USB drive.

In the meantime we have also implemented an Update and Install mechanism in U-Boot where installation can take place automatically. So the environment has improved quite a lot since 2012. But if you have an old board or use old software, then you also have to deal with the limited options that were possible in these old versions. If you use newer versions, you also have more comfort.

Your F&S Support Team

Unfortunately your answer is useless and there is no solution for us...

Problem 1) Some of our technicians only have Windows 10, and some versions of nboot on some cards does not permit to load uboot with serial...
Problem 2) U-boot changed from version to version, there is a way to read and write parameters of different u-boot versions with mtd utils? I think not...
MAIN Problem) We are not asking about newer versions with many options or older versions with less options...we just need a "decent" way to load firmware on boards on different periods...on many systems is very easy. But now for older boards is a real mess because we have no way to update on field in a reasonable way.

This is a real shame, as even in 1982 was possible to load BIOS (equivalent of UBOOT) with a floppy disk on most motherboards, today in 2017 we are unable to let an our technician upgrade a firmware on site and we will need to send back cards in factory to do that.

Quote from leitmotiv

Problem 1) Some of our technicians only have Windows 10, and some versions of nboot on some cards does not permit to load uboot with serial...

That's simply not true. Serial download of U-Boot is possible on *every* NBoot version that we ever released. You just need to press 'd' (lower case). In previous versions it was a difference if you press 'd' (lower case) or 'D' (upper case). Lower case was for U-Boot, upper case for NBoot. On newer NBoot versions, they both are the same, so you can press either 'd' or 'D' for either download. But if you want to stay compatible with older versions, you must use lower case 'd' for U-Boot download. Judging from the log files in earlier posts, you mixed upper and lower case. And then you must not be surprised if it works sometimes (if you used the right key) and sometimes not (if you used the wrong key).

Quote

Problem 2) U-boot changed from version to version, there is a way to read and write parameters of different u-boot versions with mtd utils?

I'm not sure what you mean. Do you mean mtd utils from Linux? Why should you need to write U-Boot settings from Linux? And yes, you can use such tools, but simply not across the NAND version change. So you can use Linux from before fsimx6-V2.0 to write to U-Boot from before fsimx6-V2.0 and you can use Linux from after fsimx6-V2.0 to write to U-Boot from after fsimx6-V2.0.

Again: we changed the NAND flash layout, i.e. the order of data within the NAND pages in this update back then. So it is important that each component of the software chain uses the same layout or it will not understand what some other software component has written. So for example Linux and U-Boot must use the same layout, because U-Boot writes the root filesystem and Linux reads the root filesystem. If U-Boot would use a different layout, Linux could not read what U-Boot has written. The same is true for NBoot. If you write a new U-Boot image from U-Boot, NBoot must understand what U-Boot has written or it can not load the U-Boot image at the next boot. So it is necessary to use a software chain from bottom to top that uses the same NAND method. Otherwise it will not work. This is why writing something from a new Linux to an old U-Boot will not work, old U-Boot will simply not understand what new Linux has written.

Of course this makes updating from an older version to a newer version more difficult. To stay in the vision of your BIOS example, if you have a computer with an old legacy BIOS and all other computers use a new UEFI BIOS, then you also have some difficulties to update the old computer from legacy to UEFI. And of course updates have to look different for these two types of computers. But that's how it is and you can not change it afterwards.

Quote

MAIN Problem) We are not asking about newer versions with many options or older versions with less options...we just need a "decent" way to load firmware on boards on different periods...on many systems is very easy. But now for older boards is a real mess because we have no way to update on field in a reasonable way.

What do you want to hear? Yes, updating on older boards was more difficult than it is on newer boards now. This is why we do newer versions, to make things easier and to improve the working environment. But if things do work on newer versions, then you can not blame us for the fact that they were not working on the older version. That's the nature of things. If you have an old Windows 95 and also newer Windows versions in the field, and you have a perfect update procedure with USB3.0, then you can not blame Win 95 that you can not use your convenient USB3.0 update method there. Win 95 can not use USB3.0. So you need a different update method there and yes, this may be less comfortable.

Quote

This is a real shame, as even in 1982 was possible to load BIOS (equivalent of UBOOT) with a floppy disk on most motherboards, today in 2017 we are unable to let an our technician upgrade a firmware on site and we will need to send back cards in factory to do that.

No this is also not true. You could not just put a BIOS image on a floppy disk, you also needed DOS to run an operating system and an update tool. And the update tool was the part that allowed to do that. BIOS was *not* capable of updating itself. It needed software to do this. And there is software to update our old systems, too. It was just not as comfortable as it is now. So you have to live with the features that were available back then. Like in the BIOS example. You also can not use a media from 2017, like a USB stick, and go to the 1982 computer and update the BIOS there. The DOS will not be capable of accessing a USB stick. It will not work. But that's more or less what you are demanding right now. You want to use features of 2017 to update a system that is older and does not support these features.

If you have a technician going to the systems in the field anyway, why not give him a new board with new software, let him exchange the whole board and then later you can upgrade the old board without any difficulties back in your office. Then you can use this upgraded board as a replacement for the next system. Or write some script on the PC that sends all commands that are needed to replace everything. Then when you go to the system in the field, use a notebook with all the required images and this script on it, connect it to the serial line and run the script. Then the script will do all the update steps completely automatically. Once you have updated all boards with software based on releases before fsimx6-V2.0, you will have less trouble in the future because you can use the same method on all systems.

Yes, that is a little bit inconvenient, but I can not change the functionality of the old boards in the field anymore. They are as they are.

Here is a list of steps to update old NBoot to new NBoot:

• Note the MAC address (environment variable ethaddr in U-Boot)
• Restart board and go to NBoot
• Download nbootIMXQ_17.bin or nbootIMXSDL_17.bin, depending on the CPU type of your board (Quad or Solo/DualLite). You can do this by serial download with 'd' or via USB (with NetDCUUSBLoader) with 'u'. Save it.
• Restart board and go again to NBoot; press 'E' to erase flash
• Download nbootimx6_32.bin (there is only one version for all CPU types now) with 'd' or 'u', save it
• Restart board and go again to NBoot; press 'U' to erase flash and unmark all bad blocks
• Now install your new software as you would do on a new board (first U-Boot, then start U-Boot and install Linux images)
• When setting U-Boot environment, also set ethaddr again and use the MAC address noted in the first step

Your F&S Support Team

1) We use mtd-utils together with the tools called fw_printenv (and fw_setenv), to set uboot parameters from userspace. This is needed because on same terminal we use different displays (lvds 7", 12", 15") so it can be configured at any moment, like other parameters
2) We cannot give to our technicians another board, because the technician is in another country and sometime is very expensive and takes very long to ship boards (we must act in the fastest way sometimes)
3) You are comparing differences between differences architectures and systems (BIOS and UEFI) here we have a problem with the same board and microprocessor.

Now I try to explain the differences between the previous embedded systems compared to this one:
Remote past: Yes bios does not update itself, but was just needed a floppy disk (Bootable) with a .exe file (supplied from manufacturer) with the .bin image that would load on BIOS. Also, it was possible to change parameters from screen directly, without any firmware change.
Near past: In latest systems, USB-HDD option was available, so technician just had to insert a pendrive (yes, that was a bootable system made by me) restart the computer and automatic install procedure would run.

Please understand that the difference is that not much equipment was needed, and even a mechanical technician could perform that.
With this board i don't have a way to correct the situation in the same way, a serial port converter is needed and a usb cable with a tty utility. That could be possible, but it is impossible us to make do these kind of operations to our technicians because are too much complex.
But i don't expect anything from this tech support, it is just a complain and a suggestion at the same time, for me is still crazy that i need a tty terminal with a computer to change a boot parameter or update uboot, expecially by having a display. on the board..
When i will have time i will try to make a customized uboot version with display support, at least to change some parameter directly from the display or worst case HDMI screen.

Times ago i tried Advantech boards and they have at least that, i will try to make customization from newer uboot myself.
Anyway, i thank you for the kind reply.

Best Regards

Quote from leitmotiv

1) We use mtd-utils together with the tools called fw_printenv (and fw_setenv), to set uboot parameters from userspace. This is needed because on same terminal we use different displays (lvds 7", 12", 15") so it can be configured at any moment, like other parameters

OK. So where is the problem? You can use these tools.

Quote

2) We cannot give to our technicians another board, because the technician is in another country and sometime is very expensive and takes very long to ship boards (we must act in the fastest way sometimes)

OK, I understand the situation. So having a working update system is important for you. So the question is, why do you find all these update issues just today? Not three years ago before these systems went into the field? Why did you not make sure back then, that these systems have a working update infrastructure?

Quote

3) You are comparing differences between differences architectures and systems (BIOS and UEFI) here we have a problem with the same board and microprocessor.

It was a visual image for an example where a PC gets a major update on the BIOS level. Usually updates on BIOS level are quite compatible, so as our usual NBoot updates are also quite compatible. But an update from a legacy BIOS to a UEFI Bios would not be, so this was the example I wanted to give, that if there would be incompatible updates in BIOS because of significant improvements, you would have problems there, too.

Quote

for me is still crazy that i need a tty terminal with a computer to change a boot parameter or update uboot, expecially by having a display. on the board..

But this is exactly the point. Not all customers use a display. Many of our customers have so-called headless systems without any display at all. But our update and configuration system must work for them, too. So the lowest common denominator is the serial line. This is supported by all our customers. When we ship the boards, we often simply do not know for what purposes these boards will be used. We don't know whether they use a display or not, and if they use a display, we do not know the size and resolution. So we have to restrict ourselves to very minimal solutions like a serial port. If any more convenient update solutions are required, this has to be implemented by the customer.

You say that you needed only very little equipment to update BIOS. Well, a full operating system, a diskette or pen-drive, a keyboard and a screen is looking as quite a lot of equipment to me. You happen to have some of this equipment already available by your device. But imagine some PC-like device that is controlling a traffic light in a cabinet next to the street near the street crossing, there is also no screen and no keyboard and the service technician has to bring all this along. So the difference is not very big compared to a notebook that you have to bring along and connect to a serial port.

Quote

When i will have time i will try to make a customized uboot version with display support, at least to change some parameter directly from the display or worst case HDMI screen.

Yes, and when you do this, you will most probably do this exactly for your situation. And maybe this will work. But when you think of the possibility, that some people only have a 3 inch display with a very small resolution, do you also get this to work on such displays? Or you will implement this for LVDS, because you use LVDS. But will this also work for RGB-LCD and HDMI? And also for the second LVDS channel? And how do you perform your settings and updates on boards without a display? It is very easy to implement something if you have very well-known conditions. But if you have to do this for a completely open system where you can not make any assumptions about the available devices, it is quite a lot more difficult.

You seem to come from a PC-like environment where you always have a screen. But this is not the case here. We have customers in many many other situations where a PC-like system is not and never was an option. And we have to take care for them, too.

Your FS& Support Team

1) i can't use mtd-utils and fw_printenv/setenv anymore because now uboot flash structure is changed, was base on previous uboot version you given
2) because you changed 2 or 3 times the uboot versions, if everything remained with same and old uboot version it would be not needed

Quote

You say that you needed only very little equipment to update BIOS. Well, a full operating system, a diskette or pen-drive, a keyboard and a screen is looking as quite a lot of equipment to me. You happen to have some of this equipment already available by your device. But imagine some PC-like device that is controlling a traffic light in a cabinet next to the street near the street crossing, there is also no screen and no keyboard and the service technician has to bring all this along. So the difference is not very big compared to a notebook that you have to bring along and connect to a serial port.

On all our terminals are given with a display and a touch screen, as all normal PLC panels or Scada HMI with USB port. But not all technicians having intervention have a computer, and in this case with the proper software normally would be needed just a pendrive. So no, it is not easier to use TTY

Ps: we are not coming from a PC-like environment with a screen, but we are using these board because have lvds support and these kind of boards are made for screen and multimedia.
Normally all the firmware not related to a display we made internally with M4 microprocessor in C or a Infineon in Assembler, but this is not the point.

By ending, just to explain our point: We have all these issues because sometimes when you supply boards the uboot version changes, all our firmware was made for the first uboot version.

Quote from leitmotiv

1) i can't use mtd-utils and fw_printenv/setenv anymore because now uboot flash structure is changed, was base on previous uboot version you given

No, we have not changed Uboot flash structure, we have changed flash structure for *all* parts of the software. Is this so difficult to understand? The original NXP/Freescale code was very incomplete and unreliable. As long as there are no bit errors in the flash, everything seems to be OK. But we have NAND flash, and NAND flash is supposed to have bit flips. This is totally OK with NAND flash, but it requires appropriate ECC handling to correct these bit errors. And exactly this ECC code was insufficient in the original code. So even very small bit errors would lead to real read errors, i.e. data corruption.

So we decided to improve the situation. Which means we increased the ECC correction so that it can detect and correct at least 16 bit errors, or even more, depending on the specific flash type used. And we added block refresh to U-Boot and NBoot.

But when using a different ECC, this automatically results in a different layout of the page data. And as I explained before, it is necessary that all software components use the same layout or they will not understand what the other component has written. This is exactly what you are trying to do. You want to use Linux to read and modify the U-Boot environment that was written by U-Boot. This means U-Boot and Linux have to use the same layout or it will not work. Or in other words, when you use versions with different layout, i.e. U-Boot from after V2.0 and Linux from before V2.0, this will not work because Linux will not understand what U-Boot has written and vice versa.

So the only thing that makes sense is to use *all* software components from before fsimx-V2.0 or *all* components from after fsimx6-V2.0. Mixing is not possible, or at least it does not make sense.

Quote

2) because you changed 2 or 3 times the uboot versions, if everything remained with same and old uboot version it would be not needed

if everything remained with same old U-Boot, you would still have the same unreliable NAND algorithm. By using the new version you profit from the significantly more reliable data. And you would still not have a working update infrastructure. Software improves and you have to live with that and you also want that. Of course we try to stay as compatible as possible, but regarding the NAND flash data, it was simply not possible to stay compatible. So what should we have done instead? Keep the old code forever to stay compatible?

Nowadays, software is a rather dynamic thing. You have security issues, new hardware that you were not aware of when you started the software, new regulations from the government, and many many other reasons why you need to change software. So you also should design your own software in a way that can keep up with these changes. The times where you designed code once and then used it for the next 20 years are over.

Quote

On all our terminals are given with a display and a touch screen, as all normal PLC panels or Scada HMI with USB port. But not all technicians having intervention have a computer, and in this case with the proper software normally would be needed just a pendrive. So no, it is not easier to use TTY

Yes, in your specific application. But we have also other applications. And we have to present a way to provide an update to *all* our customers. If this is not sufficient for your case, then you have to improve this update procedure to your own needs. But this is not our task anymore.

Quote

Ps: we are not coming from a PC-like environment with a screen, but we are using these board because have lvds support and these kind of boards are made for screen and multimedia.

Of course, these boards are definitely suited for display oriented devices. But put yourself in our place. You can connect any display from lets say 2 inches to 20 inches or even more. Having resolutions from 272x64 up to Full-HD. You have four different display ports: LCD, LVDS0, LVDS1, HDMI. Which means you can connect up to four displays to it. On which port would you put the U-Boot output? LVDS? Then someone who only has a display on LCD would not see anything. LCD? Then someone with a display on LVDS or HDMI would not see anything. And for which resolution would you configure the output? Full-HD? Then someone with 640x480 would not see anything. 640x480? Then someone with FullHD-Display would not see anything.

How would you solve this? And this doesn't even start to think about those people who do not have any display at all.

Using a serial line is working for all people. Yes, this may be a little less comfortable for those who actually have a display than it could theoretically be, but it works. If this is not enough, then you have to add a better one. This can also be suited for your specific situation, something that we can not do, because we do not know your hardware.

Quote

By ending, just to explain our point: We have all these issues because sometimes when you supply boards the uboot version changes, all our firmware was made for the first uboot version.

Probably let me also explain how this works here. On one side we have standard boards. These boards are always shipped with the newest software. That are either Starter Kits with a fully installed Linux system for people who start a new project. Here it would not make sense to start with an old version. Or the boards are for the series, then we only install NBoot and U-Boot, but also the newest version. If you need some specific version, you have to install it yourself, i.e. downgrade the board.

On the other side we have customer specific boards. Here the customer decides what software should be put on the board, and we can even talk about a specific hardware configuration (soldering special connectors, having more or less memory, etc). When everything is decided, we will produce one sample, provide it to the customer and the customer checks if everything is correct. Then he signs a production release document. From now on he will always get the boards in the same hardware and software configuration until he decides to change it. Then the whole cycle with defining the software, sending a sample, signing the production release document, starts again. Of course these customer specific versions are slightly more expensive and each renewal of the software costs a small fee for the work involved with running the cycle again. But basically this is what you need. A board that is always shipped with the same software version.

Remark: Customer specific versions are only possible with a minimum quantity of boards, usually 300 or more per year, depending slightly on the board type. With lower quantities, the whole procedure is getting too expensive and it is easier for the customer to install some specific software version himself.

Your F&S Support Team

Ok from this replies i assume you don't understand what i am saying or giving just political reply, don't worry anymore about this.
PS: We cannot use newer distro or yocto as we made porting for dosbox, mysql, and other functions for the board.

If you could help me about this matter at least:

With your distro fsimx6 2.1, is fw_printenv fw_setenv working together with uboot or is not compatible? In older versions everything was working but with fsimx6 from 2.0, i think there is an incompatiblity on the BBT handling of nand flash between uboot and kernel, do you have some information/experience about that?

Best Regards