phyFLEX-i.MX 6 Downloads

Hardware Manual

Yocto Reference Manual

Heatspreader

Software

Image Processing

Dimensioned Drawing

FAQ

FAQ

phyFLEX-i.MX 6

Setting boot mode DIP-switch

As being described within the manuals, for booting from SD card DIP-Switch S3 must be set to ON-ON-OFF-OFF. But in case that your baseboard is an OEM-board instead of that shipped within our RDKs, most probably this switch is not populated. In such a case you need to wire the according pads or close solder jumpers (see schematics of your OEM-board).

QNX BSP

Our partner BitCtrl created a QNX BSP for the phyFLEX-i.MX6. Please visit their pages for more information.


English: http://www.bitctrl.de/produkte/hw_qnx/bsp/phyFLEX-i.MX6/index_en.shtml

German: http://www.bitctrl.de/produkte/hw_qnx/bsp/phyFLEX-i.MX6/index.shtml

 

 

Linux

Creating a bootable SD card

Setting up SD Card Partitions for Bootloader and Linux RootFS

1. A new card must be setup with 2 partitions and 8 MB of free space at the beginning of the card. Use the following procedure with fdisk under Linux:

  • 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, fdisk lets you specify where the first sector starts. During this process fdisk will tell you where the first sector on the disk begins. If the first sector begins at 1000 for example, and each sector is 512 bytes in size, then 8 MB / 512 bytes = 16384 sectors ==> your first sector should begin at 17384 to leave 8 MB of free space. The size of this fat partition only needs to be big enough to hold the zImage which is only a few megabytes. To be safe, make this partition 64 MB in size.
  • Create a new Linux partition with partition id 83. Make sure you start this partition after the last sector of partition 1! By default fdisk will try to use the first partition available on the disk, which in this example is 1000. However, this is our reserved space! You can use the remaining portion of the card for this partition. Write the new partitions to the SD card and exit fdisk.

 

2. Create filesystems on the partitions (you may need to remove and reinsert the card for Linux to recognize the new partitions created in the previous step and you need to replaxe sdx by the proper devices):

mkfs.vfat /dev/sdx1

mkfs.ext3 /dev/sdx2

 

3. Mount the partitions so that you can copy files to them:

mount -t auto /dev/sdx1 /mnt/sdx1

mount -t auto /dev/sdx2 /mnt/sdx2

 

4. Copy the images from the BSP to the card:

cp linuximage /mnt/sdx1/zImage

tar -xvzf root.tgz -C /mnt/sdx2

 

5. umount the partitions:

umount /dev/sdx1

umount /dev/sdx2

 

6. Copy barebox image and environment to the card using the script write_flash.sh:

./write_flash.sh /dev/sdx barebox.bin barebox_default_env

 

 

write_flash.sh

#!/bin/sh

DEV=$1

LOADER=$2

ENVIRONMENT=$3

err_exit () {

  echo -e "Error: $1\n";

  echo -e "\tUse this script with parms: Device BareboxImage bareboxEnvironmentImage"

  echo -e "\tEx: write_flash.sh /dev/sdb barebox.bin barebox_default_env"

  exit 1

}

[ -z "$DEV" ] && err_exit "device not found"

[ -b "$DEV" ] || err_exit "Device '$DEV' not a block device."

[ -f "$LOADER" ] || err_exit "barebox image not found"

[ -f "$ENVIRONMENT" ] || err_exit "barebox environment image not found"

 

echo "Writing bootloader '$LOADER' and environment '$ENVIRONMENT' to '$DEV'"

 

echo -ne "Writing loader: "

dd if="$LOADER" of="$DEV" bs=512 skip=2 seek=2 >/dev/null 2>&1 && echo "Ok" || echo "False"

 

echo -ne "Writing environment: "

dd if="$ENVIRONMENT" of="$DEV" bs=512 seek=4096 >/dev/null 2>&1 && echo "Ok" || echo "False"

sync

Activating and deactivating cores

To determine the number of active cores use:
grep '^processor*:*' /proc/cpuinfo | cut -d : -f 2 | wc -l

Turning off a core, i.e. core #1 (cpu0):
echo 0 > /sys/devices/system/cpu/cpu0/online

Reactivating core #1 (cpu0):
echo 1 > /sys/devices/system/cpu/cpu0/online

Use "cpu1" for core #2, "cpu2" for core #3, ...

But please note:

i.MX6 Solo and Dual Lite will behave differently to a Quad with only 1 or 2 activated cores, anyway! Amongst others this is due to different width and speed of the busses.

 

 

Accessing GPIO inputs as interrupt from userspace

