Outside the Walled Garden

Mit dem funktionierenden USB-Device-Controller des Oyo, wird es nun möglich auch ohne Löterei Verbindung zum Gerät aufzunehmen.

Der Linux-Kernel bietet verschiedene Gadget-Treiber dafür an. Die original-Firmware des Oyo verwendete zum Beispiel g_serial um eine serielle Konsole zur Verfügung zu stellen.

Eine deutlich bessere Alternative stellt aber das sogenannte gadget-Ethernet dar. Dies ermöglicht es, über die USB-Verbindung eine echte Netzwerkverbindung zu leiten. Das heißt das Gerät kann dann darüber auch auf das Internet zugreifen und ist gegebenenfalls per SSH zu erreichen.

Um dies aber zu ermöglichen sind sowohl auf Geräte- als auch auf Hostseite einige Einstellungen notwendig. Meine weiteren Ausführungen beziehen sich wie immer nur auf Debian-Systeme. Natürlich funktioniert das Gadget-Ethernet auch auf anderen Distributionen, nur die umzulegenden Schalter sind eben andere.

Die Geräteseite

Das entsprechende Modul muss eingebunden werden. Idealerweise erfolgt dies über einen Eintrag in der /etc/modules so ähnlich wie folgender:

# USB RNDIS/Ethernet Gadget
g_ether

Anschliessend muss noch das Netzwerkinterface konfiguriert werden. Wichtig ist, dem Eintrag in die resolv.conf noch eine funktionierende Nameserver-IP zu verpassen. Die gateway-Einstellung sorgt dabei dafür, allen Netzwerkverkehr in entfernte Netze über den Host-Rechner zu leiten.

# Ethernet/RNDIS gadget (g_ether)
# ... or on host side, usbnet and random hwaddr
auto usb0
iface usb0 inet static
        address 192.168.0.202
        netmask 255.255.255.0
        network 192.168.0.0
        gateway 192.168.0.200
        up echo nameserver IP_EINES_DNSSERVERS > /etc/resolv.conf

Die Host-Seite

Wenn alles funktioniert, sollte mit den soeben getaetigten Einstellungen folgende Meldungen, je nach Gerät in leicht abgewandelter Form, erscheinen - bzw. in den Kernelmeldungen auftauchen, wenn das Gerät mit dem Host-Rechner verbunden wird:

usb 1-1.3: new high speed USB device using ehci_hcd and address 12
usb 1-1.3: New USB device found, idVendor=0525, idProduct=a4aa
usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 1-1.3: Product: CDC Composite Gadget
usb 1-1.3: Manufacturer: Linux 2.6.37-g7d05d13 with fsl-tegra-udc
cdc_ether 1-1.3:1.0: usb0: register 'cdc_ether' at usb-0000:00:1a.7-1.3, CDC Ethernet Device, fe:23:bd:de:77:ec

Nun fehlt nur noch ein entsprechendes Netzwerkinterface auf der Host-Seite. Dies lässt sich zum Beispiel durch folgende Zeilen in der /etc/network/interfaces bwerkstelligen:

#allow-hotplug usb0
iface usb0 inet static
 address 192.168.0.200
 netmask 255.255.255.0
 network 192.168.0.0
 up iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24 &
 up echo 1 > /proc/sys/net/ipv4/ip_forward &
 up iptables -P FORWARD ACCEPT &
 down iptables -D POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24 &

Das allow-hotplug kann ggf. auskommentiert werden und sollte hoffentlich dafür sorgen, dass das Interface automatisch eingerichtet wird, wenn das Gerät angesteckt wird.

Die »up ...«-Kommandos sorgen dabei dafür, dass der Host ankommende Anfragen gegebenenfalls über sein Nezwerkinterface weiterreicht und Antworten darauf wieder dem Gerät zukommen lässt.

So wie es aussieht hat mein kleiner Fix des S3C-ADC-Battery-Treibers seinen Weg in den offiziellen Kernel geschafft.

Ich bin jetzt also für immer in der History der Kernel-Enwicklung verewigt .

Gestern Abend hat Marc seine Kernelbasteleien zum AC100 auf einen aktuelleren Kernel portiert - den 2.6.37 aus dem ChromeOS-Projekt.

Ich musste das heute natürlich gleich ausprobieren, und siehe da sogar meine KDE läuft jetzt scheinbar stabil. Diesen Beitrag schreibe ich zur Feier des Tages auch gleich mal direkt auf dem AC100.

Kleine Bestandsaufnahme:

• Basissystem + Framebuffer-X11 läuft.
• Tastatur funktioniert und tippt sich ganz angenehm. Nur das Layout der Sondertasten ist gewöhnungsbedürftig
• Maus geht auch, nur selten treten Ruckler auf
• WLAN versuchte sich zwar zu verbinden, hat aber noch nicht geklappt

Der AC100 ist also schon relativ gut nutzbar, wenn man WLAN nicht unbedingt benötigt, sondern z.B. auch Usb-Ethernet nutzen kann.

... Einen riesigen, stinkenden, schwitzenden Elch.

Der Elch ist in diesem Fall der USB-Device-Controller und dieses Zitat aus dem ersten Turtles-Film beschreibt recht gut das Gefühl des Triumphs, dass mich gerade befällt.

Es ist also soweit — der USB-Device-Controller funktioniert jetzt auch auf meinem intakten Oyo.

