New Release fsimx6sx-V2.1

After over a year of preparation, it is finally available. We have uploaded a new Linux version for all boards and modules based on the i.MX6-SoloX CPU to our server, i.e. the fsimx6sx architecture: efusA9X and PicoCOMA9X. This release is 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 i.MX6-SoloX boards and it will run.

This is a maintenance release based on Buildroot. The release consists of two files:

fsimx6sx-V2.1.tar.bz2
This is the main release itself containing all sources, the binary images, the documentation, examples and the toolchain.

sdcard-fsimx6sx-V2.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

Source Code

tar xvf fsimx6sx-V2.1.tar.bz2

This will create a directory fsimx6sx-V2.1 that contains all the files of the release.

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

Release Notes for fsimx6sx-V2.1

Here are some highlights of this release.

1. Support for new boards

This is the first regular release that supports PicoCOMA9X. Also the device tree for efusA9X is heavily improved. If you use your own device tree, please make sure that you adjust your tree accordingly.

2. Secure-Boot features

We have done quite a lot to support Secure-Boot. This means the whole boot process from NBoot via U-Boot to Linux can be restricted to binary images that are either signed or signed and encrypted. At the moment, the following images are supported: NBoot, U-Boot, Linux kernel (uImage), device tree, root filesystem (if not mounted read/write).

However as this all requires some effort and instructions, we have not included this in the regular release. You need a special NBoot and also special versions of U-Boot. So if you are interested in Secure-Boot, please contact F&S.

3. Enhanced device drivers

Many device drivers are improved. For example the signal drivestrength for SD cards is now better trimmed and should provide less problems on all boards. Card Detect (CD) and Write Protect (WP) is fixed. eMMC is now supported on all eMMC-capable boards. RTS/CTS on UART had some issues that are solved now. The ethernet speed can now be restricted in the device tree. For example on a Gigabit ethernet port, you can limit the speed to 100 Mbit/s.

The USB bus power is now switched by the controller itself. This pin was configured and used as GPIO in the past, now it uses the dedicated USB controller function. We have left the old code for reference (look for "#if 0 //###"), but we will remove this in the next release if there are no further problems.

The USB OTG port can be used as additional host now on boards where this is supported by the hardware. We have added appropriate CONFIG macros in the device tree in this case. On some boards this even works completely automatically by checking the ID pin on the USB connector.

Add support for the new WLAN chip on board revisions 1.20 and 1.30 of efusA9X. Unfortunately the old and the new WLAN driver can not be active at the same time, so the old WLAN driver needed to be disabled in this release. If you still have an older board revision, please replace the board because only these new revisions will be available in larger quantities for the series.

4. Display & Touch

All default display configurations use 32 bits per pixel now. This is necessary for some OpenGL and Qt5 examples. Backlight handling is improved. We have added a virtual keyboard to the Matchbox window manager in our standard configuration, including a German keyboard layout. xrandr is now also included in the default configuration, this can be used to rotate the X11 screen. We have added support for more CAP-Touch drivers.

By the way, if you use our EDT070080 display, do not be surprised if the screen is now upside down. This was in fact an error in the past and the display was already upside down. So now is the correct orientation. This was caused by a wrong default setting for the rotate pin on the RGB-Adapter (armStoneA9 and efus-SKIT only).

5. Fix freezing problem

There was a problem that the board might freeze when only a few interfaces were active. This was caused by a power saving mode where the bus frequency for RAM is reduced to 24 MHz. Unfortunately not all DDR3 RAMs support this so-called DLL-off mode, which caused problems on these boards. Bus frequency scaling could be disabled via the sysfs at run-time already, but the system always started with bus frequency scaling enabled. We have added a switch to the device tree that allows starting with bus frequency scaling turned off. This is our default setting now.

6. Audio chip default settings

We have added /var/lib/alsa/asound.state, where the default settings for the sound codecs are given. You can modify this file for your own preferred sound settings.

7. U-Boot

