Vorschlag für die I2C Implementierung unter Linuxstatic.sws.bfh.ch/download/MAS-07-01-10-spec.pdf · 4.1.1 Abstrahierung im sysfs ... Will der Prozessor die IVM-Daten aus dem IVM-EEPROM

MT 07-01.10

Vorschlag für die I2C Implementierung unter Linux

Abstract:

Thesis topic is the evaluation and documentation of describing Single-Master I2C-topologies on Embedded-Linux containing Multiplexers and other I2C slave devices. Employing a prototype on a PowerPC based target, a mechanism of hiding the topology and its ease of integration are demonstrated.

Diplomand:

Christian Herzig, [email protected], 031 377 12 15

Experte:

Rolf Lanz, [email protected], 031 848 32 73

Betreuer der Arbeit:

Thomas Reufer, [email protected], 031 377 11 24

Dieses Dokument ist Bestandteil der Thesis MT 07-01.10

MT 07-01.10

Implementierungsvorschläge für Linux, Rev. B

14.08.2009 2/30 Christian Herzig

Zusammenfassung Die Firma KEYMILE migriert ihre Produkte von vxWorks nach Linux. Noch nicht geklärt ist die Art der I2C-Migrierung. Es besteht eine provisorische Lösung, welche auf alten vxWorks Konzepten basiert.

Dieses Dokument zeigt auf, welche Varianten der Implementierung in Frage kommen. Grundsätzlich lässt sich das I2C-Framework im Kernel- und/oder Userspace realisieren. Aus diesem Dokument wird ersichtlich, dass das I2C-Framework trotz des erhöhten Aufwandes nach den Konzepten von Linux im Kernel entwickelt werden soll.

Dieser Vorschlag gilt für bestehende, zu migrierende Produkte der Firma KEYMILE, für neu entwickelte Produkte der Firma KEYMILE, und für die Diplomarbeit MT07-01.10.

Die Vorteile der Kernel-Lösung liegen hauptsächlich in der Wiederverwendbarkeit von bestehenden und getesteten Treibern. Weiterhin ist die Auseinandersetzung mit der Kernelstruktur eine spannende Herausforderung, da es sich nicht um ausschliessliche Programmieraufgaben handelt, sondern ebenfalls das Beherrschen von Tools und Workflows umfasst.

Ziel der Diplomarbeit ist eine Lösung im Linux-Kernel, welche anhand der Hardwarebeschreibung im Flattened Device Tree automatisch die entsprechenden Treiber lädt. Das Management der Multiplexer soll vom Kernel übernommen werden.

Der Userspace Teil umfasst ein API, welches dem Softwareentwickler eine komfortable Schnittstelle auf die I2C-Elemente und dessen Parameter bietet.

MT 07-01.10



Lesehilfe Kapitel 1, Generelles Dieses Kapitel bietet einen Überblick. I2C-relevante Linux Terminologien sowie das Linux Kernel I2C-Subsystem werden erläutert. Ebenfalls sind Information zu finden, wo das I2C-Framework zum Einsatz kommt.

Kapitel 2, Entwicklungsbasis In diesem Kapitel sind die Werkzeuge für die Umsetzung der Diplomarbeit festgelegt. Dazu gehören die Entwicklungsumgebung sowie das Zielsystem.

Kapitel 3, Datenbasis Dieser Teil geht darauf ein, wie PowerPC Architekturen unter Linux beschrieben werden. Dies geschieht mit dem „Flattened Device Tree“. Wie dieser aufgebaut ist und wie diese Datenbasis schlussendlich für die Beschreibung der Multiplexer aussehen könnte, ist aus weiteren Listings und Beschreibungen in diesem Kapitel zu entnehmen.

Kapitel 4, Mögliche Implementierungsvarianten Grundsätzlich lässt sich ein Framework im Userspace oder im Kernelspace implementieren. Diese beiden Möglichkeiten unterscheiden sich grundsätzlich, gewähren jedoch beide die volle Funktionalität.

Kapitel 5, Gegenüberstellung der Varianten Die verschiedenen Implementierungsvarianten haben unterschiedliche Vor- und Nachteile. Dieses Kapitel listet die Stärken und Schwächen der einzelnen Varianten auf.

Kapitel 6, Die Vorteile nutzen Dieses Kapitel unterstreicht die wichtigsten Vor- und Nachteile. Die in diesem Kapitel erlangten Fakten bilden die Grundlage für die Auswahl der Variante in Kapitel 7.

Kapitel 7, Auswahl der Varianten, Vorschläge In diesem Kapitel werden die einzelnen Implementierungen vorgestellt. Es beinhaltet die Vorschläge für bestehende Produkte der Firma KEYMILE, für Neuentwicklungen der Firma KEYMILE sowie den Vorschlag und Beschluss, wie das I2C-Framework für die Diplomarbeit MT07-01.10 implementiert wird.

Kapitel 8, Abkürzungen, Begriffe und Namen Hier ist das Verzeichnis mit Abkürzungen, Begriffen und Namen zu finden.

Kapitel 9, Illustrationsverzeichnis Dieses Kapitel beinhaltet das Verzeichnis aller Abbildungen.

Kapitel 10, Verzeichnis der Listings Dieses Kapitel beinhaltet das Verzeichnis der im Dokument verwendeten Codeausschnitte.

Kapitel 11, Literaturverzeichnis Hier sind die Quellen aufgelistet, welche als Grundlage für das vorliegende Dokument dienten. Weiterhin sind die Quellen genannt, auf welche innerhalb des Dokuments verwiesen wird.

Kapitel 12, Historie Die in diesem Kapitel aufgeführte Tabelle zeigt die Aktualität und den Verlauf des vorliegenden Dokuments auf.

MT 07-01.10



Inhalt Zusammenfassung................................................................................................................ 2

Lesehilfe................................................................................................................................ 3

Inhalt ..................................................................................................................................... 4

1 Generelles...................................................................................................................... 6 1.1 Leserkreis ............................................................................................................... 6 1.2 Einsatzgebiet........................................................................................................... 6 1.3 Entwicklungs-Zielsystem ......................................................................................... 6 1.4 Linux Terminologie.................................................................................................. 6 1.5 I2C Subsystem Architektur ...................................................................................... 7

2 Entwicklungsbasis .......................................................................................................... 8 2.1 ETER1-Hardware.................................................................................................... 8

3 Datenbasis ..................................................................................................................... 9 3.1 Configtable.............................................................................................................. 9 3.2 Hardware Beschreibung unter Linux ......................................................................11 3.3 Flattened Device Tree............................................................................................11

3.3.1 Knoten und ihre Eigenschaften .......................................................................12 3.3.2 / (root) .............................................................................................................12 3.3.3 /cpus ...............................................................................................................12 3.3.4 /cpus/PowerPC,8360@0.................................................................................13 3.3.5 /memory..........................................................................................................13 3.3.6 /soc .................................................................................................................13 3.3.7 Kind-Knoten von /soc ......................................................................................13 3.3.8 /soc/i2c............................................................................................................13

4 Mögliche Implementierungsvarianten ............................................................................15 4.1 Logik im Kernelspace.............................................................................................15

4.1.1 Abstrahierung im sysfs ....................................................................................15 4.2 Logik im Userspace................................................................................................16

5 Gegenüberstellung der Varianten..................................................................................17 5.1 Vorteile des Frameworks im Kernel........................................................................17

5.1.1 Open Source...................................................................................................17 5.1.2 Profitieren von vorhandenen Treibern .............................................................17

5.2 Nachteile des Frameworks im Kernel .....................................................................17 5.2.1 Implementierung erfordert fundiertes Kernelwissen.........................................17 5.2.2 Preisgabe von Know-How ...............................................................................18 5.2.3 Pflege bei neuen Kernelversionen...................................................................18 5.2.4 Keine Floating Point Operationen verfügbar....................................................18

