L-1012e.Ax phyGATE-Tauri-S i.MX 6UL/ULL Kit Hardware and BSP Manual Head
Notes about this Manual
The information in this manual is valid for all standard variants of the phyGATE Tauri-S industrial gateway from PHYTEC Messtechnik GmbH. An overview of all devices and variants to which the descriptions apply can be found inProduct Information.
For proper installation and safe operation of the device, the operating instructions and in particular the safety instructions contained therein must be carefully read and observed.
The manual uses various symbols to indicate helpful and safety-critical notes. Below you will find an explanation of each symbol's meaning.
This symbol indicates safety-critical information. The warnings must be observed!
This symbol indicates general notes and helpful information in handling the device.
Abbreviations (reserved, will be continued in next version)
Safety Instructions and Liability
The phyGATE Tauri-S gateway is designed for monitoring, processing, and communicating machine and sensor data in industrial environments. For data communication, the devices provide various typical industrial interfaces for connection to surrounding devices.
This PHYTEC standard gateway is supplied exclusively as an OEM device by PHYTEC Messtechnik GmbH and requires an adaptation of the operating software for the intended application by the distributor of the device.
The device must not be used in a manner not specified in this manual to avoid damage of the protection provided by the equipment.
L’appareil ne doit pas être utilisé d'une façon non spécifiée dans ce manuel afin éviter d’endommager la protection fournie par l'équipement.
General Safety Instructions
For commissioning, development work, and assembly, the operating instructions for the device must be used. Knowledge in the following areas is required:
Working in electrostatically protected areas
Accident prevention regulations
On-site valid rules and regulations for occupational safety
These devices may only be commissioned and installed by adequately qualified personnel with basic electrical knowledge! The device must be handled with care in every phase of its life cycle, in order to prevent destruction by electrostatic discharge or mechanical stress, for example.
To ensure functional safety, the device must be powered by a SELV/PELV power supply. The gateway must be mounted on a top-hat rail in a fire save control cabinet for permanent use.
Improper modifications and repairs may impair the integrated protective functions and the electromagnetic behavior of the device. This can cause malfunction of the device, interference with connected and surrounding devices, or personal injury. Therefore, interventions on the device may only be carried out by the manufacturer.
To ensure functional safety, the device must be powered by a SELV/PELV power supply. The gateway must be mounted on a top-hat rail in a fire save control cabinet for permanent use.
Pour garantir la sécurité fonctionnelle, l’appareil doit être alimenté par une alimentation SELV/PELV. Pour une utilisation permanente, la passerelle doit être montée sur un rail profilé chapeau dans une armoire de commande coupe-feu.
The operator of these devices must ensure that there is no danger to persons or property in the event of a defect or malfunction of the device. In case of non-repairable defects and device malfunctions, the devices must be taken out of operation and disposed of properly.
The device must not be disposed of in household waste!
Improper use and connection of these devices, as well as subsequent processing of these devices (e.g. soldering work on the printed circuit board), lead to exclusion of liability on the part of the manufacturer. Please observe the corresponding information in the operating instructions for proper installation.
Product Names and Variants
The phyGATE Tauri-S gateway is available in different variants and expansion stages, which differ in the scope of performance and functions. The following table gives an overview of available variants of the gateway and an explanation for the identification of the article number.
The article numbers have an index ".Ax" where x determines the product revision.
phyGATE Tauri-S Gateway
1x MicroSD Card
1x MicroSD Card
mPCIe slot (USB only) with 2x SMA antenna connector
phyGATE Tauri-S Variants
phyGATE-Tauri Gateway (25 mm housing)
The phyGATE Tauri-S has several interfaces and controls/displays which are shown in the following figure.
Picture of phyGATE Tauri-S with 50mm housing (reserved, will be added in next revision)
phyGATE Tauri-S Interfaces
PB-03513-001.Ax (25mm housing)
PB-03513-002.Ax (50mm housing)
1. Power-LED green
2. User-LED red (freely configurable)
3. User-LED yellow (freely configurable)
4. Button (freely configurable)
5. USB interface (Typ A)
6. Ethernet interface (RJ45)
7. Micro-SD Slot
8. RS232, RS485, CAN interface (configurable)
9. Supply connection
10. Boot-Switch (Concealed, on opposite housing side)
11. Air vents
12. Extension interface under a top-hat rail and top-hat rail clip (35mm)
(13.) SMA antenna connectors
(14.) Internal miniPCIe slot (USB only)
(15.) SIM card socket
phyGATE Tauri-S Interface List
The nameplate of the phyGATE Tauri-S gateway is located on the side of the housing. Here you will find the essential information about your device.
Illustration of phyGATE Tauri-S nameplate (reserved, will be added in next revision)
Modification of the device, such as adjustments to the software or the use of additional devices in conjunction with the phyGATE Tauri-S Gateway, can influence the electrical properties of the device. In this case, the validity of the CE declaration of conformity is void. For a valid CE marking, a renewed approval by the operator must be carried out in this case.
Block diagram may be adapted for next version (reserved)
The phyGATE Tauri-S gateway has various interfaces for connection to the surrounding infrastructure. The following table lists the connections with the matching mating connectors.
phyGATE Tauri-S Mating Connectors
phyGATE Tauri-S Interfaces
Phoenix MC 1,5/ 2-GF-3,81
Phoenix MC 1,5/ 2-STF-3,81
RS232 / RS485 / CAN
Phoenix MC 1,5/10G-3,5
User Input Button
D10 / D11
User-LEDs (red / yellow)
(X41 / X23)
phyGATE Tauri-S Mating Connectors List
Pinout of Non-standard Interfaces
RS232 / RS485 / CAN
Pinout of Non-standard Interfaces
For the phyGATE Tauri-S variants with RS232 / CAN / RS485, the function of the pins can be configured by the application software.
For permanently connected equipment: supply wiring requirements, requirements for any external switch or circuit-breaker, and external over-current protection devices, we recommend that the switch or circuit-breaker be near the equipment.
All signals at connector X27 are galvanically decoupled from the GND reference potential of the board and the supply voltage of the phyGATE Tauri-S.
The phyGATE Tauri-L gateway housing is designed to be mounted on a top-hat rail in the control cabinet. For mounting on the top-hat rail, there is a mounting device on the housing which allows a tool-free and safe mounting on a 35 mm top-hat rail.
Picture of top-hat rail clip (reserved, will be added in next revision)
The installation environment, such as the control cabinet in which the device is installed, must meet, as a minimum, the IP44 specifications and must be fireproof.
L'environnement de l’installation du dispositif, comme l'armoire de commande dans laquelle l’appareil est installé, doit répondre, au minimum, aux spécifications IP44 et être ignifuge.
For intended use, the device must be installed on a 35 mm top-hat rail according to DIN EN 60715.
Pour l'utilisation à laquelle il est destiné, l’appareil doit être monté sur un rail profilé chapeau de 35 mm conformément à la norme DIN EN 60715.
To prevent malfunction or destruction of the device due to overheating, it is essential to ensure that the ventilation slots are not covered by surrounding components, cables, and other objects. The air must be able to circulate freely around the housing to dissipate heat.
Pour éviter tout dysfonctionnement ou destruction de l’appareil en cas de surchauffe, il est indispensable de s’assurer que les fentes d'aération ne sont pas couvertes par des composants environnants, des câbles et autres objets. L'air doit pouvoir circuler librement autour du boîtier pour dissiper la chaleur.
Getting Started with the phyGATE Tauri-S Gateway
To get started easily with your phyGATE Tauri-S device, you'll find a description with the necessary tools and provision of the know-how to work with the Linux Board Support Package (BSP) for the phyCORE-i.MX 6UL/ULL in this chapter. It shows you step by step, how to set up the device for an easy start in development, including:
essential connection of the device and getting access to the OS
installing and use the appropriate tools and sources
building custom kernels
deploying the OS in order to operate the software and hardware
To use the SD card as a boot device, you'll have to put the prepared SD card into the microSD card slot located in the front of the device's housing.
Set Boot Switch
The phyGATE Tauri-S provides a boot switch to choose the boot source of the device. You can choose either eMMC (DIP at position '1') or SD-Card (DIP at position 'ON') as a boot source.
The Switch is located at the opposite side of the housing referenced to the supply connector X28. You can reach the switch in between the vent slots of the housing with help of a small item e.g. a screwdriver to switch the position of the DIP switch.
Boot Switch Location
Powering the Board
The phyGATE Tauri-S has a 2 pin Phoenix Contact MINI COMBICON power connector (counterpart Phoenix Contact FMC 1,5/ 2-STF-3,81). The permissible input voltage is 12 VDC to 36 VDC. A 24 VDC adapter with a minimum current rating of 1A is recommended to supply the board.
Power Connector Location
After turning the power supply on, the green LED D9 in the device front will light up and the boards will start booting.
Please note the polarity of the Power connector X28. Make sure that your power adapter is correctly set up to use the polarity as shown in the picture above!
Do not make any electrical changes to the interfaces and cables while the board is connected to power. This is to avoid damage to the device!
Be aware that as soon as the phyGATE Tauri-S is supplied with power, the SD-Card boot sequence will begin. Ensure that all cables are connected to the board!
With help of the red user LED in the front of the device housing, you can see if the boot process is running. The LED is flickering during the boot process.
Connecting the OS via SSH
Once the board is done booting, you can connect to the board via Ethernet and SSH. Therefore you need to connect an RJ45 Ethernet cable between the phyGATE Tauri-S and your computer. Make sure that the IP configuration of your computer is configured as follows:
IP address: 192.168.3.10
Now you are able to log in via SSH. Therefore please use the following login data:
IP Address: 192.168.3.11
Password: no password
Login via SSH should only be used for purpose of development. Otherwise, there will be a security risk.
If you are using Windows:
For the SSH connection under Windows, you can use an SSH client of your choice. The description below is based on PuTTY:
The CAN configuration is automatically done by the daemon systemd. You can send messages with cansend or receive messages with candump:
target$ ip link can0 down
target$ ip link set can0 txqueuelen 10 up type can bitrate 500000 sample-point 0.75 dbitrate 4000000 dsample-point 0.8 fd on
target$ cansend can0 123#ab.cd.ef
target$ candump can0
Connecting to USB
The driver will detect USB Devices automatically. To mount a USB Flash for example, use the following commands:
target$ mount /dev/disk/by-id/usb_san_disk_0:-part1 /mnt/
target$ cd /mnt
Building the BSP
This section will guide you through the general build process of the i.MX 6UL BSP using the phyLinux script. For more details, see the sectionphyLinux Documentationin theYocto Reference Manual. If you want to use our software without phyLinux and theRepotool managed environment, you can find allGitrepositories at:
Ourbareboxversion is based on the mainline bareboxand adds only a few patches which will be sent upstream in the future.
Our i.MX 6UL/6ULL Linux kernel is based on theLinuxstable kernel. The kernel repository can be found at:
To find the correct software and the corresponding machine name for your PHYTEC board, go toi.MX 6UL/ULL BSP Releasesand click on the corresponding BSP release, or refer to the files in the source folder of the BSP:
where you can find the platform name to the corresponding product IDs. This information is also displayed by the phyLinux script.
The default boot source for the i.MX 6UL/6ULL modules like phyCORE-i.MX 6UL or phyCORE-i.MX 6ULL is the NAND flash. The easiest way to get started with your freshly created images is by writing them to an SD card and setting the boot configuration accordingly. For information on how to set the correct boot configuration, refer to the corresponding hardware manual for your PHYTEC board.
On BSP version PD19.1.0, there is a software issue with factory bad block detection, in which only 25% of the factory bad blocks are detected correctly and marked as such. Any I/O operation on the unmarked bad blocks will lead to an error. Please read the BSP Release Notes for more information. This issue is fixed on PD19.1.1.
Booting from SD Card
Booting from SD card is useful in several situations, for example, if the board does not start due to a damaged bootloader. To boot from an SD card, the SD card must be formatted in a special way as the i.MX 6UL/6ULL ROM code does not use file systems. Instead, it expects the bootloader at a fixed location on the SD card.
There are two ways to create a bootable SD card. You can either use: - a single prebuild SD card image, or - the four individual images (barebox-, kernel- and device tree image, and root filesystem)
Using a Single, Prebuild SD Card Image
The first option is to use the SD card image built byYocto. This image has the ending*.sdcardand can be found underbuild/deploy/images/<MACHINE>/<IMAGENAME>-<MACHINE>.sdcard. It contains all BSP files in an already correctly formatted image and can be easily copied to the SD card by using the singleLinuxcommanddd.
You can also find ready-to-use*.sdcardimages on ourFTP server.
To create your bootable SD card with theddcommand you must have root privileges. Because of that, you must be very careful when selecting the destination device for theddcommand! All files on the selected destination device will be erased immediately without any further query! Consequently, having selected the wrong device can also erase your hard drive!
To create your bootable SD card, you must first find the correct device name and possible partitions of your SD card. Then unmount the partitions before you start copying the image to the SD card.
In order to get the correct device name first remove your SD card and executels /dev.
Next, insert your SD card and executels /devagain.
Compare the two outputs to find the new device name(s) listed in the second output. These are the device names of the SD card (device and partitions if the SD card is formatted).
In order to verify the device names found, execute the commanddmesg. Within the last lines of its output, you should also find the device names, for example, sde(depending on your system).
Now that you have the device name/dev/<your_device>(e.g./dev/sde) you can also recognize the partitions which must be unmounted if the SD card is formatted. In this case, you will also find/dev/<your_device>with an appended number (e.g./dev/sde1) in the output. These represent the partition(s) to be unmounted.
Unmount all partitions:
host$ umount /dev/<your_device><number>
After having unmounted all devices with an appended number (<your_device><number>), you can create your bootable SD card:
using the device name (<your_device>) without appended number (e.g.sde) which stands for the whole device.
The parameterconv=fsyncforces a sync operation on the device beforeddreturns. This ensures that all blocks are actually written to the SD card and do not remain in the memory.
Using Four Individual Images (barebox-, kernel- and device tree image, and root filesystem)
Instead of using the single prebuild SD card image, you can use thebarebox, kernel, and device tree image together with the root filesystem separately to manually create a bootable SD card.
For this method, a new card must be set up with 2 partitions and 8 MB of free space at the beginning of the card. Use the following procedure withfdiskunderLinux:
Create a new FAT partition with partition id C. When creating the new partition, you must leave 8 MB of free space at the beginning of the card. When you go through the process of creating a new partition,fdisklets you specify where the first sector starts. During this process,fdiskwill tell you where the first sector on the disk begins. If, for example, the first sector begins at 2048, and each sector is 512 bytes. 8 MB / 512 bytes = 16384 sectors, which means your first sector should begin at 18432 to leave 8 MB of free space. The size of the FAT partition only needs to be big enough to hold the zImage which is only a few megabytes. To be safe we, recommend a size of 64 MB.
Create a newLinuxpartition with partition id 83. Make sure you start this partition after the last sector of partition 1! By default,fdiskwill try to use the first partition available on the disk, which in this example is 1000. However, this is our reserved space! You must use the remaining portion of the card for this partition.
Write the new partition to the SD card and exitfdisk.
host$ sudo fdisk -l /dev/sdc
You will receive:
Disk /dev/sde: 3,8 GiB, 4025483264 bytes, 7862272 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xef6c9559
Device Boot Start End Sectors Size Id Type
/dev/sde1 18432 149503 131072 64M c W95 FAT32 (LBA)
/dev/sde2 149504 7862271 7712768 3,7G 83 Linux
Remove and reinsert the card. Otherwise,Linuxwill not recognize the new partitions created in the previous step. Create a file system on the partitions with (replace 'sde' with your device):
Then copy your BSP image files to this directory. You also need to configure a static IP address for the appropriate interface. The default IP address of the PHYTEC evaluation boards is 192.168.3.11. So setting 192.168.3.10 with netmask 255.255.255.0 as a host address is a good choice.
Set TFTP_DIRECTORY to your TFTP server root directory Set TFTP_ADDRESS to the host address the server is listening to (set to 0.0.0.0:69 to listen to all local IPs) Set TFTP_OPTIONS, following command, shows the available options:
host$ man tftpd
Restart the services to pick up the configuration changes:
host$ sudo service tftpd-hpa restart
Configure TFTP as xinetd service:
To run the TFTP server with xinetd, the standalone daemon first needs to be disabled:
protocol = udp
port = 69
socket_type = dgram
wait = yes
user = root
server = /usr/sbin/in.tftpd
server_args = -s /tftpboot
disable = no
server_argsholds the options and the TFTP server root directory Reload the services to pick up the configuration changes:
sudo /etc/init.d/xinetd reload
After the installation of the TFTP server, an NFS server needs to be installed, too. The NFS server is not restricted to a certain file system location, so all we have to do on most distributions is modify the file/etc/exportsand export our root filesystem to the embedded network. For that, append/etc/exports:
and adapt it to your local needs, where <user> must be replaced with your home directory name and the <rootfspath> can be set to a folder that contains an extracted rootfstar.gzimage.
Updating from SD Card
To update the software from an SD card, one needs an SD card that holds all required images (barebox, kernel, devicetree, and root filesystem). Using an SD card that was flashed with the .sdcard image from Yocto out of the box is not possible since the FAT partition holding the kernel and devicetree image is not big enough to hold the root filesystem images.
A new partitioning scheme is created for the SD card. The SD card will hold the barebox in 8 MiB unpartitioned space at the first sectors to still be able to boot from this SD card and following that a FAT partition will hold all required images (including a copy of the barebox image).
Use the following procedure with fdisk under Linux:
First, delete all existing partitions on the disk and then create a new primary FAT partition with partition id C. When creating the new partition you must leave 8 MB of free space at the beginning of the card. When you go through the process of creating a new partition, fdisk lets you specify where the first sector starts. With the command F on an unpartitioned disk, fdisk tells you where the first sector on the disk begins. If, for example, the first sector begins at 2048 and each sector is 512 bytes, then 8 MB / 512 bytes = 16384 sectors. Therefore, your first sector should begin at 18432 to leave 8 MB of free space. The size of the FAT partition needs to be at least big enough to hold all required images. The partition can easily cover the rest of the SD card.
Remove and reinsert the card. Otherwise, Linux will not recognize the new partitions created in the previous step.
Create a file system on the partition with (replace 'sde' with your device):
host$ sudo mkfs.vfat /dev/sde1
Now write the barebox in front of the partition (replace 'sde' with your device):
Mount the FAT partition and copy all required images to the partition (replace 'sde' with your device):
host$ sudo mount /dev/sde1 /mnt
After copying unmount the FAT partition and insert the SD card into your board:
host$ sudo umount /mnt
To update i.MX 6UL/6ULL board from SD card, the SD card used for updating must be mounted after the board is powered and the boot sequence is stopped on the bootloader prompt. If the board is booted from the SD card, the card is already mounted automatically under/mnt/mmc/. Otherwise, mount the SD card in the barebox with:
bootloader$ detect mmc0
It is then also mounted under/mnt/mmc/if it was partitioned as described above. In any other case, the partition needs to be mounted manually.
Updating the bootloader from Linux Userspace
It is possible to update the barebox bootloader from within the booted Linux userspace. This can only be done if certain specifications have been met.
Updating NAND Flash bootloader from Linux Userspace
To update the barebox on the NAND Flash from within Linux Userspace, the kobs-ng tool is used. It implements the same failsafe update mechanism that is used with the barebox-update tool in the barebox. The following command requires the new barebox image to be copied to the target.
We also recommend erasing the environment of the old barebox. Otherwise, the new barebox will still use the old environment.
target$ flash_erase /dev/mtd1 0 0
After a reboot or power cycle, the new barebox will be used.
Updating eMMC bootloader from Linux Userspace
To update the bootloader on the eMMC from within Linux userspace, the dd command is used. This is similar to pregramming the bootloader to an SD card (see Booting from SD Card).
Some precautions need to be taken when updating the bootloader on the eMMC. The i.MX 6UL/6ULL ROM code expects the bootloader at a specific offset from the beginning of the eMMC. In front of that lies the partitioning table of the filesystem which follows the bootloader. So we have to make sure not to overwrite the partitioning table. Copying the bootloader to the eMMC can be achieved with:
After a reboot or power cycle, the new barebox will be used.
Since the rocko release, the RAUC (Robust Auto-Update Controller) mechanism support has been added to Yogurt. It controls the procedure of updating a device with new firmware. This includes updating the Linux kernel, Device Tree, and rootfs. It does not update the bootloader. For more information about RAUC, seehttps://rauc.readthedocs.io/en/latest/.
RAUC uses the barebox bootchooser and state framework (seeBarebox BootchooserandBarebox State-Frameworkfor more information). It can be used in different update scenarios. Have a look at the use cases below and the example setup used in the BSP.
RAUC on i.MX 6UL/6ULL
With the BSP-Yocto-i.MX6UL-PD19.10 BSP release, RAUC (Robust Auto-Update Controller) can be used with NAND flash. It is not enabled by default but our example can be configured and activated with the instructions shown below. RAUC can be used in different update scenarios. As an example, we configured the BSP to use an A-B setup with two redundant systems.
Example BSP Setup
The partition layout is defined in the/etc/rauc/system.conffile. Shown here is thesystem_nand.conffrom meta-yogurt used for our example setup:
There is no configuration for the barebox since a barebox update with RAUC is not supported.
Updates with RAUC use an OpenSSL certificate to verify the validity of an image. The BSP includes a certificate that can be used for development. In a productive system, however, it is highly recommended to use a self-created key and certificate.
Creating RAUC Bundles
To update your system with RAUC, a RAUC bundle (.raucb) needs to be created. It contains all required images and scripts for the update and a RAUCmanifest.raucmthat describes the content of the bundle for the RAUC update on the target. The BSP includes aYoctotarget that lets you build a RAUC bundle from your Yocto build.
To create the bundle withYocto, run:
host$ bitbake phytec-qt5demo-bundle
This results in the creation of a.raucbbundle file in thedeploy/images/<machine-name>/phytec-qt5demo-bundle-<machine-name>.raucbfile which can be used for an update described in the next chapter. There is no need to create amanifest.raucmmanually as it is created automatically during the build of the bundle. But as a reference, the created manifest would look something like:
Currently, there is a bundle target for thephytec-qt5demo-image(phytec-qt5demo-bundle) and thephytec-headless-image(phytec-headless-bundle).
Update NAND Flash with RAUC
To update the NAND flash with RAUC, the RAUC bundle file previously created first needs to be copied to the board or to a memory device that can be mounted inLinux. One way is to copy the bundle file withscp, but make sure that there is enough space left on the board's filesystem. To do this, boot the target board toLinuxand connect it via Ethernet to your host PC.
When you update from a USB stick, make sure to remove the stick after a successful update before rebooting. If not, an automatic update will be started after each boot. This is due to the "Automatic Update from USB Flash Drive example" you can find below.
With the success of the update, RAUC automatically switches the active system to the newly updated system. Now during reboot, RAUC counts the boot attempts of the kernel and if it fails more often than specified in the state framework of the system, RAUC switches back to the old system and marks the new system as bad. If the boot attempt to the kernel is successful, the new system is marked as good and now the old system can be updated with the same instructions. After two successfulrauc installandreboot, both systems are updated.
Change the Active Boot Slot
It is possible to switch the active system manually:
target$ rauc status mark-active other
Now after a reboot or power cycle, the kernel starts from the alternate system.
Use Case 1: Automatic Update from USB Flash Drive with RAUC
One of the most prominent use cases for RAUC might be an automatic update system from a USB flash drive. This use case is implemented in the BSP as a reference example. We combine only standardLinuxmechanisms with RAUC to build the system. The kernel notifiesudevwhen a device gets plugged into the USB port. We use a customudevrule to trigger asystemdservice when this event happens.
Use Case 2: Security measurement: downgrade barrier
As a second reference example, we will implement a security mechanism: a downgrade barrier. When you detect a security vulnerability on your system, you will fix it and update your system. The systems with the new software will now be secure again. If an attacker gets ahold of the old software update bundle, which has still a valid signature, the attacker might have the possibility to install the old software and still take advantage of the previously fixed security vulnerability. To prevent this from happening, you could revoke the update certificate for every single update and create a new one. This might be difficult to handle, depending on the environment. A simpler solution would be to allow updates only in one direction using a version check.
The script is installed on the target but it is not activated. You need to remove the developer mode line in the script to activate it.
How to setup RAUC for your Machine
First, you need to add the state framework configuration to thebareboxdevice tree. Check out theBSP Customizationchapter in theYoctoreference manual. You have to include theimx6ul-phytec-state.dtsifile to yourbareboxdevice tree by adding
to the includes. Afterward, rebuild the image
Be aware that by adding the state framework configuration, the EEPROM is partly occupied and can no longer be used for user-specific purposes.
The following device tree snippet shows the state framework configuration used with the BSP. As you can see, the EEPROM is used as a backend for the state information.
The next steps do not require a rebuild of the image and can be performed on a running system. To be able to boot from two systems alternately, the bootchooser needs to be aware of the state framework configuration. Also, two new boot scripts have to be created for system0 and system1 of the A-B system. To fulfill these requirements, boot your board and stop the boot process in the barebox.
The NAND flash can be updated from different sources too. You can choose from one of the possibilities described inUpdating the Software. Simply adapt the script and its name to the chosen source.
Device Tree (DT)
The following text briefly describes the Device Tree and can be found in theLinuxkernel (linux/Documentation/devicetree/usage-model.txt).
The "Open Firmware Device Tree", or simply Device Tree (DT), is a data structure and language for describing hardware. More specifically, it is a description of hardware that is readable by an operating system so that the operating system doesn't need to hard code details of the machine. Structurally, the DT is a tree or acyclic graph with named nodes, and nodes may have an arbitrary number of named properties encapsulating arbitrary data. A mechanism also exists to create arbitrary links from one node to another outside of the natural tree structure. Conceptually, a common set of usage conventions, called 'bindings', is defined for how data should appear in the tree to describe typical hardware characteristics including data busses, interrupt lines, GPIO connections, and peripheral devices.
The kernel is a really good source for a DT introduction. An overview of the device tree data format can be found on the device tree usage page atdevicetree.org:
PHYTEC i.MX 6UL/6ULL BSP Device Tree Concept
The following section explains some rules we have defined on how to set up device trees for our i.MX 6 and i.MX 6UL/6ULL SOC-based boards.
The device tree files are roughly divided into three layers:
the SoC layer
the module layer
the baseboard layer
This resembles the physical properties of the hardware. For example, the same phyCORE-i.MX 6UL module can be used on the phyGATE-Tauri or the phyBOARD-Segin.
In each layer, multiple device trees include files.
An overview of the device tree hierarchy for the PHYTEC i.MX 6UL/6ULL platforms are shown below.
PHYTEC i.MX 6UL/6ULL Device Tree Hierarchy
The following sections provide an overview of the supported hardware components and their corresponding operating system drivers. Further changes can be ported upon customer request.
To find out which boards and modules are supported by the release of PHYTEC’s i.MX 6UL/6ULL BSP described herein, visit our web page athttps://www.phytec.de/produkt/system-on-modules/phycore-imx-6ul-download/#software. Click the corresponding BSP release and look for the article number of your module in the column "Article Number". Finally, look for the correct machine name in the corresponding cell under "Machine Name".
To achieve maximum software re-use, theLinuxkernel offers a sophisticated infrastructure, layering software components into board-specific parts. The BSP tries to modularize the kit features as far as possible, which means that when a customized baseboard or a customer-specific module is developed, most of the software support can be re-used without error-prone copy-and-paste. The kernel code corresponding to the boards can be found in device trees (DT):
In fact, software re-use is one of the most important features of theLinuxkernel (especially the ARM implementation), which always had to fight with an insane number of possibilities of the System-on-Chip CPUs. The whole board-specific hardware is described in DTs and is not part of the kernel image itself. The hardware description is in its own separate binary, called device tree blob (DTB) (sectionBootloader's DT Modifications). Please read sectionPHYTEC i.MX 6UL/6ULL BSP Device Tree Conceptto get an understanding of our i.MX 6UL/6ULL BSP device tree model.
The following sections provide an overview of the supported hardware components and their operating system drivers on the i.MX 6UL and i.MX 6ULL platform.
i.MX 6UL/6ULL Pin Muxing
The i.MX 6UL/6ULL SOC contains many peripheral interfaces. In order to reduce package size and lower overall system cost while maintaining maximum functionality, many of the i.MX 6UL/6ULL terminals can be multiplexed to up to eight signal functions. Although there are many combinations of pin multiplexing possible, only a certain number of sets (called IO sets) are valid due to timing limitations. These valid IO sets were carefully chosen to provide as many application scenarios as possible for the user.
Please refer to the NXP i.MX 6UL and i.MX 6ULL Reference Manuals for more information about the specific pins and the muxing capabilities: - for the i.MX 6Ultra Lite:
The first part of the stringMX6UL_PAD_UART1_TX_DATA__UART1_DCE_TXnames the pad (PAD_UART1_TX_DATA). The second part of the string (UART1_DCE_TX) is the desired muxing option for this pad. The pad setting value (hex value on the right) is explained in:
In this example, the pad setting value0x1b0b1means the pin is configured with: PAD_CTL_HYS, PAD_CTL_SRE_SLOW, PAD_CTL_DSE_40ohm, PAD_CTL_SPEED_MED, PAD_CTL_PUS_100K_UP, PAD_CTL_PUE and PAD_CTL_PKE. For the i.MX 6UL the muxing options are defined in:
and for the i.MX 6ULL in:
The i.MX 6UL/6ULL SOCs provide up to 8 UART units. PHYTEC boards support different numbers of these UART units. The debug UART is configured as 115200 8N1 (115200 baud, 8 data bits, no parity bit, 1 stop bit). The other UARTs will have default settings, which normally will be 9600 baud.
The phyGATE-Tauri-S uses the UART1 (ttymxc0) as standard console output. From the command line prompt ofLinuxuser space, you can easily check the availability of other UART interfaces with:
target$ echo "test" > /dev/ttymxc4
Be sure that the baud rate is set correctly on both the host and target. In order to get the currently configured baud rate, you can use the commandsttyon the target. The following example shows how to copy all serial settings fromttymxc0tottymxc4.
Now, you can "echo" and "cat" data to and from/dev/ttymxc4
The Ethernet features provided by our modules and boards vary (e.g.: 1 x 10/100 Mbit on phyBOARD-Segin Low Cost and 2 x 10/100 Mbit on phyBOARD-Segin Full Featured).
However, all interfaces offer a standardLinuxnetwork port which can be programmed using the BSD socket interface. The whole network configuration is handled by thesystemd-networkddaemon. The relevant configuration files can be found on the target in/lib/systemd/network/and also in the BSP inmeta-yogurt/recipes-core/systemd/systemd-machine-units/.
IP addresses can be configured within*.networkfiles. The default IP addresses and netmasks for eth0 and eth1 are:
Here is the device tree excerpt of the first Ethernet interface (eth0) on the phyCORE-i.MX 6UL (arch/arm/boot/dts/imx6ul-phytec-phycore-som.dtsi):
With these configurations, Linux will boot with the necessary functionality to realize the ethernet bridge.
In the next step, the network daemon has to be configured appropriately. For this, networkd needs to know about the interfaces and their role. Modify the already available eth0 and eth1 interface config files under /lib/systemd/network/ . Comment all options under [Network] and add a Bridge option:
Then, create a netdev configuration file to set up a netdevice that should act as a bridge. The name of the bridge device needs to be referenced from the prior created interface files:
Finally, specify the network options for the formerly created netdevice:
Restart the network daemon for the changes to take effect:
systemctl restart systemd-networkd.service
The phyBOARD-Segin-i.MX 6UL provides a Controller Area Network (CAN) interface, which is supported by drivers using the proposed Linux standard CAN framework SocketCAN. Using this framework, CAN interfaces can be programmed with the BSD socket API.
The CAN bus offers a low-bandwidth, prioritized message fieldbus for serial communication between microcontrollers. Unfortunately, CAN was not designed with the ISO/OSI layer model in mind, so most CAN APIs available throughout the industry does not support a clean separation between the different logical protocol layers, for example, known from Ethernet.
The SocketCAN framework for Linux extends the BSD socket API concept toward CAN bus. Because of that, using this framework, the CAN interfaces can be programmed with the BSD socket API and behaves like an ordinary Linux network device, with some additional features special to CAN.
target$ ip link
to see if the interface is up or down. To get the information on can0 (which represents i.MX 6UL’s CAN module FLEXCAN1) (such as bit rate and error counters), type:
target$ ip -d -s link show can0
The information for can0 will look like the following:
The output contains a standard set of parameters also shown for Ethernet interfaces, so not all of these are necessarily relevant for CAN. The following output parameters contain useful information:
CAN cannot use ARP protocol
Maximum Transfer Unit
Number of Received Packets
Number of Transmitted Packets
Number of Received Bytes
Number of Transmitted Bytes
Bus Error Statistics
Ethernet Interface Output Parameters
The CAN configuration is done in thesystemdconfiguration file/lib/systemd/system/can0.service. For a persistent change of parameters change the configuration in the BSP undermeta-yogurt/recipes-core/systemd/systemd-machine-units/can0.serviceinstead and rebuild the root filesystem.
Description=can0 interface setup
ExecStart=/sbin/ip link set can0 up type can bitrate 500000
ExecStop=/sbin/ip link set can0 down
Thecan0.serviceis started by default after boot. You can start and stop it using:
To generate random CAN traffic for testing purpose, usecangen.
Seecansend --helpandcandump --helphelp messages for further information on options and usage. Here is a device tree excerpt for the can interface of the phyBOARD-Segin (arch/arm/boot/dts/imx6ul-phytec-segin.dtsi):
All i.MX 6UL/6ULL kits support a slot for Micro Secure Digital Cards to be used as general-purpose block devices. These devices can be used in the same way as any other block device.
These kinds of devices are hot-pluggable. Nevertheless, you must ensure not to unplug the device while it is still mounted. This may result in data loss.
After inserting an MMC/SD card, the kernel will generate new device nodes in/dev. The full device can be reached via its/dev/mmcblk0device node, MMC/SD card partitions will show up as:
<Y> counts as the partition number starting from 1 to the max. count of partitions on this device. The partitions can be formatted with any kind of file system and be handled in a standard manner, e.g themountandumountcommand work as expected.
These partition device nodes will only be available if the card contains a valid partition table (”hard disk” like handling). If it does not contain one, the whole device can be used as a file system (”floppy” like handling). In this case,/dev/mmcblk0must be used for formatting and mounting.
The cards are always mounted as being writable.
Device tree configuration for the MMC interface inarch/arm/boot/dts/imx6qdl-phytec-segin.dtsi:
After expanding the partition size, resize theext4file system in the partition:
target$ resize2fs /dev/mmcblk0p2
The command's output looks like this:
resize2fs 1.42.9 (28-Dec-2013)
Filesystem at /dev/mmcblk0p2 is mounted on /; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 15
The filesystem on /dev/mmcblk0p2 is now 3886080 blocks long.
Increasing the file system size can be done while it is mounted. Anon-lineresizing operation is performed. However, you can also boot the board from internal memory (NAND or eMMC) and then resize the file system on the SD card partition while it is not mounted.
The phyCORE-i.MX 6UL/6ULL, can be populated with an eMMC memory chip as main storage instead of the NAND Flash. eMMC devices contain raw MLC memory cells (sectionEnable pseudo-SLC Mode) combined with a memory controller, that handles ECC and wear leveling. They are connected via an MMC/SD interface to the i.MX 6UL/6ULL and are represented as block devices in theLinuxkernel like SD cards, flash drives, or hard disks.
In contrast to raw NAND Flash, an eMMC device contains a Flash Transfer Layer (FTL) that handles the wear leveling, block management, and ECC of the raw MLC cells. This requires some maintenance tasks, for example erasing non-used blocks, that are performed regularly. These tasks are calledBackground Operations(BKOPS).
In the default case (which depends on the chip), the background operations are not executed periodically which impacts the worst-case read and write latency.
Therefore, the JEDEC Standard version v4.41 specifies a method that the host can issue BKOPS manually. See the JEDEC Standard chapterBackground Operationsand the description of registers BKOPS_EN (Reg: 163) and BKOPS_START (Reg: 164) in the eMMC datasheet for more details.
Meaning of Register BKOPS_EN (Reg: 163) Bit MANUAL_EN (Bit 0):
Value 0: The host does not support the manual trigger of BKOPS. Device write performance suffers.
Value 1: The host does support the manual trigger of BKOPS. It will issue BKOPS from time to time when it does not need the device.
The mechanism to issue background operations has been implemented in theLinuxkernel sincev3.7. You only have to enable BKOPS_EN on the eMMC device (see below for details). The JEDEC standardv5.1introduces a new automatic BKOPS feature. It frees the host to trigger the background operations regularly because the device starts BKOPS itself when it is idle (see the description of bit AUTO_EN in register BKOPS_EN (Reg: 163)). eMMC chips deployed by PHYTEC currently do not support the new standardv5.1. TheLinuxkernel and userspace toolmmcdo not support this feature.
Here BKOPS_EN is enabled. The host will issue background operations from time to time. There is also a kernel boot message showing if BKOPS_EN is not set:
mmc1: MAN_BKOPS_EN bit is not set
To set the BKOPS_EN bit, execute:
target$ mmc bkops enable /dev/mmcblk1
To ensure that the new setting has taken over and the kernel triggers BKOPS by itself, shut down the system with:
and perform a power cycle.
The BKOPS_EN bit is a one-time programmable only. It cannot be reversed.
Enable pseudo-SLC Mode
eMMC devices use MLC memory cells (https://en.wikipedia.org/wiki/Multi-level_cell) to store the data. Compared with SLC memory cells used in NAND Flash, MLC memory cells have lower reliability and a higher error rate at lower costs.
If you prefer reliability over storage capacity, you can enable thepseudo-SLCmode orSLC mode. The method used here employs theenhanced attribute, described in the JEDEC standard, which can be set for continuous regions of the device. The JEDEC standard does not specify the implementation details and the guarantees of theenhanced attribute. This is left to the chipmaker. For the Micron chips, theenhanced attributeincreases the reliability but also halves the capacity.
When enabling theenhanced attributeon the device, all data will be lost.
The following sequence shows how to enable theenhanced attribute. First, obtain the current size of the eMMC device with:
As you can see this device has 3850371072 Byte = 3672.0 MiB. To get the maximum size of the device afterpseudo-SLCis enabled use:
target$ mmc extcsd read /dev/mmcblk1 | grep ENH_SIZE_MULT -A 1
which shows, for example:
Max Enhanced Area Size [MAX_ENH_SIZE_MULT]: 0x0000e5
i.e. 1875968 KiB
Enhanced User Data Area Size [ENH_SIZE_MULT]: 0x000000
i.e. 0 KiB
Here the maximum size is 1875968 KiB = 1832 MiB. Now, you can setenhanced attributefor the whole device, e.g. 1875968 KiB, by typing:
target$ mmc enh_area set -y 0 1875968 /dev/mmcblk1
You will get:
Done setting ENH_USR area on /dev/mmcblk1
setting OTP PARTITION_SETTING_COMPLETED!
Setting OTP PARTITION_SETTING_COMPLETED on /dev/mmcblk1 SUCCESS
Device power cycle needed for settings to take effect.
Confirm that PARTITION_SETTING_COMPLETED bit is set using 'extcsd read' after a power cycle
To ensure that the new setting has taken over, shut down the system:
and perform a power cycle.
It is recommended that you now verify the settings. First, check the value of ENH_SIZE_MULT which must be 1875968 KiB:
targe$ mmc extcsd read /dev/mmcblk1 | grep ENH_SIZE_MULT -A 1
You should receive:
Max Enhanced Area Size [MAX_ENH_SIZE_MULT]: 0x0000e5
i.e. 1875968 KiB
Enhanced User Data Area Size [ENH_SIZE_MULT]: 0x0000e5
i.e. 1875968 KiB
Finally, check the size of the device, in this example it should be 1920991232 Byte = 1832.0 MiB, with:
After expanding the partition size, resize theext4file system in the partition:
target$ resize2fs /dev/mmcblk1p2
The command's output looks like this:
resize2fs 1.43.8 (1-Jan-2018)
Filesystem at /dev/mmcblk1p2 is mounted on /; on-line resizing required
old_desc_blocks = 2, new_desc_blocks = 15
The filesystem on /dev/mmcblk1p2 is now 3729408 (1k) blocks long.
Increasing the file system size can be done while it is mounted. Anon-lineresizing operation is performed. But you can also boot the board from an SD card and then resize the file system on the eMMC partition while it is not mounted.
Erase the Device
It is possible to erase the eMMC device directly rather than overwriting it with zeros. The eMMC block management algorithm will erase the underlying MLC memory cells or mark these blocks asdiscard. The data on the device is lost and will be read back as zeros. After booting from SD card execute:
target$ blkdiscard --secure /dev/mmcblk1
The option--secureensures that the command waits until the eMMC device has erased all blocks.
dd if=/dev/zero of=/dev/mmcblk1also destroys all information on the device, but is bad for wear leveling and takes much longer!
For raw NAND flashes, the same could be achieved with the commandflash_erase.
Additional Software in the BSP
In the BSP, you will also find the toolflashbenchwhich allows the user to get the page size and erase the block size.
target$ flashbench -a /dev/mmcblk1 --blocksize=1024
This will, for example, result in:
align 1073741824 pre 779µs on 1.21ms post 768µs diff 439µs
align 536870912 pre 855µs on 1.29ms post 858µs diff 433µs
align 268435456 pre 846µs on 1.29ms post 821µs diff 454µs
align 134217728 pre 812µs on 1.25ms post 822µs diff 429µs
align 67108864 pre 846µs on 1.29ms post 832µs diff 452µs
align 33554432 pre 830µs on 1.24ms post 807µs diff 422µs
align 16777216 pre 841µs on 1.26ms post 842µs diff 418µs
align 8388608 pre 842µs on 1.27ms post 814µs diff 446µs
align 4194304 pre 838µs on 1.28ms post 842µs diff 436µs
align 2097152 pre 827µs on 928µs post 834µs diff 97.9µs
align 1048576 pre 826µs on 921µs post 827µs diff 94.5µs
align 524288 pre 828µs on 924µs post 841µs diff 89.6µs
align 262144 pre 835µs on 903µs post 841µs diff 65.1µs
align 131072 pre 842µs on 949µs post 853µs diff 101µs
align 65536 pre 854µs on 959µs post 858µs diff 103µs
align 32768 pre 844µs on 954µs post 869µs diff 97.2µs
align 16384 pre 862µs on 962µs post 847µs diff 108µs
align 8192 pre 849µs on 946µs post 847µs diff 98.5µs
align 4096 pre 858µs on 953µs post 855µs diff 96.9µ2s
align 2048 pre 845µs on 936µs post 846µs diff 90.8µs
PHYTEC i.MX 6UL/6ULL modules are equipped with raw NAND memory, which is used as media for storingLinux, DTB, and root filesystem including applications and their data files. The NAND Flash is connected to the General Purpose Media Interface (GPMI) of the i.MX 6Ul/6ULL. The NAND Flash type and size is automatically detected via the Open NAND Flash Interface (ONFI) during boot.
The partitions of the NAND Flash have defined thebareboxdevice tree and the barebox writes the partitions to the kernel device tree before booting. Thus, changing the partitions can be done either in thebareboxdevice tree or in thebareboxenvironment. How to modify the partitions during runtime in thebareboxenvironment is described in the sectionChanging MTD Partitions. Adding new partitions can be done by creating a new partition node in the corresponding board device tree (PHYTEC i.MX 6UL/6ULL BSP Device Tree Concept) in thebarebox.
The propertylabeldefines the name of the partition and theregvalue of the offset and size of a partition. Do not forget to update all following partitions when adding a partition or changing a partition's size.
Here is an example partitioning for the phyBOARD-Segin (arch/arm/dts/imx6ul-phytec-phycore-som.dtsi) in the barebox:
PHYTEC boards often have a set of pins especially dedicated to user I/Os. These pins are connected directly to i.MX 6UL/6ULL pins. The processor has organized its GPIOs into five chips (gpiochip0 – gpiochip4) of 32 GPIO lines each. By contrast, theLinuxkernel uses a single integer to enumerate all available GPIOs in the system. The formula to calculate the right number:
Linux GPIO number: <N> = (<X> - 1) * 32 + <Y>
Accessing GPIOs from userspace will be done using thelibgpiod. It provides a library and tools for interacting with the Linux GPIO character device. Examples of the usage of some of the tools:
Show detailed information about the gpiochips. Like their names, consumers, direction, active state, and additional flags:
target$ gpioinfo gpiochip0
Read the value of a gpio (e.g gpio 20 from chip0):
target$ gpioget gpiochip0 20
Set value of gpio 20 on chip0 to 0 and exit tool:
target$ gpioset --mode=exit gpiochip0 20=0
The help text ofgpiosetshows possible options:
# gpioset --help
Usage: gpioset [OPTIONS] = = ...
Set GPIO line values of a GPIO chip
-h, --help: display this message and exit
-v, --version: display the version and exit
-l, --active-low: set the line active state to low
-m, --mode=[exit|wait|time|signal] (defaults to 'exit'):
tell the program what to do after setting values
-s, --sec=SEC: specify the number of seconds to wait (only valid for --mode=time)
-u, --usec=USEC: specify the number of microseconds to wait (only valid for --mode=time)
-b, --background: after setting values: detach from the controlling terminal
exit: set values and exit immediately
wait: set values and wait for user to press ENTER
time: set values and sleep for a specified amount of time
signal: set values and wait for SIGINT or SIGTERM
The muxing for GPIO Pins can be added by adding or modifying a pinctrl_hog group which is associated directly with the iomux controller of the i.MX 6UL/6ULL. Since the GPIO pins are not related to a specific function that is dedicated to a driver, the muxing should be done in this pinctrl_hog group. Be careful when adding a new pinctrl_hog group since there could already be an existing pinctrl_hog group defined in your devicetree or in any of the included device tree files. In this case, the new group will override the existing one.
Fir example, to add pin 42 of the expansion connector of the phyBOARD-Segin as user GPIO, modify thearch/arm/boot/dts/imx6ul-phytec-segin.dtsifile as shown below:
Before adding a muxing for a GPIO always check the schematic or hardware manual if the pin is not already in use by another function. Otherwise, this can lead to a muxing conflict and malfunctioning the respective function.
Withgpio-keys, theLinuxkernel can interpret GPIO signals as virtual keyboard events. The phyBOARD-Segin can feature a PEB-EVAL-01 adapter board which contains two buttons from which one can be used with thegpio-keysdriver (see phyBOARD-Segin GPIO-Keys). By pushing a button, an interrupt is triggered which causes the system to handle the corresponding keyboard event.
To display the key events in ASCII format, useevtest.and select the correct event device:
To show the available input devices run:
You will get, for example:
No device specified, trying to scan all of /dev/input/event*
Select the device event number [0-1]:
Select input device gpio-keys. Listing the device withcatwill print the raw output:
target$ cat /dev/input/event1
The following gpio-keys are already assigned with the phyBOARD-Segin evaluation board:
Button S2 on PEB-EVAL-01
As Button S2 is assigned to the Power Key functionality, pressing this button initiates a power-down of the board. A wake-up from this state can only be issued by another press of the Power Key button. This behavior can be prevented by disabling the power key handling of systemd.
The Power Key handling of systemd can be disabled by setting the following configuration in /etc/systemd/logind.conf:
GPIO-Keys configuration in imx6ul-phytec-segin-peb-eval-01.dtsi:
The i.MX 6UL contains four Multimaster fast-mode I²C modules called I2C1, I2C2, I2C3, and I2C4. This chapter will describe the basic device usage of some of the I²C devices integrated on our phyBOARD-Segin. General i²C bus master device tree node (arch/arm/boot/dts/imx6ul-phytec-phycore-som.dtsi):
With RAUC (as described inRAUC), the EEPROM is used to hold the barebox state information.
RTCs can be accessed via/dev/rtc*. Because PHYTEC boards often have more than one RTC, there might be more than one RTC device file. To find out the name of the RTC device, you can read its sysfs entry with:
This will list all RTCs including the non-I²C RTCs.Linuxassigns RTC device IDs based on the device tree /aliases entries if present.
rtc0 = &i2c_rtc;
rtc1 = &snvs_rtc;
As the time is set according to the value of rtc0 during system boot, rtc0 should always be the RTC that is being backed up. Date and time can be manipulated with thehwclocktool, using the-w(systohc) and-s(hctosys) options. To set the date, first usedateand then runhwclock -w -uto store the new date into the RTC. For more information about this tool, refer to the manpage ofhwclock.
Device tree representation of I²C RTC (arch/arm/boot/dts/imx6ul-phytec-segin.dtsi):
The capacitive touchscreen is a part of the display module. For a simple test of this feature, startevtest:
USB Host Controller
The USB controller of the i.MX 6UL SOC provides a low-cost connectivity solution for numerous consumer portable devices by providing a mechanism for data transfer between USB devices with a line/bus speed up to 480 Mbps. The USB subsystem has two independent USB controller cores. Both are On-The-Go (OTG) controller cores but on the phyBOARD-Segin one of them is used as a host-only port.
The phyBOARD-Segin i.MX 6UL BSP includes support for mass storage devices, keyboards, and mice. Other USB-related device drivers must be enabled in the kernel configuration on demand. Due toudev, all mass storage devices connected get unique IDs and can be found in/dev/disks/by-id. These IDs can be used in/etc/fstabto mount the different USB memory devices in different ways.
Device tree configuration of USB on the phyBOARD-Segin (arch/arm/boot/dts/imx6ul-phytec-segin.dtsi):
Most PHYTEC boards provide a USB OTG interface. USB OTG ports automatically act as a USB device or USB host. The mode depends on the USB hardware attached to the USB OTG port. If, for example, a USB mass storage device is attached to the USB OTG port, the device will show up as/dev/sda.
In order to connect the board's USB device to a USB host port (for example a PC), you need to configure the appropriate USB gadget. With USBconfigfsyou can define the parameters and functions of the USB gadget. The BSP includes USBconfigfssupport as a kernel module.
target$ modprobe libcomposite
First, define the parameters such as the USB vendor and product IDs and set the information strings for the English (0x409) language:
- acm: Serial gadget, creates serial interface like /dev/ttyGS0. - ecm: Ethernet gadget, creates ethernet interface, e.g. usb0 - mass_storage: The host can partition, format, and mount the gadget mass storage the same way as any other USB mass storage.
Bind the defined functions to a configuration with:
The CPU in the i.MX 6UL/6ULL SOC is able to scale the clock frequency and the voltage. This is used to save power when the full performance of the CPU is not needed. Scaling the frequency and the voltage is referred to as 'Dynamic Voltage and Frequency Scaling' (DVFS). The i.MX 6UL/6ULL BSP supports the DVFS feature. TheLinuxkernel provides a DVFS framework that allows each CPU core to have a min/max frequency and a governor that governs it.
To get a complete list of the available frequencies type:
ondemand (default) switches between possible CPU core frequencies in reference to the current system load. When the system load increases above a specific limit, it increases the CPU core frequency immediately.
conservative is much like the ondemand governor. It differs in behavior in that it gracefully increases and decreases the CPU speed rather than jumping to max speed the moment there is any load on the CPU.
powersave always selects the lowest possible CPU core frequency.
performance always selects the highest possible CPU core frequency.
userspace allows the user or userspace program running as root to set a specific frequency (e.g. to 396000). Type:
For more detailed information about the governors refer to theLinuxkernel documentation in:linux/Documentation/cpu-freq/governors.txt.
TheLinuxkernel has integrated thermal management which is capable of monitoring SOC temperatures, reducing the CPU frequency, driving fans, advising other drivers to reduce the power consumption of devices, and – in the worst-case – shutting down the system quickly and safely (https://www.kernel.org/doc/Documentation/thermal/sysfs-api.txt).
This section describes how the thermal management kernel API can be used to monitor the i.MX 6UL SOC temperature. The i.MX 6UL has an internal temperature sensor for the SOC ("Temperature Monitor (TEMPMON)" in the i.MX 6UL/6ULL Reference Manual). The current temperature can be read in millicelsius with:
target$ cat /sys/class/thermal/thermal_zone0/temp
You will get, for example:
which meets a temperature of 77,535 °C.
There are two trip points registered by the imx_thermal kernel driver:
A passive trip point where the temperature is set to 10 °C below the maximum allowed temperature of the SOC.
A critical trip point where the temperature is set to 5 °C below the maximum allowed temperature of the SOC.
(see kernel sysfs folder /sys/class/thermal/thermal_zone0/)
So for instance with the industrial temperature grade of the i.MX 6UL/6ULL, the following trip points are registered:
passive: 95 °C
critical: 100 °C
These trip points are used by the kernel thermal management to trigger events and change the cooling behavior. The events and cooling behavior depend on the thermal policy that is used. The following thermal policies (also named thermal governors) are available in the kernel: Step Wise, Fair Share, Bang Bang, and User space.
The thermal policy used in this BSP is step_wise.
If the SoC temperature rises above the passive trip point, the maximum available CPU frequency is reduced step-wise. If the temperature then drops under the passive trip point temperature again, the frequency throttling is released. If the SoC temperature reaches the critical trip point temperature, the thermal management of the kernel shuts down the systems. On the serial console you can see:
kernel: [ 895.524255] thermal thermal_zone0: critical temperature reached(100 C),shutting down
[ OK ] Stopped target Sound Card.
[ OK ] Stopped target System Time Synchronized.
[ OK ] Stopped target Network. Stopping Autostart Qt 5 Demo...
The PHYTEC i.MX 6UL/6ULL SOCs include a hardware watchdog that is able to reset the board when the system hangs. This chapter will explain how to handle the watchdog in the barebox to monitor a kernel boot and also how to handle the watchdog in Linux using systemd to check for system hangs and during reboot. By default, the watchdog is enabled in barebox and Linux.
Prior to PD21, the Watchdog was disabled. The Watchdog behavior has changed and is now default enabled since PD21.
Watchdog Support in systemd
Systemd has included hardware watchdog support since version 183. To activate watchdog support, the file system.conf in /etc/systemd/ has to be adapted by enabling the options:
RuntimeWatchdogSec defines the timeout value of the watchdog, while ShutdownWatchdogSec defines the timeout when the system is rebooted. For more detailed information about hardware watchdogs under systemd refer to http://0pointer.de/blog/projects/watchdog.html
If the watchdog is enabled in the barebox it continues running in Linux so there is no need to also enable it with systemd
Changes in this manual
Updated Power Information
Updated housing information
Wir nutzen Cookies auf unseren Webseiten und in damit zusammenhängenden Diensten. Einige von ihnen sind notwendig, um die Funktionalität der Webseiten zu gewährleisten, während andere uns helfen, diese Websiten zu verbessern oder zusätzliche Funktionalitäten zur Verfügung zu stellen.