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).

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

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

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.

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

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.

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.

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.

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

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.

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).

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

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

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.

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.

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!

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.

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:

phyCORE-i.MX27: