phyCARD-XL

Hardware Manual

QuickStart Instructions

Application Notes

Software

Kit CD

Dimensioned Drawing

Module Connector

PHYTEC Order Number: VB090

FAQ

phyCARD-XL

Linux

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 CE

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

HABToolKit with phyCORE i.MX31 Development Kit

Question:

We are using a few phyCORE i.MX31 Development Kits with preinstalled Linux, U-Boot bootloader etc.
The kit contains a tool called HABToolKit which can be used to boot the target board over the serial port (i.e. not booting the flash resident U-Boot), and load and run an application in RAM. Also, it shall be possible to program an image into flash memory. I understand that the processor in these cases boots from an internal ROM which implements some kind of ROM bootstrap protocol to communicate with HABToolKit.

There is also documentation on how to use HABToolKit. However, my problem is that I cannot make it work. By using a monitor program on the host PC serial port, I see that HABToolKit sends commands to the target board, and sometimes responses are also returned by the target board. Sometimes the responses appear to be "correct", this is something like 0x56, 0x78, 0x78, 0x56, because on these occasions HABToolKit proceeds to send more commands.

However, the responses sent by the target board are very often different, in fact they are usually "garbage" or missing. There seems to be some kind of randomness about this, and the procedure usually stops at some point. I think, however, the DIP switches are set right, because otherwise I would think there would be no request/response at all.

I therefore have the following questions:
Have you ever successfully used HABToolKit at all with the phyCORE i.MX31 Development Kit ?
If so, is there anything special that must be done, some kind of special jumper setting, register initialization or whatever ?
Is it possible to obtain the document describing the ROM bootstrap protocol (i.MX31_ROM_User_Guide.pdf or something) ?
When downloading a program with the HABToolKit, is the downloaded program supposed to have some kind of specific format, header, or whatever ?

Answer:

Your problem seems to result of a mismatch of the baudrate used for the connection. It might be that you followed an older QS-Instruction where switch 1 of S5 is set ON. Later we discovered that the connection is much more reliable if switch 1 is OFF.

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.MX31 Dokumentation

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

Link: i.MX31 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

phyCORE-i.MX31: Bad Magic Number error

Question:

I get an error message “Bad Magic Number” on the UBoot console.

Answer:

All this error message tells us is that something with the kernel is not right, or there is no kernel available on the target system or the parameters in UBoot do not match. In other words, there could be all kinds of reasons for seeing this type of error message. This is especially true if you are using a different kernel.

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.

RealView ICE

Question:

Does the RealView ICE support the NXP i.MX31 processor?

Answer:

Yes

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