The Linux kernel offers an UIO-driver for this purpose. For usage see Linux-kernel-documentation within "DocBook/uio-howto.tmpl" or online this link:
www.kernel.org

Decreasing amount of available RAM

In order to change the amount of available RAM for example to 512 MB, you need to add "mem=512M" parameter within Barebox's environment.

For current BSP versions this means to add "mem=512M" within "/env/config-board" at the end of the line:

global.linux.bootargs.base="console=ttymxc3,115200 enable_wait_mode=off vt.global_cursor_default=0 consoleblank=0 mem=512M"

Out of 512MB RAM, 128MB will be allocated to GPU and 384MB for general uses. Depending upon your requirement you can change GPU memory size. In order to modify the GPU memory size you need to make modification in kernel
board config file.

Verwendung eines Nameserver anmelden

Damit auch bei fix eingestellten IP-Adressen ein Nameserver verwendet wird, sind die folgenden Einstellungen vorzunehmen:

In die /etc/resolv.conf gehört ein Eintrag der Art:
nameserver 192.168.1.19

In der /etc/nsswitch.conf muß der Eintrag "hosts: files" erweitert werden zu "hosts:files dns".

Ein gültiger Default-Gateway sollte eingestellt sein, erkennbar daran, daß die Anweisung "route" eine Zeile "default" mit ausgibt.

Wo finde ich die Linux-Sourcen und sind diese schon an die PHYTEC-Module angepaßt?

Auf unserem FTP-Server finden Sie unter ftp://ftp.phytec.de/pub/Products/ eine Auswahl unserer Module. Das darunter befindliche Verzeichnis "Linux/" beinhaltet die letzte(n) aktuelle(n) BSP-Version(en). Diese bestehen aus den fertig flashbaren Binary-Images sowie einem OSELAS-Tarball und der PTXdist-Toolchain.

Der OSELAS-Tarball enthält außer den letzten PHYTEC-Patches selber kaum Sourcen. Vielmehr ist es ein Regelwerk, mit dem PTXdist die Binary-Images erstellen kann. Dazu ist eine Verbindung zum Internet erforderlich, denn fast sämtliche Sourcen werden von dem Regelwerk aufgrund fest hinterlegter Links von dort geladen. Die Sourcen befinden sich also erst nach der Erstellung der Binaries auf Ihrer Festplatte und enthalten dann in der Tat auch sämtliche Anpassungen an Ihr PHYTEC-Modul.

Windows Embedded Compact 7

Fragen und Antworten zu ähnlichen Produkten

Phytec Linux BSP on a Gentoo Linux Host

Phytec Linux BSP on a Gentoo Linux Host

There's a couple of useful documentations of how to use a Phytec Linux BSP on a Gentoo Linux Host available under http://en.gentoo-wiki.com/wiki/Phytec_phyCORE-iMX35

Stromaufnahmen des phyCORE-i.MX35

Stromaufnahmen des phyCORE-i.MX35

Maximalwerte (teilweise kurze Stromspitzen) gemessen bei 5V Eingangsspannung:
- beim Booten des Moduls:             ~235 mA (~1,175W)    (Spitzenwert)
- bei UBootbetrieb, Prompt:            ~220 mA (~1,1W)    (Standardwert)
- bei einem RAM-Test aus dem UBoot:        ~210 mA (~1,05W)    (Spitzenwert)
- bei Linuxbetrieb, Prompt:            ~145 mA (~0,725W)    (Standardwert)
- bei einem Ping des Moduls über Ethernet:      ~145 mA (~0,725W)    (Spitzenwert)
- inkl. Display, Displaytest:            ~146 mA (~0,73W)    (Spitzenwert)

Die Werte beinhalten noch keinen richtigen Streßtest. In einem solchen Falle könnten die Stromaufnahmen höher liegen.

3.3V liefert der Powerchip mit maximal 1,6 Ampere. Was davon das Modul nicht selber verbraucht - siehe obige Tabelle - steht Ihnen über die Connectorpins zur Verfügung.

Boot über USB

Problem:

phyCORE-i.MX35 bootet nicht über USB.

Antwort:

Offenbar wertet der i.MX35 einen LOW-Pegel an dem RX-Pin seines UART als "aktivity" und schaut dann nicht mehr nach USB...
Nach High-setzen des RX-Pins (über den RS422 Receiver) funktioniert das Booten mit ATK-Tool auch über USB problemlos.

=> Soll über USB gebootet werden, muß UART-RX-Input auf High sein (bei angeschlossenem RS232-Treiber ist das der Fall).

NXP i.MX27 Dokumentation