5.3 Vorteile des Frameworks im Userspace .................................................................18 5.3.1 Unabhängigkeit vom Kernel ............................................................................18 5.3.2 Stabilität ..........................................................................................................18 5.3.3 Effizienz ..........................................................................................................18

5.4 Nachteile des Frameworks im Userspace ..............................................................19 5.4.1 Kein definiertes Interface für den Zugriff..........................................................19 5.4.2 Nebenläufigkeit ...............................................................................................19 5.4.3 Open Source Code nicht nutzbar ....................................................................19 5.4.4 Open Point ......................................................................................................19

6 Die Vorteile nutzen........................................................................................................20

7 Auswahl der Varianten, Vorschläge...............................................................................21

MT 07-01.10



7.1 KEYMILE ...............................................................................................................21 7.1.1 Bestehende Produkte......................................................................................21 7.1.2 Neue Produkte ................................................................................................21 7.1.3 Übergangslösung ............................................................................................21

7.2 MT 07-01.10...........................................................................................................22 7.2.1 Verfolgung des Grundgedankens....................................................................22 7.2.2 Konzept...........................................................................................................22 7.2.3 Userspace Schnittstelle Sysfs .........................................................................23 7.2.4 Userspace Schnittstelle /dev ...........................................................................24 7.2.5 Hürden ............................................................................................................24 7.2.6 Userspace.......................................................................................................24

8 Abkürzungen, Begriffe und Namen................................................................................28

9 Illustrationsverzeichnis ..................................................................................................29

10 Verzeichnis der Listings.................................................................................................29

11 Literaturverzeichnis .......................................................................................................30

12 Historie..........................................................................................................................30

MT 07-01.10



1 Generelles

1.1 Leserkreis Dieses Dokument richtet sich primär an die Software-Entwickler der Firma KEYMILE, welche für die Linux-Plattform verantwortlich sind. Des Weiteren richtet sich dieses Dokument an alle Personen, welche in die Master Thesis MT-07-01.10 involviert sind. Grundkenntnisse von Linux und I2C sind Voraussetzung, um den Inhalt dieses Dokuments und den Kontext der Problemstellung zu verstehen. Fundiertes Linux -Basiswissen kann aus den Quellen [7] und [8] erlangt werden. Für I2C-Basiswissen wird an dieser Stelle auf das Kapitel 3 in [1] verwiesen. Ebenso sollte der Leser die Notwendigkeit, den I2C-Baum zu beschreiben sowie die Vorgehensweise unter vxWorks kennen [1].

1.2 Einsatzgebiet Die hier beschriebenen Implementierungsvorschläge gelten für den I2C-Teil der Embedded Linux-Plattform für die Produkte Milegate und UMUX. Milegate und UMUX sind Multiservice Plattformen für Telekom-Netzbetreiber und stellen das Vermittlungsstück zwischen WAN und den Endbenutzern dar. Unterstützte Dienste reichen von Telefonie über xDSL bis hin zu FTTx. Weiterhin finden diese Plattformen aufgrund ihrer hohen Verfügbarkeit Einsatz im Bereich des Schienenverkehrs. Die Plattformen unterstützen hierbei eine Vielzahl von Teilnehmerschnittstellen, von RS232 bis GbE. Die Anbindung an das Backbone-Netz erfolgt wahlweise über GbE oder STM-1/STM-4.

1.3 Entwicklungs-Zielsystem Entwickelt wird das I2C-Framework auf einer UMUX Baugruppe, der ETER1 Hardware. Die ETER1 ist eine Ethernet Baugruppe mit Switching und Routing Funktionalität, welche den Anschluss von Ethernet Netzen an ein PDH/SDH Netz ermöglicht. Für die Entwicklung des I2C-Frameworks ist die Funktion dieser Baugruppe nicht relevant, da die I2C-Problematik vollständig gekapselt ist.

1.4 Linux Terminologie In der Linuxwelt werden im Zusammenhang mit dem I2C-Subsystem einige Begriffe verwendet, deren Bedeutung nicht auf Anhieb erkennbar ist. In diesem Abschnitt sollen diese Begriffe kurz erläutert werden.

Grundsätzlich kann der Linux Kernel ausschliesslich die Master Rolle einnehmen. Der Kernel ist also dafür zuständig, dass eine Kommunikation mit den Slave-Komponenten stattfinden kann.

Die Logik, die Register eines I2C-Kontrollers richtig anzusprechen, ist bei jedem I2C-Kontroller unterschiedlich. Diese Logik wird als Bus-Algorithm bezeichnet. Für die Hardware Anbindung ist der Bus-Adapter zuständig. Bus-Algorithm und Bus-Adapter sind in der Regel in einem c-File vereint. Eine Ausnahme bildet der „Bus-Algorithm für Bitbang“ (den Software-emulierten I2C-Kontroller). Dieser ist unabhängig vom Kontroller.

Jede Art von Slave-Komponente, in Linux Client genannt, benötigt einen eigenen Treiber. Dieser Teil der Software wird Device Driver genannt.

Bei einer gegebenen Konfiguration - wie es bei der ETER1 der Fall ist - werden sowohl ein Bus-Algorithm und ein Bus-Adapter für den Bus benötigt, als auch mehrere Device Drivers für die I2C-Clients. In der Regel ist ein Device Driver pro Client notwendig.

MT 07-01.10



1.5 I2C Subsystem Architektur Abbildung 1 zeigt die Architektur des I2C-Subsystems im Linux Kernel. Beim Driver handelt es sich um einen Device Driver. Device Driver existieren für diverse Arten von I2C-Elementen wie RTC, EEPROM, GPIO und weiteren Typen des Hardware Monitorings. Der i2c-core beinhaltet die I2C bzw. SMBus Protokoll Implementierung sowie Methoden für die Registrierung vom Device Driver beim Bus-Adapter.

Am unteren Rand des Kernelbereichs dargestellt sind die Algorithmen- und Adapter-Driver, welche den Bus-Accessor (Treiber des Bus-Masters) beinhalten. Algorithmus- und Adapter-Driver sind in der Regel zusammengefasst. Eine Ausnahme bilden dabei die Bitbang Treiber, welche sich den Algorithmus teilen.

sysfs /dev

Program

ClientsDriverDriver

Algorithm Adapter

I2C Core

Adapter specific Code

I2C Dev I2C Dev I2C Dev I2C Dev

Abbildung 1: Aufbau des I2C-Subsystems (Kernel 2.6.29)

Der Programm-Block stellt die Userspace Programmteile dar, welche auf I2C zugreifen. Entweder wird mit Hilfe des i2c-dev Treibers auf das /dev Interface zugegriffen (deprecated), oder mit chip-spezifischen Treibern über sysfs.

MT 07-01.10



2 Entwicklungsbasis Als Entwicklungsumgebung dient ein Linux-PC mit installierter ELDK. Sowohl für den Prototypen als auch für das Produkt ist die UMUX Baugruppe ETER1 sowohl Zielsystem als auch Entwicklungs- und Demonstrationsobjekt. Kernstück dieser Baugruppe ist ein PowerQUICC II Pro Prozessor (MPC8360), welcher zwei integrierte I2C-Kontroller enthält. Der erste I2C-Kontroller wird von der ETER1-Applikation benötigt, der zweite ist beim KEYMILE-Produkt deaktiviert. Für den Prototypen wurden an den zweiten Kontroller zu Testzwecken weitere Clients angeschlossen.

2.1 ETER1-Hardware

Abbildung 2 zeigt den Aufbau des I2C-Teils aus Hardwaresicht. Der Multiplexer steht nach Power-up per default auf Kanal 0. So kann der Prozessor seine Bootparameter, die „Hard Reset Configuration Words“, aus dem Boot-EEPROM beziehen.