SD support is also improved in U-Boot. eMMC is now detected and can be read and written with mmc read and mmc write.

USB OTG devices (usb 0) can also be used as host in U-Boot where appropriate. Simply set the environment variable usb0mode to one of the following modes:

peripheral: Use port fix as device (default)host: Use port fix as hostotg: Check ID pin and depending on this use as host or device

USB devices that are active in U-Boot are shut down now before starting the kernel to save power. Environment variable earlyusbinit is removed. The current USB code detects all USB storage devices realiably and we do not need this kludge anymore.

All ethernet PHYs are set to standby before starting the kernel. This considerably saves power in case that networking is not automatically active in Linux.

U-Boot patches some entries in the device tree automatically according to the board configuration that it finds at run-time. For example the ecc-strength for the NAND flash and some settings for /sys/bdinfo. More of these settings will be added in the future, for example WLAN detection, eMMC detection, etc.

The U-Boot console output can now be redirected via network to a remote host. By default the host given as serverip is used, but you can also give a separate host by setting environment variable ncip. The following commands will redirect input and output to the remote host:

Source Code

setenv stdin nc; setenv stdout nc

On the host side you have to start a tool called netconsole which is available in the tools directory when you build U-Boot.

Source Code

tools/netconsole <ip-addr_of_board>

To redirect input and output back to the board, issue these commands:

Source Code

setenv stdin serial; setenv stdout serial

For further information about this feature see doc/README.NetConsole in the U-Boot sources.

8. Cortex-M4 support

There were also lots of changes for asymmetric multicore processing (AMP) with the Cortex-M4. We have an additional package with FreeRTOS for the Cortex-M4 where all examples are modified to work with F&S boards and modules. This also needs modifications in the Linux device tree which can be activated by defining SUPPORT_M4. This is already available in the device tree, just remove the comment characters in front of the appropriate code line. Then all the devices that are used on Cortex-M4 in the examples are disabled in Linux.

A command bootaux was added to U-Boot to allow starting of Cortex-M4 software. Please note that this command is slightly different and more capable than the original NXP command with the same name.

bootaux start
Start M4 clock to have access to TCM

bootaux run
Start M4 program that is on default address (TCM)

bootaux <addr>
Start M4 program that is on given address <addr>

bootaux pause
Stop M4 clock to pause M4 program

bootaux continue
Continue M4 program after pausing

bootaux stop
Assert reset to M4 core, but keep clock running

bootaux off
Assert reset to M4 core and shut down clock

Example:

Source Code

tftp m4-image.bin

bootaux start

cp $loadaddr 7f8000

bootaux run

A similar environment can be used in Linux to load, start and stopCortex-M4 programs from the running Linux system. This is done via the sysfs in /sys/devices/system/cpu/aux_core/. There are three entries:

bootaux
Command file; you can echo one of the following commands to this file: start, run, pause, continue, stop, off. The behaviour is exactly the same as the corresponding commands in U-Boot. Reading this file returns the current running state of the M4 core.

Example:

Source Code

cd /sys/devices/system/cpu/aux_core/

echo "m4-image.bin" > mem

bootaux run

Please see Documentation/auxiliary_core.txt in the Linux source tree for further information.

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

No, I do not think that your freeze is related to the i.MX6SX issue. On i.MX6 this was triggered when the bus frequency was lowered to 24 MHz, which is only possible with some RAM types and if no device driver requests a high bus frequency anymore. This was introduced by NXP in kernel 4.1, so I do not think that the Vybrid CPU on PicoCOMA5, that is still on an older kernel, has any similar power saving functions.

Usually you try to isolate such a problem by disabling nearly all devices but the serial debug line. This configuration should start successfully. Then you enable one device after the other until it freezes again. Then the problem is most probably caused by the last device that you activated again.

Sometimes also the power supply is not stable enough. Then the board may freeze at the moment when the display is activated. This draws significantly more current and this might result in a voltage drop that causes the freeze.