Auf der Homepage von NXP auf der i.MX27 Product Summary Page finden Sie  Application Notes, Datasheets und Reference Manual und vieles mehr zu dem i.MX27 Controller

Link: i.MX27 Product Summary Page

NXP i.MX35 Dokumentation

Auf der Homepage von NXP auf der i.MX35 Product Summary Page finden Sie  Application Notes, Datasheets und Reference Manual und vieles mehr zu dem i.MX35 Controller

Link: i.MX35 Product Summary Page

JTAG header connector

Question:

We need to interface to X2, an ARM-JTAG connector pads on the i.MX31 board. Do you supply a connector/cable for this interface?

Answer:

We have the header connectors to be populated at X2 on the SBC module. We also have an adapter cable that converts the non-standard 2.0mm pitch at X2 to a more standard 2.54mm male connector. However, my recommendation is to access the JTAG header connector on the Carrier Board at X6.

Welcher Modulsockel für das phyCORE-i.MX Modul?

Die Bezeichnung des Molexverbinders lautet: 52760-2079 und die des Gegenstückes auf der Basisplatine 55091-2079.

Die technischen Daten finden Sie unter
www.molex.com
und
www.molex.com

Je nach der von Ihnen benötigten Stückzahl für Ihre eigene Entwicklung kann es sich anbieten die Teile bei uns zu beziehen, da wir sie natürlich in sehr großen Stückzahlen einkaufen und wir deshalb in der Lage sind, Ihnen ein interessantes Angebot unterbreiten zu können. Die Artikelnummer dazu lautet VB107. Sie benötigen immer zwei Stück pro Modul

Wenn bei Ihnen diesbzgl. Interesse besteht, wenden Sie sich bitte an den Vertrieb, der Ihnen gerne ein konkretes Angebot unterbreiten wird.

Notwendige Minimalbeschaltung Spannungsversorgung phyCORE-i.MX

Wir haben zu diesem Thema ein TechNote vorbereitet, das Sie unter folgendem Link herunterladen können:

Download: TechNote

Ergänzend zu dieser TechNote, wie wir vor Kurzen herausgefunden haben, müssen bei dem phyCORE-i.MX31 der Condensator C179 und bei dem phyCORE-i.MX27 der Condensator C160 entfernt werden.


Bild: Position von C179 auf dem phyCORE-i.MX31

Bild: Position von C160 auf dem phyCORE-i.MX27


Bei allen neuen Modulen, die wir seit 15.09.2008 produzieren und produziert haben, sind diese Condensatoren nicht mehr bestückt!

64 MByte NOR Flash auf phyCORE-i.MX Modulen?

Die phyCORE-i.MX27 und phyCORE-i.MX31 Module unterstützen zurzeit nur 32MByte NOR Flashes.

Weitere technische Daten entnehmen Sie bitte aus der Beschreibung zu dem jeweiligen Modul.

Wie hoch ist die Stromaufnahme des phyCORE-i.MX27/31 Moduls?

Die Stromaufnahmen der Module für den normalen Betrieb entnehmen Sie bitte den folgenden Tabellen. Die controllerspezifischen Stromspar-Modi  realisieren wir  gerne auf Kundenanfrage. Für nähere Informationen steht Ihnen unser  Vertriebsteam zur Verfügung.

 
phyCORE-i.MX31:

Modul-Zustand

VIN

Main-Input X26

VCC_3V3

VCC_CHARGE

x_VBAT

 

typ.

max.

typ.

max.

typ.

max.

typ.

max.

typ.

max.

U-Boot prompt

181,5mA

 

811mA

 

140,5mA

 

2,9mA

 

0mA

 

Linux Login, Display an

90mA

240mA

735mA

811mA

138mA

153,2mA

3,44mA

3,61

0mA

 

Linux Login, Display an, dd if=/dev/urandom of=/dev/null count=16M

280mA

290mA

1052mA

1061mA

138mA

153,2mA

3,44mA

3,61

0mA

 

 

 

phyCORE-i.MX27:

Modul-Zustand

MainBoard-VIN

Modul-VIN

VCC_3V3

X_Charger_Input_3-20V

x_VBAT

 

typ.

max.

typ.

max.

typ.

max.

typ.

max.

typ.

max.

Ruhezustand ohne Peripherie

 

 

 

97mA

 

42,5mA

 

3,5mA

 

TBD

Windows BSP laden, Display an

 

 

 

132mA

 

61mA

 

4,1mA

 

TBD

Windows, Display an, Peripherie in Betrieb (AUDIO etc)

 

 

 

153mA

 

52mA

 

2,8mA

 

TBD

 

 

 

Back to product

Back to the product page of phyFLEX-i.MX 6

*) discontinued, not recommended for new products / development