Will der Prozessor die IVM-Daten aus dem IVM-EEPROM auslesen, so muss zunächst der Multiplexer auf Kanal 1 gestellt werden.

An Kanal 2 sind vier Temperatursensoren angeschlossen.

Die Kanäle 3 bis 7 sind nicht besetzt.

Abbildung 2: I2C-Topologie auf der ETER1 P1A

MT 07-01.10



Aus dem Blockschaltbild aus Abbildung 2 lässt sich folgender I2C-Baum ableiten:

I2C

Ctrlr #0

TMP1

LM75

TMP2

LM75

TMP3

LM75

TMP4

LM75

IVM

24C08

Adr. 0x70

Adr. 0x50-0x53 Adr. 0x48 Adr. 0x49 Adr. 0x4a Adr. 0x4b

#0 #1 #2

MUX1

PCA9547

Boot

24C08

Adr. 0x50-0x53 Abbildung 3: I2C-Topologie auf der ETER1 P1A

Um die Möglichkeiten der ETER1-Hardware etwas auszubauen, wird der zweite Kontroller ebenfalls mit Slave-Komponenten ausgestattet. Der Baum wird am ersten Kontroller noch durch einen Temperatursensor erweitert. Letztendlich wird auf folgender Topologie entwickelt:

Abbildung 4: I2C-Topologie auf dem Entwicklungs-Zielsystems

3 Datenbasis Um ein Kernel-Image für unterschiedliche Produkte verwenden zu können, muss die Hardware in einer Datenbasis beschrieben werden. Motivation und Hintergründe der Datenbasis sind im Dokument Anforderungen [2] zu entnehmen.

3.1 Configtable Der I2C-Baum, wie er in Abbildung 3 dargestellt ist, wurde unter vxWorks wie folgt beschrieben [1]:

MT 07-01.10



CONFIG_FILE ID = "Main Controller"

RECORD UNIT_IDENT

CT_SS_REVISION "$Rev: $"

CT_SS_HEADER "$HeadURL: $"

DEVICE_NAME "ETERx"

CPU_TYPE mpc8360

END_R

#

# DEFINITION OF IVM RECORDS

#

RECORD IVM ID = MAIN_CTRL

EEPROM_ADDRESS 0xa0 # addr 0

EEPROM_SIZE 1024

EEPROM_TYPE X24C08

# MUX

{

MUX_ADDRESS 0xE0 # mux 0

MUX_CHANNEL 0x09 # channel 1

MUX_TYPE PCA9547

}

END_R

#

# THERMOMETER

#

RECORD THERMO ID = Top

THERMO_ADDRESS 0x90 # addr 1001000x

THERMO_TYPE LM75A

{


MUX_CHANNEL 0x0a # channel 2

MUX_TYPE PCA9547

}

END_R

RECORD THERMO ID = Control


THERMO_TYPE LM75A

{



MUX_TYPE PCA9547

}

END_R

RECORD THERMO ID = Power


THERMO_TYPE LM75A

{



MUX_TYPE PCA9547

}

END_R

RECORD THERMO ID = Front


THERMO_TYPE LM75A

{



MUX_TYPE PCA9547

}

END_R

END_C

Abbildung 5: Beschreibung der I2C-Beschaltung mit der Configtable unter vxWorks

MT 07-01.10



Unter Linux lässt dich diese Form der Beschreibung weiterverwenden, sofern eine Lösung im Userspace angestrebt wird. Der Vorteil dieses Ansatzes ist, dass die Syntax der Configtable in der Firma KEYMILE bereits bekannt ist.

3.2 Hardware Beschreibung unter Linux Eine Alternative zur Configtable ist der „Flattened Device Tree“. Bei PowerPC Architekturen wird die Abstraktion der Hardware mit einer Baumstruktur gelöst, welche in Kapitel 3.3 detaillierter beschrieben wird.

Der Vorteil des Linux- Ansatzes ist, dass die gesamte Hardwarebeschreibung an nur einer Stelle erfolgt. Auf die Configtable kann somit verzichtet werden, da diverse andere Hardware-Komponenten (SPI, Ethernet PHYs, Flash, RAM …) bereits in dem „Flattened Device Tree“ beschrieben sind.

Ein schwerwiegender Nachteil dieser Art der Beschreibung ist, dass gewisse I2C-Device Driver noch nicht durch den Kernel unterstützt werden. Der Einsatz des Flattened Device Tree bedeutet, dass relativ tief im Kernel Codeänderungen vorgenommen und somit das I2C-Subsystem angepasst oder gar umgebaut werden müsste.

Es liegt nahe, die I2C-Busbeschreibung für PowerPC Architekturen ebenfalls in diesen Device Tree zu integrieren. Der Vorteil ist, dass auf die Configtable gänzlich verzichtet werden kann.

Open Point: Inwiefern ist der Mechanismus vom Flattened Device Tree im Linux Kernel bereits für ARM Architekturen integriert?

3.3 Flattened Device Tree Eine verbreitete Variante zur Beschreibung von Hardware in Embedded Linux Systemen ist die Verwendung eines Device Trees. So benutzen Apple-Rechner eine Art Device Tree und IBM-Server den Device Tree von Openfirmware (OF).

Ein Device Tree ist eine Datenstruktur. Wie durch den Name bereits suggeriert, handelt es sich um eine Baumstruktur mit folgenden Eigenschaften:

- Die Struktur besteht aus mehreren Knoten - Jeder Knoten hat einen Namen - Jeder Knoten hat genau einen Eltern-Knoten - Jeder Knoten beinhaltet Daten in Form von Properties

Im Device Tree wird das funktionale Layout einer Hardware bestehend aus CPU, Speicher und Peripherie beschrieben. Mit wenigen Ausnahmen repräsentiert jeder Knoten ein physikalisches Bauteil. Bei PowerPC basierten Systemen ist die Beschreibung der Hardware mittels Device Tree „state of the art“.

Der Device Tree wird nicht in den Kernel hineinkompiliert. Dieser eigenständige Code dient der Hardware-Abstraktion, mit welcher es möglich ist, ein Kernel Image auf verschiedenen Systemen einsetzen zu können.

Damit der Linux-Kernel auf die Datenstruktur zugreifen kann, muss diese aufbereitet werden (Abbildung 6). Dies geschieht mit dem Device Tree Compiler (DTC). Quellcode für diesen Compiler ist das Device Tree Source-File (DTS). Das kompilierte Produkt ist ein Device Tree Binary Large Object (DTB).

MT 07-01.10



DTSDTC

DTB

Abbildung 6: Aus der Device Tree Source resultiert ein BLOB

In den folgenden Unterkapiteln werden die einzelnen Knoten vorgestellt. Die Listen mit den Properties sind nicht vollständig. Es sind lediglich jene Properties aufgelistet, die in jedem Fall definiert werden sollten. Weiterführende Informationen sind aus der Kernel Dokumentation [5, booting_without_OF.txt] zu entnehmen.

3.3.1 Knoten und ihre Eigenschaften Jeder Device Tree hat einen Root-Knoten. Dieser hat folgendes Format:

Listing 1: Root Knoten

/{

}

Knoten werden mit Properties beschrieben. Grundsätzlich gibt es vier verschiedene Arten von Properties:

Listing 2: Properties und Kind-Knoten

/ {

// 0-terminierter String

property1 = „string_value“;

// 32-bit Wert, hexadezimal

property2 = <1234cdef>;

// 3 numerische 32-bit Werte (3 Zellen)

property3 = <12345678 deadbeef cafeaffe>;

// Beliebiges Array of Bytes

property4 = [01 02 0a de ad be ef];

//Hinzufügen eines Kind-Knotens

Kind-Knotenname@Adresse {

}

}