Hintergründe

So wie es aussieht ist mein Bastel-Oyo eins der berüchtigten Montagsmodelle. Das Problem dabei ist, dass der Device-Controller scheinbar immer mitläuft ohne vorher explizit aktiviert werden zu müssen. Dies führt zum einen dazu dass der UDC gestern bei mir funktionierte, andererseits wird dadurch aber auch kontinuierlich Strom verbraucht, was zu den teilweise gravierenden Unterschieden der Laufzeit zwischen verschiedenen Geräten führen könnte.

Ich habe heute also nichts weiter gemacht, als die beiden GPIOs GPH14 und GPD13 zu aktivieren — genauso wie es im originalen Kernel geschieht.

Zuvor musste ich aber erstmal feststellen, dass die Menge an GPH-GPIOs zu klein definiert war. Es scheint so, dass alle Prozessoren vor dem S3C2416 nur 11 GPIOs im GPH-Bereich unterstützen, sodass er meine Anfragen für den GPH14 konsequent ignoriert hat. Das heißt dort war auch noch eine kleine Änderung an der Menge der nutzbaren GPIOs notwendig.

Hier also der Tipp aus leidvoller Erfahrung: immer schön den Rückgabewert von gpio_request() überprüfen, dann fallen solche Probleme viel zeitiger auf

Nächste Schritte

Da nun der UDC, wie auf dem fehlerhaften Oyo, immer mitläuft, ist der nächste Schritt diesen nur zu aktivieren wenn eine Verbindung besteht und nach deren Ende den UDC wieder zu deaktivieren.

Der Weg dahin führt über den gpio_vbus-Treiber, der sich darum kümmert Änderungen dieses Signals zu bearbeiten. Momenten kann er zwar noch nicht Dinge ein- bzw. ausschalten, aber das ist ja nicht so schwer .

Irgendwann wäre auch noch zu prüfen, ob wirklich beide GPIOs notwendig sind, bzw. wofür sie eigentlich dienen.

Nach langen Mühen, vielen Flüchen und noch viel mehr unterschiedlichen Versuchen habe ich heute den UDC zum Laufen bekommen.

Man kann nun also den Oyo wieder als Massenspeicher nutzen oder ihn wahlweise als pseudo-Ethernetgerät ansprechen. Die zweite Variante ist für Entwickler ohne gute Lötfähigkeiten sogar sehr wichtig, da es damit möglich wird, den Oyo per SSH anzusprechen und damit keine serielle Konsole mehr notwendig ist.

Und wer war schuld? Der gemeine Nullpointer.

Der Übeltäter

Der USB-Interrupt wurde aktiviert bevor die sogenannten Endpunkte initialisiert wurden. Scheinbar ging bei dem ursprünglichen Entwickler alles gut sodass das Problem gar nicht auffiel.

Beim Oyo-Start wird aber scheinbar sofort dieser Interrupt ausgelöst. Das führt dazu, dass der Interrupt-Handler auf die Endpunkt-Daten zugreifen möchte, deren Zeiger aber ins Leere zeigt, was wiederum zu einem Kernel-Oops führt.

Die Lösung ist einfach, das Aktivieren des Interrupts etwas später zu tun - also den Code etwas nach unten zu schieben:

diff --git a/drivers/usb/gadget/s3c-hsudc.c b/drivers/usb/gadget/s3c-hsudc.c
index b98d8a1..a3f2fbf 100644
--- a/drivers/usb/gadget/s3c-hsudc.c
+++ b/drivers/usb/gadget/s3c-hsudc.c
@@ -1248,19 +1248,6 @@ static int s3c_hsudc_probe(struct platform_device *pdev)
 		goto err_remap;
 	}
 
-	ret = platform_get_irq(pdev, 0);
-	if (ret < 0) {
-		dev_err(dev, "unable to obtain IRQ number\n");
-		goto err_irq;
-	}
-	hsudc->irq = ret;
-
-	ret = request_irq(hsudc->irq, s3c_hsudc_irq, 0, driver_name, hsudc);
-	if (ret < 0) {
-		dev_err(dev, "irq request failed\n");
-		goto err_irq;
-	}
-
 	spin_lock_init(&hsudc->lock);
 
 	device_initialize(&hsudc->gadget.dev);
@@ -1278,6 +1265,19 @@ static int s3c_hsudc_probe(struct platform_device *pdev)
 
 	s3c_hsudc_setup_ep(hsudc);
 
+	ret = platform_get_irq(pdev, 0);
+	if (ret < 0) {
+		dev_err(dev, "unable to obtain IRQ number\n");
+		goto err_irq;
+	}
+	hsudc->irq = ret;
+
+	ret = request_irq(hsudc->irq, s3c_hsudc_irq, 0, driver_name, hsudc);
+	if (ret < 0) {
+		dev_err(dev, "irq request failed\n");
+		goto err_irq;
+	}
+
 	hsudc->uclk = clk_get(&pdev->dev, "usb-device");
 	if (hsudc->uclk == NULL) {
 		dev_err(dev, "failed to find usb-device clock source\n");

Der Unschuldige

Die ganzen verschwurbelten Änderungen im 2.6.21er Hersteller-Kernel waren gar nicht für unsere Problem verantwortlich. Vermutlich wird auch nie jemand herausfinden wozu sie eigentlich dienten.