Listing 2 zeigt neben den vier Property Arten, wie ein neuer Kind-Knoten hinzugefügt werden kann.

3.3.2 / (root) Der Root-Knoten wird definiert durch folgende Properties:

- model: Name des Boards - compatible: Board Familie

3.3.3 /cpus Alle Prozessoren werden unter dem Knoten /cpus deklariert. Es wird empfohlen, die Properties

- #address_cells = <00000001> - #size_cells = <00000000>

bei jedem Knoten zu definieren.

MT 07-01.10



3.3.4 /cpus/PowerPC,8360@0 Die Bezeichnung PowerPC,8360@0 bedeutet Folgendes:

- PowerPC: Prozessor-Architektur - 8360: Prozessortyp - @0: Erster Prozessor im System.

Ein weiterer Prozessor vom Typ MPC8360 bekäme die Bezeichnung @1. Die erforderlichen Properties, um diesen Knoten zu beschreiben, sind:

- device_type: muss “cpu“ sein - d-cache-block-size: Cacheblock Grösse für Daten - i-cache-block-size: Cacheblock Grösse für Instruktionen - d-cache-size: Grösse des Datencaches - i-cache-size: Grösse des Instruktionen Caches

3.3.5 /memory Unter diesem Knoten werden die Speicherbausteine aufgelistet und parametrisiert. Da dieser Ast nicht direkt mit der zu lösenden Aufgabe zusammenhängt, wird an dieser Stelle nicht weiter auf diesen Aspekt eingegangen und für weiterführende Information auf die Kerneldokumentation [5] verwiesen.

3.3.6 /soc Sofern es sich beim Prozessor um einen Mikrokontroller handelt, also neben dem Flash und RAM-Kontroller noch weitere Hardwarekontroller integriert sind, repräsentiert dieser Knoten ein SOC (System On a Chip).

Folgende Properties müssen in diesem Knoten deklariert werden:

- device_type: muss „soc“ sein - ranges: der Adressrange des SOC - bus-frequency: die Busfrequenz des SOC

3.3.7 Kind-Knoten von /soc Jeder Kontroller von dieses SOCs wird durch einen eigenen Kind-Knoten repräsentiert. So auch die beiden I2C-Kontroller des MPC8360.

3.3.8 /soc/i2c Jeder I2C-Kontroller wird durch einen separaten Kind-Knoten im /soc repräsentiert. Für den MPC8360 bedeutet dies konkret, dass der erste Kontroller durch den Knoten /soc@e0000000/i2c@3000 und der zweite durch /soc@e0000000/i2c@3100 repräsentiert werden. Bei der ETER1, dem ersten KEYMILE Embedded Linux Board, ist soc auf die Adresse 0xe0000000 gemappt. Der erste I2C-Kontroller liegt auf der Adresse 0xe0003000, der zweite an der Adresse 0xe003100.

Dies ergibt folgende Properties für den ersten Kontroller:

- reg = <0x3000 0x100>; Offset und Grösse des Adressbereichs - compatible = „fsl-i2c“; Freescale-I2C

I2C-Slave Teilnehmer von diesem I2C-Kontroller sind somit an dieser Stelle zu repräsentieren. Der Device Tree des I2C-Teils der ETER1, passend zum I2C-Baum wie in Abbildung 3 dargestellt, könnte wie folgt aussehen:

MT 07-01.10



Listing 3: Auszug aus DTS File für die I2C-Beschreibung

soc@0xe0000000{

reg = <0x00000000 0x00100000>;

compatible = “fsl-8360”;

i2c@3000 {

interrupt-parent = <40000>;

interrupts = <1b 3>;

reg = <3000 0x18>;

device_type = “i2c”

compatible = „fsl-i2c“;

dfsrr;

mux1@70{

compatible = “pca9544A”;

ivm@50{

channel = <0x09 0x1>;

reg = <0x50 0x100>;

compatible = “24c08”;

};

temp_top@48{

channel = <0x0a 0x1>;

reg = <0x50 0x1>;

compatible = “lm75”;

};

temp_ctrl@49{


reg = <0x51 0x1>;


};

temp_power@4a{


reg = <0x51 0x1>;


};

temp_front@4b{


reg = <0x51 0x1>;


};

};

};

};

MT 07-01.10



4 Mögliche Implementierungsvarianten Grundsätzlich gibt es zwei Varianten für die Einbettung des I2C Frameworks unter Linux. Auf diese Varianten wird in den folgenden Kapiteln eingegangen.

4.1 Logik im Kernelspace Die erste Variante siedelt das gesamte I2C-Framework im Kernelspace an. Dies bedeutet, dass der Applikations-Entwickler direkt über Systemcalls via sysfs auf die Hardware zugreift.

Abbildung 7: I2C-Framework ausschliesslich im Linux Kernel

4.1.1 Abstrahierung im sysfs Linux unterstützt Mechanismen zur Abstraktion. So könnte das IVM-EEPROM im sysfs mit einem speziellen IVM-Driver folgendermassen modelliert werden:

Listing 4: Mögliche File-Struktur des sysfs

/sys/bus/i2c-0/

devices/0-0050/

eeprom

board_id

hw_key

…

/0-0048/

temp1_input

temp1_max

temp1_max_hyst

…

drivers/

ivm_driver

lm75

Mit dem Systemcall read() können nun beispielsweise direkt die board_id oder der hw_key ausgelesen werden, mit dem Systemcall write()kann die Temperatur-Hysterese für den Thermostaten gesetzt werden.

MT 07-01.10



4.2 Logik im Userspace Die zweite Variante sieht das gesamte I2C-Framework im Userspace vor. Dies bedeutet, dass der Applikations-Entwickler über ein proprietäres API auf die Hardware zugreift.

Abbildung 8: I2C-Framework ausschliesslich im Userspace

Seit dem Kernel 2.6.23 unterstützt Linux eine Methode, Hardware-Treiber ausserhalb des Kernels als so genannte Userspace-Treiber laufen zu lassen. Die Anwendung ist also in der Lage, direkt Hardware anzusteuern.

Um einen Userspace-Treiber einzusetzen, müssen zwei Bedingungen erfüllt sein:

• Es wird Kernel-Code benötigt, der die Hardware mit dem Userspace verbindet. Dieses Stück Code wird mit dem Kernel kompiliert und als Kernelmodul geladen. Das geladene Modul öffnet beliebig viele Adressfenster, über welche direkt aus dem Userspace auf die Hardware zugegriffen werden kann.

• Der Kernel muss so konfiguriert sein, dass Userspace-Treiber unterstützt werden.

Applikation

Userpart

Proprietäres Interface

Linux-Kernel

Hardware

Kernelpart

Abbildung 9: UIO Modell

MT 07-01.10



5 Gegenüberstellung der Varianten Beide Methoden der Implementierung sind möglich und würden zum gewünschten Ziel führen. Beide Methoden haben Vor- und Nachteile, welche in diesem Kapitel erläutert werden.

5.1 Vorteile des Frameworks im Kernel

5.1.1 Open Source Der Open Source Gedanke steht und fällt mit den damit verbundenen Lizenzbedingungen. Programmcode, der im Kernelspace läuft, fällt automatisch unter die GPL (GNU Public Licence). Dies bedeutet, dass der Quellcode auf Anfrage hin offengelegt werden muss. Dies mag wie ein Nachteil erscheinen, wird jedoch im Kapitel 5.2.2, Preisgabe von , relativiert.

Ein immenser Vorteil von Open Source ist, dass durch die Linux Community Unterstützung zu erwarten ist. Durch das pro-aktive Veröffentlichen von Quellcode wird dieser vielen erfahrenen Linux Entwicklern zugänglich. Das Begutachten des Codes durch diese Sachverständigen entspricht einem Online-Review. Auf diese Art und Weise ist es möglich, die Software-Qualität zu steigern, um letztendlich ein hochwertigeres Softwareprodukt zu erstellen, welches der Firma zu Gute kommt.

Open Source wird im Bereich der Wirtschaft eher reserviert betrachtet, sobald es um die Veröffentlichung von firmeninternem Wissen geht. Hier ist Aufklärungsarbeit zu leisten: Ein veröffentlichter Code, der weiter benutzt wird, fällt automatisch unter die GPL. Dies bedeutet, dass der Ersteller selber somit auch wieder freien Zugriff auf den weiter entwickelten Code hat und profitieren kann.

Schlussendlich liegt die Entscheidung, Open Source als Vor – oder Nachteil zu betrachten, bei jedem Einzelnen. In Anbetracht der Tatsache, dass ein grosser Profit und somit Wissenszuwachs möglich gemacht wird, ist der Autor dieses Dokuments der Meinung, dass die positiven Aspekte überwiegen, und der Open Source Gedanke unterstützenswert ist.

5.1.2 Profitieren von vorhandenen Treibern Wird ein neues Bauteil einsetzt, so ist die Wahrscheinlichkeit gross, dass bereits ein Treiber hierfür existiert. So gibt es beispielsweise Treiber für den auf den KEYMILE Boards eingesetzten LM75 Temperatursensor. Ebenso ist für das EEPROM ein entsprechender Treiber bereits geschrieben und getestet worden.

5.2 Nachteile des Frameworks im Kernel

5.2.1 Implementierung erfordert fundiertes Kernelwissen Kernel Know-how ist erfordert, wenn man Treiber schreibt oder erweitert. Programmcode, der im privilegierten Modus abläuft, muss fehlerfrei laufen, da ansonsten die Stabilität des ganzen Systems gefährdet ist.

Das Erlangen von Kernel Know-how kann sich als schwierig erweisen. Hierfür gibt es viele Dokumente im Internet, Helpfiles im Linux-Kernel (Kernel-Documentation) und Bücher, mit welchen versucht wird, das Innenleben des Kernels zu beschreiben. Da der Kernel rasant wächst und ständig weiterentwickelt wird, ist das Studium des Quellcodes unerlässlich, um die Mechanismen zu erfassen. Der erhebliche Zeitaufwand für die Einarbeitung in den Kernel-Code muss einkalkuliert werden.

MT 07-01.10



5.2.2 Preisgabe von Know-how Wer Programmcode im Kernelspace laufen lässt, muss die GPL Richtlinien erfüllen und den Code offenlegen. Dieser Punkt wurde bereits in Kapitel 5.1.1 relativiert. Dennoch muss beachtet werden, welche Informationen dadurch preisgegeben werden. Entscheidungen müssen von der Geschäftsleitung unterstützt und getragen werden.

5.2.3 Pflege bei neuen Kernelversionen Wenn ein Betriebssystem bestehen will, muss es den Bedürfnissen der Anwender gerecht werden. Da die Bedürfnisse und somit auch die Anforderungen an das Betriebssystem steigen, wird der Kernel ständig erweitert, verbessert und überarbeitet. Dies kann zur Folge haben, dass Schnittstellen im Kernel geändert werden müssen.

Änderungen an Schnittstellen betreffen in der Regel ebenfalls die angrenzenden Komponenten. Je mehr proprietärer Kernel-Code man schreibt, desto eher besteht die Gefahr, dass eigene Komponenten, bedingt durch die Weiterentwicklung des Kernels, nicht mehr auf Komponenten des Linux Kernels passen. Erneute Anpassungen vom proprietären Kernel-Code sind erfordert. Es empfiehlt sich, Kernel-Code in die Mainline zu bringen, wo er im Falle von API-Änderungen durch Kernel-Entwickler angepasst wird.

5.2.4 Keine Floating Point Operationen verfügbar Floating Point Arithmetik ist rechenintensiv. Da die Abläufe im Kernel bewusst kurz gehalten werden müssen, wurde auf die Unterstützung von Floating-Point Arithmetik im Kernel verzichtet.

5.3 Vorteile des Frameworks im Userspace

5.3.1 Unabhängigkeit vom Kernel Wie die Abbildung 9 zeigt, benötigen Userspace-Treiber auch ein Kernelmodul. Dieses muss für jede Kernelversion kompiliert werden.

Das Kernelmodul umfasst nur wenige Codezeilen und ist daher gut überschaubar. Da die Möglichkeit, Treiber im Userspace laufen zu lassen, erst mit dem Kernel 2.6.23 unterstützt wurde und sich bewährt hat, kann davon ausgegangen werden, dass die Schnittstelle zunächst nicht ändern wird.

Userspace Programmcode ist daher nahezu vollständig immun gegen Änderungen im Kernel.

5.3.2 Stabilität Kernel-Code läuft im privilegierten Modus. Fehlerbehaftete Treiber können die Stabilität des Systems schwächen. Programmcode ausserhalb des Kernels läuft im nicht-privilegierten Modus und sorgt daher für Stabilität des Systems.

5.3.3 Effizienz Bei jedem Systemcall erfolgt ein Prozesswechsel. Gerade in Realtime-Systemen kann dieser Wechsel ein entscheidender Nachteil sein, da dieser die Leistung des Systems negativ beeinflusst. Treiber im Userspace greifen direkt auf die Hardware zu. Da hierfür kein Prozesswechsel notwendig ist, kann dies je nach Anwendungsfall ein Vorteil sein.

MT 07-01.10



5.4 Nachteile des Frameworks im Userspace

5.4.1 Kein definiertes Interface für den Zugriff Im Gegensatz zur reinen Implementation im Kernelspace, wo mittels Systemcalls auf die Hardware zugegriffen wird, sind die Zugriffsfunktionen im Userspace proprietär. Die Vergangenheit hat gezeigt, dass proprietäre Schnittstellen auf Dauer ein Problem darstellen können und standardisierte Schnittstellen beständiger sind.

5.4.2 Nebenläufigkeit Bei Hardwarezugriffen aus dem Userspace könnten Konflikte bei der Benutzung und beim Ansprechen gemeinsamer Ressourcen entstehen. Hardwarezugriffe müssen also speziell geschützt werden.

5.4.3 Open Source Code nicht nutzbar Offengelegter Treibercode ist in der Regel für den Kernel geschrieben. Will man den Treiber aus dem Userspace laufen lassen, so müssen auch die Treiber für Standard-Bauteile wie I2C-EEPROMs selber geschrieben (und auch getestet) werden.

5.4.4 Open Point Für ein faires Scheduling ist es von immenser Bedeutung, ob ein Prozess oder Task auf Hardware zugreift oder nicht. Inwieweit dies vom Scheduler berücksichtigt wird oder ob dies zu potenziellen Problemen führen kann, sollte zu Beginn abgeklärt werden.

Aus der OS-Theorie dürfte ein Userspace Prozess, der direkt auf I2C-Hardware zugreift, vom Scheduler als „bösen Prozess“ identifiziert werden. Ein Zugriff auf I2C-Hardware dauert sehr lange und wird in der Regel mehrere volle CPU-Timeslots benötigen.

„Gute Prozesse“ sind solche, welche den Anspruch auf die CPU innerhalb ihres Timeslots freiwillig abgeben. „Gute Prozesse“ werden vom Scheduler begünstigt, „böse Prozesse“ tendenziell bestraft, indem ihnen seltener Timeslots zugesprochen werden.

Die Funktionsweise des verwendeten Schedulers (CFS) kann der Kernel-Documentation [12] entnommen werden.

MT 07-01.10



6 Die Vorteile nutzen Beide Varianten haben entscheidende Nachteile, welche bei der Suche nach der besten Implementierungsmethode berücksichtigt werden müssen. Dabei sollen die Vorteile genutzt und die Nachteile so gering wie möglich gehalten werden.

Abbildung 10: Allgemeine Einbettung des I2C-Frameworks

Abgesehen von den technischen Schwierigkeiten gibt es zwei Fakten, die unumstritten sind und generell gelten.

- Will man von der Linux Community profitieren, muss der Code in den Kernel. Denn so fällt der Code unter die GPL und muss jedem frei zugänglich sein. Diskussionen in Mailing-Listen werden von vielen erfahrenen Kernel Programmierern mitverfolgt. Durch solche Diskussionen werden neue und bessere Ansätze gefunden, was schlussendlich zu einer höheren Codequalität und somit zu einem stabileren Kernel führt.

- Sind vertrauliche Daten vorhanden, dürfen diese unter keinen Umständen in den Kernel. Denn Kernel Code fällt unter die GPL und ist daher jedem frei zugänglich.

Der erste Fakt ist erstrebenswert, aber mit hohem Aufwand verbunden, da der Linux-Kernel ein komplexes Konstrukt ist, dessen Verständnis enorm viel Einarbeitungszeit erfordert.

Der zweite Fakt ist politischer Natur. Soll interne Information in den Kernel integriert werden, so darf diese nicht als vertraulich klassifiziert sein. Sie erfordert eine Neuklassifizierung.

Dies ist der Grund, weshalb für die KEYMILE Produkte nicht die ganze Logik in den Kernel gebaut werden soll. Die „Aufteilung des IVM-EEPROMs“ ist als vertraulich klassifiziert und soll nicht zurückgestuft werden.

Das IVM-EEPROM stellt jedoch keinen Hinderungsgrund dar, dass der IVM-EEPROM Zugriff durch den Kernel erfolgt. Die Schnittstelle vom Kernel- zum Userspace, in der Abbildung 10 als rote Linie gekennzeichnet, ist ein File im sysfs, welches den Inhalt des gesamten IVM-EEPROMs repräsentiert. Die Aufteilung in die einzelnen IVM-Properties kann auf der Applikationsseite, aus dem Userspace, erfolgen. Der Applikationsentwickler kann nun über ein proprietäres Interface, in der Abbildung 10 als blaue Linie gekennzeichnet, auf die verschiedenen IVM Properties zugreifen.

MT 07-01.10



7 Auswahl der Varianten, Vorschläge Dieses Dokument liefert Implementierungsvorschläge für verschiedene Produkte und Projekte.

Wie in der Themeneingabe für die MT07-01.10 beschrieben [13], umfasst die Thesis neben dem Prototypen auch eine Empfehlung für bestehende Produkte und Neuentwicklungen der Firma KEYMILE AG.

7.1 KEYMILE

7.1.1 Bestehende Produkte Die Firma KEYMILE migriert bestehende Produkte von vxWorks nach Linux. Da diese Produkte stabil laufen und die Portierung möglichst wenig Zeit in Anspruch nehmen soll, muss die Frage der I2C-Implementierungsart neu überdacht werden. Behält man die Configtable bei, wird nur ein kleiner Codeteil im Kernelspace benötigt (siehe Abbildung 9). Der zu verwendende Codeteil lässt sich als Kernelmodul laden. Gegen diese Variante spricht, dass auf zwei verschiedene Arten, einerseits mit dem Flattened Device Tree, andererseits mit der Configtable, die Hardware abstrahiert wird.

7.1.2 Neue Produkte In Zukunft wird die Firma KEYMILE ihre Produkte ausschliesslich auf Linux entwickeln. Aus diesem Grund ist eine Loslösung der vxWorks Konzepte anzustreben.

Zurzeit ist noch unklar, welche I2C-Bauelemente in Zukunft verbaut werden. Mit der heutigen Userspace Lösung muss die proprietäre Configtable weitergepflegt sowie Treiber für neue I2C-Devices oder Adapter für neue Masterschnittstellen selber geschrieben und getestet werden.

Das Loslösen von vxWorks Konzepten gewinnt an Bedeutung, wenn Prozessoren verschiedener Architekturen eingesetzt werden. Dank dem Einhalten von Linux Konzepten wird es zukünftig möglich sein, von NAND Flash zu booten. Ferner wird, sofern der I/O Kontroller-Treiber als Linux Kernel Treibermodul implementiert wird, die Anzahl Software-emulierter Hardware-Schnittstellen komfortabel erweiterbar. Linux bietet Bitbang Algorithmen für I2C, SPI und diverse andere Schnittstellen an, welche bei Bedarf ohne grossen Aufwand hinzugezogen werden können.

Das Risiko für die Firma KEYMILE ist somit gering. Sollte der Sprung für das I2C-Multiplexer Management im Linux Kernel nicht auf Anhieb gelingen oder sich verzögern, ist eine akzeptable Fall-Back Alternative in Form der Configtable und den Userspace Treibern verfügbar.

7.1.3 Übergangslösung Es wird eine Übergangszeit geben, in der die I2C relevanten Plattformteile sowie die neue Linux I2C-Plattform Komponente parallel gepflegt werden müssen. Sobald sich die Linux-Lösung etabliert hat, ist die Configtable Lösung als „deprecated“ zu deklarieren und - wenn immer möglich - nicht mehr weiter zu gebrauchen. Weiter soll, sobald das letzte bestehende Produkt auf Linux migriert wurde, die Configtable-basierte Lösung aus der Software-Plattform entfernt werden.

MT 07-01.10



7.2 MT 07-01.10

7.2.1 Verfolgung des Grundgedankens Der Prototyp der MT 07-01.10 soll Wegbereiter für die Lösungen zukünftiger KEYMILE Produkte sein. In einem ersten Schritt soll das Lesen und Schreiben eines EEPROMs ermöglicht werden. Hierfür wird auf der ETER1 Hardware am zweiten I2C-Controller ein EEPROM angeschlossen. Die gewonnenen Erkenntnisse sollen helfen, das I2C-Subsystem und dessen Mechanismen zu verstehen.

7.2.2 Konzept Erneute Recherchen im Internet haben ergeben, dass der Wunsch nach Multiplexer-Unterstützung im Linux Kernel nicht neu ist. Google liefert beim Suchen nach „linux i2c virtual adapter“ einen Patch von Kumar Gala. Dieser Patch ist jedoch bereits 3 Jahre alt und ist nicht mehr auf die aktuellen Kernel Versionen anwendbar.

Vor ein paar Monaten wurde diese Problematik durch Rodolfo Giometti [10] erneut aufgegriffen. Er stützt sich bei seiner Arbeit [6] auf den Ansatz von Kumar Gala, dessen Patch im März 2006 veröffentlicht wurde.

Beide Personen verfolgten die Umsetzung mit virtuellen Adaptern. Die Idee dahinter ist die Folgende:

Jedes I2C-Segment wird als unabhängiger I2C-Adapter repräsentiert. Bezogen auf die ETER1 (Abbildung 11) bedeutet dies, dass der physikalische I2C-Controller um acht virtuelle I2C-Controller erweitert wird (der verwendete Multiplexer PCA9547 besitzt acht Kanäle). Abbildung 12 zeigt die neue Aufteilung der Segmente.

Jeder Kanal des I2C-Multiplexers hat im Prinzip die Funktion eines herkömmlichen I2C-Adapters. Jeder Kanal wird also als eigenständiger „I2C-Kontroller“ angesehen und auch so im sysfs abgebildet.

Am Beispiel der Zielhardware für die MT 07-01.10 bedeutet dies konkret:

Abbildung 11: Abstrahierte I2C Topologie auf dem Entwicklungs-Zielsystems

MT 07-01.10



Abbildung 12: I2C-Topologie mit den physikalischen und virtuellen Adaptern

7.2.3 Userspace Schnittstelle Sysfs Im sysfs werden die Adapter gemäss Linux Konvention mit den Namen i2c-<nr> folgendermassen aufgeführt, wobei <nr> der Segmentnummer entspricht.

Listing 5: Auflistung der I2C-Adapter im sysfs

ls /sys/class/i2c-adapter

i2c-0 i2c-1 i2c-2 i2c-3 i2c-4 i2c-5 i2c-6 i2c-7

i2c-8 i2c-9

Der physikalische Adapter i2c-0 listet zusätzlich zu seinen direkten Slave Komponenten für jeden Multiplexerkanal einen virtuellen Adapter (i2c-1 … i2c-8) auf.

Der physikalische Adapter i2c-9 listet, da er nicht weiter durch einen Multiplexer aufgeteilt wird, nur die direkten Slave Komponenten auf.

Listing 6: Auflistung eines physikalischen Adapters im sysfs

ls /sys/class/i2c-adapter/i2c-0

0-0070 i2c-0 i2c-2 i2c-4 i2c-6 i2c-8 subsystem

device i2c-1 i2c-3 i2c-5 i2c-7 name uevent


9-0048 9-0050 9-0051 9-0052 9-0053 device i2c-9

name subsystem uevent

Virtuelle Adapter listen nur ihre direkten Slave-Komponenten auf.

Listing 7: Auflistung eines virtuellen Adapters im sysfs


2-004f 2-0050 2-0051 2-0052 2-0053 device i2c-2

name subsystem uevent

MT 07-01.10



Jeder Client wird im sysfs durch ein Directory repräsentiert, dessen Name sich gemäss Linux Konvention folgendermassen zusammensetzt: <AdapterNbr>-<i2c-address>

Listing 8: Auflistung aller I2C-Clients im sysfs

ls /sys/bus/i2c/devices/

0-0070 1-0050 1-0051 1-0052 1-0053 2-004f 2-0050

2-0051 2-0052 2-0053 3-0048 3-0049 3-004a 3-004b

9-0048 9-0050 9-0051 9-0052 9-0053

7.2.4 Userspace Schnittstelle /dev Aus dem Userspace kann über einen Adapter auf I2C-Devices zugegriffen werden. Dafür muss das Kernelmodul i2c-dev geladen werden. Jeder registrierte Adapter bekommt eine Nummer, beginnend mit 0. In sys/class/i2c-dev kann eingesehen werden, welche Nummer mit welchem Adapter korrespondiert.

Die I2C-Device Files sind Character Device Files mit der Major Device Number 89 und der Minor Device Number, welche der oben erklärten Adapter-Nummer entspricht. Die Gerätedateien sollen gemäss Linux Konvention „i2c-%d“ (i2c-0, i2c-1 … i2c-255) genannt werden. Alle 256 Minor Nummern sind für I2C-Devices reserviert.

7.2.5 Hürden Rodolfo Giomettis Implementierungsvorschlag ist in einem separaten Kernel Tree [6]. Der Hauptgrund, weshalb sein Vorschlag nicht in den offiziellen Kerneltree einfliesst, ist vorrangig auf das veraltete I2C-Treibermodell zurückzuführen.

Zurzeit laufen Anstrengungen, um das I2C-Subsystem auf das aktuelle, „Neue Gerätemodell“ [11] zu portieren. Dieses Projekt leitet der Linux I2C Subsystem Maintainer, Jean Delvare [13].

7.2.6 Userspace

7.2.6.1 Linuxi2c Team Die Userspace-Zugriffsmethoden sollen wiederverwendbar und an einem Ort auffindbar sein.

Dies kann durch die Verwendung des KEYMILE Design Patterns „Team“ gewährleistet werden.

Ein Team ist eine Sammlung von Methoden, auf welche über eine „Service Fassade“ zugegriffen wird. Zudem beinhaltet dieses Pattern das Stimuli Framework, welches es ermöglicht, Methoden direkt über das Terminal auszuführen.

Detailliertere Informationen zum Team Design Pattern ist in [9] zu finden.

MT 07-01.10



7.2.6.2 I2C-Services und Stimuli Der Zugriff auf I2C Hardware erfolgt über Services. Um die Funktionalität dieser Services demonstrieren zu können, werden Stimuli in folgender Hierarchie bereitgestellt:

linuxi2c

`-ivm

`-dump

`-show hwkey

`-show boarded

`-eeprom

`-dump

`-erase

`-export

`-temp

`-show

`-show threshold

`-set threshold

Nachfolgend wird erläutert, welchen Output die einzelnen Stimuli erzeugen.

7.2.6.2.1 Alle Daten aus dem Inventory EEPROM auslesen Mit dem Stimulus: linuxi2c ivm dump <filepath>

soll der Inhalt des IVM EEPROMs in Tabellenform auf das Terminal ausgegeben werden. Board Id: Nummer

Hardware Key: Nummer

Symbol: NAMEx

Short Name: Beschreibung des Symbols

Manufacturer ID: Nummer

Manufacturer Serial Nbr: Nummer

Manufacturer Part Nbr: Nummer

Manufacturer Build State: String

Manufacturing Date: yyWww

Supplier Part Nbr: Nummer

Supplier Build State: String

7.2.6.2.2 Hardware Key aus dem Inventory EEPROM auslesen

Mit dem Stimulus: linuxi2c ivm show hwkey <filepath>

soll der Wert des Hardware Keys auf das Terminal ausgegeben werden.

7.2.6.2.3 Board Id aus dem Inventory EEPROM auslesen

Mit dem Stimulus: linuxi2c ivm show boardid <filepath>

soll die Board Id auf das Terminal ausgegeben werden.

MT 07-01.10



7.2.6.2.4 EEPROM auslesen

Mit dem Stimulus: linuxi2c eeprom show dump <filepath>

soll der Inhalt des IVM EEPROMs in Tabellenform auf das Terminal ausgegeben werden: 0 7 8 f 10 17 18 1f 20 27 28 2f 30 37 38 3f

1 -------- -------- -------- -------- -------- -------- -------- --------

2 -------- -------- -------- -------- -------- -------- -------- --------

3 -------- -------- -------- -------- -------- -------- -------- --------

4 -------- -------- -------- -------- -------- -------- -------- --------

5 -------- -------- -------- -------- -------- -------- -------- --------

6 -------- -------- -------- -------- -------- -------- -------- --------

7 -------- -------- -------- -------- -------- -------- -------- --------

8 -------- -------- -------- -------- -------- -------- -------- --------

Sonder- und Steuerzeichen werden als Minus (-) Zeichen dargestellt.

7.2.6.2.5 EEPROM Inhalt exportieren Der Stimulus linuxi2c eeprom export <src-filepath> <dst-filepath>

exportiert den Inhalt eines EEPROMs in ein File. Dieser Stimulus soll auch für den Import funktionieren.

7.2.6.2.6 Temperatur anzeigen Mit dem Stimulus: linuxi2c temp show <filepath>

soll die momentane Temperatur auf dem Terminal angezeigt werden.

7.2.6.2.7 Temperatur Threshold setzen Mit dem Stimulus: linuxi2c temp set threshold <value> <filepath>

soll der Temperatur-Threshold gesetzt werden.

7.2.6.2.8 Temperatur Threshold anzeigen Mit dem Stimulus: linuxi2c temp show threshold <filepath>

soll der momentane Temperatur-Threshold auf dem Terminal angezeigt werden.

MT 07-01.10



7.2.6.3 I2C-Service API

7.2.6.3.1 EEPROM Zugriffsfunktionen BTXCode eraseEeprom(const char* path);

Löscht den Inhalt eines EEPROMs.

BTXCode exportEeprom(const char* srcPath, const char* dstPath);

Kopiert den Inhalt eines EEPROMs in ein File.

BTXCode dumpEeprom(char* buff, const char* path);

Liest den Inhalt eines EEPROMs und übergibt ihn in einem char-Buffer.

7.2.6.3.2 IVM Zugriffsfunktionen BTXCode getIvmHwKey(int &hwKey, const char* path);

Gibt den Hardware Key aus dem Inventory EEPROM zurück.

BTXCode getIvmBoardId(int &boarded, const char* path);

Gibt die Board Id aus dem Inventory EEPROM zurück.

7.2.6.3.3 Temp-Sensor Zugriffsfunktionen BTXCode getTemp(int &deg, int &tenth, const char* path);

Liest die Temperatur aus dem Sensor aus und liefert diese in Grad Celsius und Zehntelgrad Celsius zurück.

BTXCode getTempThreshold(int &deg, int &tenth, const char* path);

Liest den Temperatur Threshold aus dem Sensor aus und liefert diesen in Grad Celsius und Zehntelgrad Celsius zurück.

BTXCode setTempThreshold(const int deg, const int tenth, const char*

path);

Setzt den Temperatur Threshold des Sensors.

7.2.6.3.4 Hilfs-Zugriffsfunktion BTXCode getFileSize(int &size, const char* path);

Ermittelt die Grösse eines Files bzw. eines EEPROMs in Bytes und gibt diese zurück.

MT 07-01.10



8 Abkürzungen, Begriffe und Namen BLOB Binary Large Object BSP Board Support Package, Low-Level Software, verantwortlich für den Bootprozess CUnit Framework für Regression Test con C/C++ code. (www.xunit.net) COBUX Name einer UMUX Baugruppe, Zentralkarte DDD Data Display Debugger, grafische Unterstützung des GDB DSL Digital Subscriber Line DTB Device Tree BLOB (� BLOB) DTC Device Tree Compiler DTS Device Tree Source(- File) DENX Firma in München, Wolfgang Denk und Detlev Zundel Doxygen Software Dokumentations-Werkzeug EEPROM Electrically Erasable Programmable Read-Only Memory ELDK Embedded Linux Development Kit ETER1 Name einer UMUX-Baugruppe, auf welcher das I2C-Framework entwickelt wird EOL End Of Line (CR / CR-LF) FS Filesystem FTTx Fiber To The x, x=(Building, Home …) GCC GNU C Compiler GDB GNU Debugger GIT Versionskontrollsystem für die Verwaltung des Linux-Kernels GPIO General Purpose Input/Output GPL GNU Public License I2C Inter Integrated Circuits IVM Inventory Management Mux Multiplexer OF Openfirmware PBEC PowerQUICC Board Embedded Controller PIGGY Aufsteckbares Board mit Debug Schnittstellen für CPUs MPC8xx und MPC82xx PIGY2 Wie PIGGY, für Prozessoren der Familie PowerQUICC II Pro (MPC83xx) prod-docs KEYMILE Dokumenten-Ablage System QUICC Quad Integrated Communication Controller RAM Random Access Memory ROM Read-Only Memory SAMUX Generische Applikationssoftware für UMUX Baugruppen SAKEY Generische Applikationssoftware für Milegate Baugruppen SCL Serial Clock Line SDA Serial Data Line SIV Abteilung in der KEYMILE, System Integration and Verification SVN Subversion, Versionskontrollsystem für die Applikationen der Firma KEYMILE sysfs sys Filesystem syslog sys-Logfile UCST UMUX Configuration Software Tool UMUX Universal Multiplexer, Multiservice Platform, Produkt der Firma KEYMILE

MT 07-01.10



9 Illustrationsverzeichnis Abbildung 1: Aufbau des I2C-Subsystems (Kernel 2.6.29) .................................................... 7

Abbildung 2: I2C-Topologie auf der ETER1 P1A ................................................................... 8

Abbildung 3: I2C-Topologie auf der ETER1 P1A ................................................................... 9

Abbildung 4: I2C-Topologie auf dem Entwicklungs-Zielsystems............................................ 9

Abbildung 5: Beschreibung der I2C-Beschaltung mit der Configtable unter vxWorks ...........10

Abbildung 6: Aus der Device Tree Source resultiert ein BLOB .............................................12

Abbildung 7: I2C-Framework ausschliesslich im Linux Kernel ..............................................15

Abbildung 8: I2C-Framework ausschliesslich im Userspace.................................................16

Abbildung 9: UIO Modell.......................................................................................................16

Abbildung 10: Allgemeine Einbettung des I2C-Frameworks .................................................20

Abbildung 11: Abstrahierte I2C Topologie auf dem Entwicklungs-Zielsystems .....................22

Abbildung 12: I2C-Topologie mit den physikalischen und virtuellen Adaptern ......................23

10 Verzeichnis der Listings Listing 1: Root Knoten ..........................................................................................................12

Listing 2: Properties und Kind-Knoten ..................................................................................12

Listing 3: Auszug aus DTS File für die I2C-Beschreibung.....................................................14

Listing 4: Mögliche File-Struktur des sysfs............................................................................15

Listing 5: Auflistung der I2C-Adapter im sysfs ......................................................................23

Listing 6: Auflistung eines physikalischen Adapters im sysfs ................................................23

Listing 7: Auflistung eines virtuellen Adapters im sysfs.........................................................23

Listing 8: Auflistung aller I2C-Clients im sysfs ......................................................................24

MT 07-01.10



11 Literaturverzeichnis [1] I2C Topologie unter vxWorks, MT 07-01.10

[2] Anforderungen an I2C unter Linux MT 07-01.10

[3] Kunst/Quade, Linux-Treiber entwickeln, 2. Auflage 2006, dpunkt Verlag, ISBN 3-89864-392-1

[4] Kern-Technik, Linux Magazin 11/07, Linux New Media AG Verlag

[5] Linux Kernel Documentation, powerpc/booting_without_OF.txt

[6] git://git.enneenne.com/linux-i2c-mux

[7] Linux Kernel-Documentation, Kernel 2.6.30

[8] Kunst/Quade, Linux-Treiber entwickeln, 2. Auflage 2006, dpunkt Verlag, ISBN 3-89864-392-1

[9] Embedded Software Design Pattern: Team, Version PC1, 19.06.2006, KEYMILE internes Dokument

[10] Homepage Rodolfo Giometti, http://rodolfogiometti.com

[11] Chapter 14, Corbet/Rubini/Kroah-Hartman, Linux Device Drivers, 3rd Edition 2005, O’Reilly Verlag, ISBN 0-596-00590-3

[12] Linux Kernel-Documentation, Kernel 2.6.30, scheduler/sched-design-CFS.txt

[13] Themeneingabe für die Diplomarbeit MT07-01.10

[14] Homepage Jean Delvare, http://khali.linux-fr.org

12 Historie

Rev. Datum Änderung Autor

PA1 01. Mai 2009 Erstellung des Dokuments der Kapitelstruktur Ch. Herzig PA2 10. Juli 2009 Vorschläge für MT, KEYMILE und sysfs erstellt Ch. Herzig PA3 15. Juli 2009 Überarbeitung der einzelnen Kapitel Ch. Herzig PA4 05. August 2009 Redaktionelle Überarbeitung Ch. Herzig A 10. August 2009 Stimuli Interface und API Definition Ch. Herzig PB1 12. August 2009 Redaktionelle Überarbeitung Ch. Herzig B 14. August 2009 Überarbeitung nach Review Befund Reufer/Zaugg Ch. Herzig

Documents

Vorschlag für die I2C Implementierung unter Linuxstatic.sws.bfh.ch/download/MAS-07-01-10-spec.pdf · 4.1.1 Abstrahierung im sysfs ... Will der Prozessor die IVM-Daten aus dem IVM-EEPROM