# embedded-gentoo auf einer Linksys NSLU2

## chilla

Linksys, eine Tochterfirma von Cisco Systems hat vor einiger Zeit ein kleines Maschinchen basierend auf der embedded-arm Architektur herausgebracht, welches sich "NSLU2" nennt. Darauf lässt sich mit Sicherheit wunderbar ein Gentoo zum Laufen bringen. Dies möchte ich versuchen und hier dokumentieren.

Features: Gerade mal ein bisschen kleiner als eine 3,5" Festplatte

 100mbit Netzwerkschnittstelle

 2 USB-Ports

 266 mhz Prozessor

 8 mb Flashspeicher

 32 mb SD-Ram

 Unschlagbarer Preis von gerade mal 75

 Sieht nicht schlecht aus

Bild des Geräts | Bild der Platine | Detailliertes Bild der Platine

Linksys liefert das gerät mit einem 2.4er kernel, Samba und einem entsprechenden Webinterface aus, damit man USB-platten anschliessen kann, und diese per Webinterface-konfiguration über den Samba im Netzwerk freigeben kann. Das ist zwar schön, reicht mir jedoch nicht. Ich will eine vollwertige Distribution darauf. Somit habe ich den Thread hier gestartet um gentoo darauf zum laufen zu bekommen, dies zu Dokumentieren, euch Fragen zu stellen, und schliesslich zu vesuchen, eine Schritt für Schritt Dokumentation für alle gentoo-user hier im Forum, im gentoo-wiki, oder auf den webseiten des embedded-gentoo projektes zur verfügung zu stellen. Ich hoffe, dass sich hier ein paar Leute finden, die selbst daran interessiert sind, gentoo darauf zum laufen zu bekommen  :Smile: 

Hier im Startthread sammle ich Arbeitsschritte und Informationen. Ich werde sie wahrscheinlich nicht sofort beim posten ausformulieren, werde mir jedoch Mühe geben, zumindest halbwegs verständlich zu sein. Früher oder später werde ich das ganze mit ssicherheit mal ausformulieren.

Das Gerät:

- Die CPU:

Die NSLU2 wird mit einem Intel IXP420 als Prozessor ausgelifert. Der XScale-Kern basiert auf der ARMv5TE Architektur und ist auf 266Mhz ausgelegt. Nichts desto trotz wird er in diesem Gerät nur mit 133 getaktet. Durch eine sehr einfache Modifikation kann man den Prozessor "deunderclocken". Wie man es anstellt ist hier zu sehen.

- Speicher:

Die CPU ist angeschlossen an 8mb Flash-Speicher(0x50000000 - 0x50800000) Die 8MB Flash sind folgendermaßen aufgebaut: Start: 0x50000000, Länge: 0x40000 (256K) - der Bootcode

 Start: 0x50040000, Länge: 0x20000 (128K) - Systemkonfiguration (ich glaube für den bootmanager)

 Start: 0x50060000, Länge: 0x100000 (1MB) - Platz für den Kernel

 Start: 0x50160000, Länge: 0x6A0000 (6.625MB) - Das /-Dateisystem 

Zudem gibt es 32MB SD-Ram, die unter folgender Adressspanne erreichbar sind: 0x00000000 bis 0x02000000. Es gibt die Möglichkeit, von ganz normalen SD-Ram Modulen, die Bausteine zu nutzen um damit den Speicher der NSLU2 aufzurüsen. Wie dies geht, sehr ihr hier.

- USB-Controller:

Das Gerät selbst hat 2 USB-Ports nach außen laufen. Der USB-Controller meldet sich in lspci als "USB Controller: NEC Corporation USB 2.0 (rev 04)"und wird problemlos von ohci/uhci unterstützt. Problemlos lässt sich auch ein aktiver USB-Hub anschliessen - aktiv daher, weil ich nicht glaube, dass der eigene USB der NSLU2 genügend Strom für viele Geräte liefert. 

Getestet habe ich den USB-Controller bisher mit 4 Festplatten im USB-Gehäuse und einem RFID-Reader welcher an einem Serial2USB-Converter hängt. Alles lief Problemlos, auch gleichzeitig.

- Netzwerk:

Die Netzwerkschnittstelle wird direkt vom Prozessor bereitgestellt, und basiert damit auf dem IXP420 Chip, zu welchem man hier genauere Informationen findet. der Proprietäre Treiber dafür ist in Portage vorhanden und kann gegen den 2.6er Kernel gebaut werden. 

- Bootloader:

Ausgeliefert wird das Gerät mit dem Bootloader namens "RedBoot". Dieser genügt auch für unsere Zwecke und wir lassen ihn drauf. Obgleich es möglich ist, diesen durch den APEX Bootloader zu ersetzen.

Gentoo installieren:

Auf los gehts los  :Smile: 

Wir brauchen ein Installationssystem

Die Maschine in den Updatemodus bringen

upslug2 emergen und testen

Openslug installieren

Gentoo Stage3 auf eine Festplatte

Festplatte einrichten

Stage-tarball herunterladen und entpacken

Portagesnapshot herunterladen und entpacken

chrooten

Portage-tree snchronisieren

Profil auswählen und testen

Arm-Profil verlinken

linux-headers updaten

screen emergen

Einrichten einer Crosscomplile-Umgebung

Crossdev emergen

Stage4 umgebung für die Target-Architektur einrichten

Kernel installieren

Kernelquellen besorgen

Kernel patchen

Cross-kompilieren

Module auf die NSLU übertragen

Kernelimage bearbeiten

Netzwerktreiber crossscompilen

Nötige Systemtools installieren und Konfigurationen bearbeiten

Devfs raus, udev rein!

Systemlogger

Cron

Netzwerkconfiguration

/etc/fstab editieren

/etc/conf.d/* editieren

 Kernelimage auf die NSLU übertragen und rebooten

Anmerkung 1: Keine Garantie, kein Garnichts! Es ist euer Gerät und euer Bier, was ihr damit macht! Mit dem, was ich euch hier beschreibe, könnt ihr _nichts_ kaputt machen und ihr könnt alles wieder rückgängig machen: wenn die original Linksysfirmware wieder aufgespielt wird, könnt ihr das Gerät sogar zurückgeben. Dannn gilt jedoch: Finger weg vom Deunderclocken, Finger weg vom Bootloader, Finger weg von der Platine! Wer jetzt noch weiterliest: viel Spaß  :Smile:   

Anmerkung 2: Das Howto schliesst zwar im Großen und Ganzen alles ein, jedoch ist es nicht vollständig. Copy&Paste funktioniert also _nicht_! Ich werde es weiter korrigieren und verbessern, Grundkenntnisse und Verständnis sollten jedoch bei jedem zu genüge vorhanden sein, der die Absicht hat, sich an diesem Howto zu orientieren.

Wir brauchen ein Installationssystem

Linksys liefert die Maschine zwar mit einem 2.4er Linux aus, dieses ist jedoch nicht ausreichend um von dort aus Gentoo zu installieren (kein ssh, nicht alle Werkzeuge etc.). Also müssen wir uns eines besseren bedienen, damit wir ein Grundsystem haben, womit wir eine Festplatte partitionieren können, den Stage-tarball herunterladen und entpacken können, sowie einige Dateien editieren können und schliesslich in unser neues Root-System chrooten. 

Hierfür benutzen wir die Distribution Openslug, welche komplett auf den Flash-speicher passt. 

Die Maschine in den Updatemodus bringen

Zuerst sollten wir überprüfen, ob das Gerät überhaupt funktioniert. Dafür verbinden wir es mit unserem Switch und schalten es ein, ohne dabei irgendwelche Festplatten oder sonstiges angeschlossen zu haben. Wenn nach ca 1-2 Minuten die Ready/Status Lampe auf Grün wechselt, und wir das Gerät anpingen können, oder sogar auf das Webinterface (IP steht in der Dokumentation) kommen, ist schon alles geritzt und wir können wieder getrost den Stecker ziehen. 

Nun bringen wir das Gerät auf folgendem Weg in den Update-Modus:

Darauf achten, dass nichts ausser dem Netzteil und einem Netzwekkabel angeschlossen ist

Mit einem Kugelschreiber oder sonstigem an der Hinterseite das Reset-knöpfchen drücken und weiterhin gedrückt halten.

Nun auf der Vorderseite den Power-on-button einmal drücken (den Reset-knopf weiterhin gedrückt halten)

Nach ca. 10 Sekunden, sofort in dem Moment, wo die Ready/Status-Lampe auf Rot wechselt - den Reset-knopf loslassen. Dafür hast man ca. eine halbe Sekunde Zeit, danach ist es schon zu spät. 

Wenn die Ready/Status-Lampe abwechselnd Rot und Grün blinkt, befindet sich die NSLU im Update-Modus. 

upslug2 emergen und testen

Um die NSLU mit einer anderen Firmware zu bestücken, benötigen wir das tool Upslug2.  Mike Frysinger vom embedded-gentoo Projekt hat dieses Tool bereits in Portage gestellt, somit können wir es bequem auf unserem Arbeitsplatzrechner, von dem aus wir die Gentoo-installation betreuen installieren:

```
[13:57:39]|[chilla@chucky]|~/nslu/openslug-bin$ sudo emerge upslug2
```

Vorrausgesetzt, die NSLU ist im Upgrademodus und hängt im gleichen Supnetz wie wir und hat entsprechend keinen IP-Konflikt etc. können wir sie sehen, indem wir nach der Installation auf unserem Arbeitsplatzrechner ein simples "upslug2" in die shell werfen. Die Ausgabe sollte wie folgt aussehen:

```
[13:40:26]|[chilla@chucky]|~$ upslug2

NSLU2     00:13:10:d6:1d:f2 Product ID: 1 Protocol ID: 0 Firmware Version: R23V29 [0x2329]
```

Damit wissen wir, dass die NSLU im Upgrademodus ist und unser upslug2 funktioniert. Ausserdem wissen wir die MAC-Addresse der NSLU, welche wir benötigen um die Firmware zu flashen. 

Achtung: Dieser Output erscheint NUR, wenn die originale Linksysfirmware noch installiert ist. Sobald mal ein anderer Kernel drauf ist, findet man die NSLU nicht mehr auf diese weise. Schreibt euch also die MAC-Adresse auf (alternativ steht sie auch nochmal auf der Unterseite des Geräts aufgedruckt)

Openslug installieren

Nun, da das Maschinchen im Upgrade-Modus ist und unser upslug2 funktioniert, können wir Openslug auf dem zielsystem installieren. Dazu holen wir uns das binäre Image von Openslug und flashen es mittels upslug auf das Zielsystem. (Nach wie vor dürfen noch keine anderen Geräte an das Gerät angeschlossen sein!) Danach bootet das Gerät automatisch durch und wir können uns per SSH einloggen:Openslug hier herunterladen.entpacken:

```
[13:57:39]|[chilla@chucky]|~/nslu/openslug-bin$ unzip OpenSlug-2.7-beta-firmware.zip
```

Auf das Zielsystem übertragen:

```
[13:57:39]|[chilla@chucky]|~/nslu/openslug-bin$ upslug2 --target=00:13:10:d6:1d:f2 --image=openslug-2.7-beta.bin
```

Wenn alles geklappt hat, bootet die NSLU nun automatisch neu. Falls ihr einen dchp-Server im Netzwerk habt, bekommt sie nun von diesem eine. Ansonsten sollte die IP 192.168.1.77 sein. Was nun wirklich die IP der NSLU ist verrät uns ein Blick auf

```
ping -b 192.168.1.255
```

Schliesslich loggen wir uns auf dem Zielsystem ein (das standard-root-pw lautet "opeNSLUg") und initialisieren es: 

```
ssh root@192.168.1.77
```

Und initialisieren das Grundsystem:

```
turnup init
```

Der command "turnup init" fragt uns nach einigen Einstellungen, die wir setzen möchten - erklärt sich eigentlich alles von alleine. 

  Nun rebooten wir die NSLU nocheinmal - wenn wir uns danach mit dem (bei "turnup init" gesetzten) Rootpasswort unter der eingestellten IP einloggen können, hat alles geklappt und wir sind mit der Installation von Openslug fertig. Von hier aus können wir gentoo installieren. 

Gentoo Stage3 auf eine Festplatte

Die folgenden Schritte sind eigentlich in der offiziellen offiziellen Gentoo-installations-doku besser und ausführlicher beschrieben als hier. Der Vollständigkeit halber und da ich ein anderes Stage-tarball verwende, schreibe ich sie hier trotzdem nieder.

Festplatte einrichten

Nun ist es an der Zeit, eine Festplatte anzuschliessen, zu partitionieren und zu formatieren. In meinem Fall habe ich eine 200GB Platte vo Samsung in ein billiges USB-Gehäuse gesteckt, das ich für 20 bei Arlt um die Ecke gekauft habe. Die Festplatte wird angschlossen und mit dem command "dmesg" wird überprüft, ob sie richtig erkannt wurde:

```
root@sluggy:~# dmesg  

[...]

  Vendor: SAMSUNG   Model: SP2014N           Rev: 0000

  Type:   Direct-Access                      ANSI SCSI revision: 00

SCSI device sda: 390721968 512-byte hdwr sectors (200050 MB)

[...]
```

Mittels "fdisk" wird nun die Platte partitioniert. Für den Anfang erstelle ich nur eine 20GB große /-Partition und nochmal 500MB Swap. 

```
root@sluggy:~# fdisk /dev/sda 
```

Wer nicht weiss, wie das geht, kann dies hier nachschauen. 

Schliesslich sieht meine Partitionierung folgendermaßen aus:

```
root@sluggy:~# fdisk -l /dev/sda

Disk /dev/sda: 200.0 GB, 200049647616 bytes

255 heads, 63 sectors/track, 24321 cylinders

Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot    Start       End    Blocks   Id  System

/dev/sda1               1        1825    14659312   83  Linux

/dev/sda2            1826        1887      498015   82  Linux swap
```

Nun werden beide Partitionen formatiert: 

```
root@sluggy:~# mkfs.ext3 /dev/sda1

root@sluggy:~# mkswap /dev/sda2 

root@sluggy:~# swapon /dev/sda2
```

Und schliesslich erstellen wir uns einen Mount-punkt und mounten unsere zukünftige /-Partition dorthin:

```
root@sluggy:~# mkdir /mnt/gentoo

root@sluggy:~# mount -t ext3 /dev/sda1 /mnt/gentoo/
```

Stage-tarball herunterladen und entpacken

Die netten Jungs vom embedded-gentoo Projekt haben schon das schwierigste bereits für uns erledigt: Sie haben einen Stage3-Tarball für embedded-arm Systeme mit softfloat und der uclib erstellt, dessen wir uns bedienen können.  Wir befinden uns also per ssh als root auf dem Zielsystem und haben eine fertig eingerichtete und formatierte, sowie genügend große Partition nach /mnt/gentoo gemountet. Dorthin wechseln wir nun und laden uns das Stage3-Archiv von dieser Seite herunter: 

```
root@sluggy:~# cd /mnt/gentoo/

root@sluggy:/mnt/gentoo# wget http://ftp.uoi.gr/mirror/OS/gentoo/experimental/arm/embedded/stages/stage3-armeb-uclibc-softfloat-2005.1.tar.bz2

root@sluggy:/mnt/gentoo# tar xvjpf stage3-armeb-uclibc-softfloat-2005.1.tar.bz2
```

Portagesnapshot herunterladen und entpacken

Nun laden wir uns auch einen aktuellen Portage-snapshot herunter unt entpacken ihn:

```
root@sluggy:/mnt/gentoo# wget http://ftp.uoi.gr/mirror/OS/gentoo/snapshots/portage-latest.tar.bz2  

root@sluggy:/mnt/gentoo# tar xvjf portage-latest.tar.bz2 -C /mnt/gentoo/usr 
```

chrooten

Da wir nun ein Grundsystem in /mnt/gentoo liegen haben, können wir auch schon reincrhooten, nachdem wir noch einige notwendige Dinge gemountet haben:

```
root@sluggy:~# mount -o bind /dev /mnt/gentoo/dev

root@sluggy:~# mount -o bind /dev/pts /mnt/gentoo/dev/pts

root@sluggy:~# mount -t proc none /mnt/gentoo/proc

chroot /mnt/gentoo /bin/bash
```

Geschafft: wir befinden uns in Gentoo Linux auf einem embedded-arm Maschinchen  :Smile: 

Portage-tree snchronisieren

Nun synchronisieren wir noch den Portage-tree.

```
sluggy / # emerge --sync
```

Profil auswählen und testen

Das Standardprofil des benutzten Stage3-Tarballs ist ein 2.4er. Da ich aber ein 2.6er Kernel verwenden möchte, ändere ich dies um, installiere die neuen linux-headers des 2.6er kernels und emerge Screeen um das Profil zu testen

 /etc/make.conf editieren

Zuerst schaue wird nachgeschaut, was noch in der /etc/make.conf zu machen ist. Morfic hat mir seine passende make.conf gegeben und ich habe noch der Sicherheit halber (ich habe nicht in die defaults geschaut) ein paar Useflags gesetzt. Nun sieht die make.conf so aus:

```
CFLAGS="-march=armv5t -Os"

CHOST="armeb-softfloat-linux-uclibc"

CXXFLAGS="-march=armv5t -Os"

USE="-opengl -qt -gtk -gtk2 -kde -gnome -motif -X -arts -oss -alsa -esd -ipv6 apache2"
```

 Arm-Profil verlinken

Nun löschen wir den derzeitigen Link zum 2.4er Profil und verlinken unser gewünsches 2.6er Profil:

```
sluggy / # rm /etc/make.profile 

sluggy / # ln -s /usr/portage/profiles/uclibc/arm /etc/make.profile
```

 linux-headers updaten

Nun ist es notwendig, dass wir die Linux-headers updaten:

```
sluggy / # emerge -u linux-headers
```

screen emergen

Um zu sehen, ob die Einstellungen korrekt sind, und von unserem nativen gcc richtig ausführbare dateien erstellt werden, emerge ich mir screen, da ich es gerade während solcher installationen gerne verwende. 

```
sluggy / # emerge screen
```

Einrichten einer Crosscomplile-Umgebung

Die NSLU wird standardmäßig mit 133 Mhz betrieben. Das ist für heutige Verhältnisse wirklich nicht viel. Selbst wenn man die Sperre wie hier beschrieben rausnimmt, und damit den Takt auf 266Mhz anhebt (wofür der Prozessor übrigens eigentlich ausgelegt ist), hat man immernoch nicht die Performance um genussvoll mit gentoo zu arbeiten. Schon am Beispiel von screen, welches ich ein paar Zeilen weiter oben zum Testene emerged habe, hat man deutlich gesehen, wie lahm die kiste eigentlich ist. Ich werde mit Sicherheit einen großen Teil der Software nativ auf dem System emergen - dafür ist gentoo schliesslich gemacht -, aber im Moment habe ich keine große Lust drauf, so lange zu warten, bis mein Kernel gebaut ist. Zumal ich sowieso das kernelimage von außen per upslug2 wieder auf die Maschine schieben möchte. 

Also setze ich mir eine Crosscompile-umgebung auf, damit ich nachher den Kernel auf meinem schnellen Arbeitsplatzrechner bauen kann. Dies ist leichter als es sich anhört:

 Crossdev emergen

Crossdev ist ein geniales tool. Erstellt uns compiler, toolchains, uclibcs und binutils, welche auf unserem Arbeitsplatzrechner laufen, jedoch für unsere Zielarchitektiv (embedded-arm) kompilieren. Nurnochmal um sicherzugehen: Wir führen das Folgende auf unserem Arbeitsplatzrechner aus, nicht auf der NSLU! 

```
sudo emerge crossdev
```

 Stage4 umgebung für die Target-Architektur einrichten

Nun benötigen wir alles für die Kompilierung von ARM-Programmen. Falls wir es noch nicht drin haben, müssen wir folgende Zeile in die /etc/make.conf unseres Arbeitsplatzrechners eintragen:

```
PORTDIR_OVERLAY="/usr/local/portage"
```

Nun können wir ganz einfach unsere Crosscompile-umgebung erstellen:

```
[16:15:30]|[chilla@chucky]|~$ sudo crossdev armeb-softfloat-linux-uclibc 
```

Einen Kernel installieren

Jetzt gehts ans eingemachte. Einige eeigenschaften der NSLU2 sind nicht vom vanilla-kernel unterstütz, zudem verwenden wir noch die uclibc statt der glibc, da hilft nur eins: kernel patchen. Als Grundlage nutzen wir einen halbwegs aktuellen 2.6.14.3, den wir uns zu beginn von kernel.org herunterladen werden. Danach jagen wir ein paar patches drüber und cross-kompilieren ihn auf unserem Arbeitsplatzrechner. Danach wird das erstelle Kernelimage noch ein wenig bearbeitet, damit der bootloader unseres Zielsystems es laden kann, und die kompilierten Module werden auf unseren Zielrechner übertragen. Das Kernelimage wird erst ganz zum Schluss übertragen, da wir dafür die NSLU neu booten müssen. 

 Kernelquellen besorgen

Ich erstelle mir ein Arbeitsverzeichnis für die Kernel-geschichte und lade mir die 2.6.14.3er Quellen runter: 

```
[17:11:43]|[chilla@chucky]|~/nslu$ mkdir nslu2-kernel 

[17:11:43]|[chilla@chucky]|~/nslu$ cd nslu2-kernel/ 

[17:12:28]|[chilla@chucky]|~/nslu/nslu2-kernel$ wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.14.3.tar.bz2 

[17:13:50]|[chilla@chucky]|~/nslu/nslu2-kernel$ tar xjf linux-2.6.14.3.tar.bz2 
```

 Kernel patchen

Die Patches hat morfic glaube ich alle von Openslug zusammengesucht, ich habe noch einen hinzugefügt. Das gesamte paket lade ich mir runter, entpacke es und patche damit die Kernelquellen: 

```
[17:14:37]|[chilla@chucky]|~/nslu/nslu2-kernel$ wget http://chilla.biz/projekte/gentoo-slug/files/nslu2-patches-2.6.14.3.tar.bz2 

[17:16:48]|[chilla@chucky]|~/nslu/nslu2-kernel$ tar xjf nslu2-patches-2.6.14.3.tar.bz2

[17:17:11]|[chilla@chucky]|~/nslu/nslu2-kernel$ mv patches/ linux-2.6.14.3

[17:17:21]|[chilla@chucky]|~/nslu/nslu2-kernel$ cd linux-2.6.14.3

[17:17:36]|[chilla@chucky]|~/nslu/nslu2-kernel/linux-2.6.14.3$ for i in `cat patches/nslu2-patches.list` ; do patch -p1 < patches/$i ; done
```

Nun hole ich mir noch morvic's config:

```
[17:18:10]|[chilla@chucky]|~/nslu/nslu2-kernel/linux-2.6.14.3$ wget http://dev.gentoo.org/~morfic/nslu2/nslu2-2.6.14.3.config

[17:22:08]|[chilla@chucky]|~/nslu/nslu2-kernel/linux-2.6.14.3$ mv nslu2-2.6.14.3.config .config

[17:22:22]|[chilla@chucky]|~/nslu/nslu2-kernel/linux-2.6.14.3$ make ARCH=arm CROSS_COMPILE=armeb-softfloat-linux-uclibc- oldconfig dep
```

 Cross-kompilieren

Nun wird der Kernel kompiliert. Ich befinde mich die ganze Zeit auf meinem Arbeitsplatzrechner, da ich keine Lust habe, das auf der langsamen NSLU zu machen. Da ich vorhin meine Crosscompile-Umgebung mit crossdev gebaut habe, kann ich nun ganz einfach darauf zurückgreifen und den Kernel für eine andere Architektur kompilieren:

```
make ARCH=arm CROSS_COMPILE=armeb-softfloat-linux-uclibc- 
```

Damit wir die Module noch separat bekommen, erstellen wir uns dafür noch schnell ein verzeichnis und lassen uns die Module dort hineininstallieren:

```
[17:30:46]|[chilla@chucky]|~/nslu/nslu2-kernel/linux-2.6.14.3$ mkdir /home/chilla/nslu/nslu2-2.6.14.3-modules/

[17:30:54]|[chilla@chucky]|~/nslu/nslu2-kernel/linux-2.6.14.3$ make INSTALL_MOD_PATH=/home/chilla/nslu/nslu2-2.6.14.3-modules/ DEPMOD=/bin/true modules_install
```

 Module auf die NSLU übertragen

Die kompilierten module können wir schonmal packenn und auf die NSLU übertragen und nebenbei erstellen wir schonmal  das Verzeichnis, wo später das Modul für die Netzwerkschnittstelle liegt.

```
[17:44:26]|[chilla@chucky]|~/nslu/nslu2-kernel/linux-2.6.14.3$ cd ../../

[17:33:05]|[chilla@chucky]|~/nslu$ tar cjf nslu2-2.6.14.3-modules.tar.bz2 nslu2-2.6.14.3-modules 

[17:35:21]|[chilla@chucky]|~/nslu$ scp nslu2-2.6.14.3-modules.tar.bz2 root@192.168.1.77:/mnt/gentoo/root/

[17:35:40]|[chilla@chucky]|~/nslu$ ssh root@192.168.1.77

root@sluggy:~# chroot /mnt/gentoo/ /bin/bash

sluggy / # cd /root/

sluggy ~ # tar xjf nslu2-2.6.14.3-modules.tar.bz2

sluggy ~ # cp -r nslu2-2.6.14.3-modules/lib/modules/2.6.14.3 /lib/modules/

sluggy ~ # mkdir /lib/modules/2.6.14.3/kernel/drivers/ixp400/

sluggy ~ # exit

root@sluggy:~# exit
```

Damit hätten wir schon mal die Kernelmodule auf dem Zielrechner. 

 Kernelimage bearbeiten

Auch wenn das Image erst später installiert wird, so machen wir es trotzdem jetzt noch "ready to be slugged". Damit der Bootloader das image laden kann, muss es noch leicht modifiziert werden - dies erledigt ein kleines script für uns:

```
[17:51:46]|[chilla@chucky]|~/nslu$ cd nslu2-kernel/

[17:51:49]|[chilla@chucky]|~/nslu/nslu2-kernel$ wget http://dev.gentoo.org/~morfic/nslu2/prepimage

[17:56:21]|[chilla@chucky]|~/nslu/nslu2-kernel$ chmod +x prepimage

[17:55:37]|[chilla@chucky]|~/nslu/nslu2-kernel$ cp linux-2.6.14.3/arch/arm/boot/zImage .

[17:55:53]|[chilla@chucky]|~/nslu/nslu2-kernel$ ./prepimage
```

Damit haben wir nun ein Kernel-image erhalten, wechles von der NSLU2 gebootet werden kann. 

 Netzwerktreiber kompilieren

Glücklicherweise steht der Netzwertreiber in Portage. Diesen können wir bequem auf unserem Arbeitsplatz kompilieren - dort haben wir ja auch noch die kernel-sourcen abgelegt. Schliesslich schieben wir das entstandene Modul noch auf die NSLU, dann hätten wir auf Seiten des Kernels im Prinzip alles fertig. 

Aus irgendeinem Grund müssen bei mir die Kernelquellen nach /usr/src/linux gelinkt werden. 

```
[21:45:05]|[chilla@chucky]|~$ su

chucky chilla # rm /usr/src/linux
```

 Nun demaskieren wir noch den Netzwerktreiber und kompilieren ihn schliesslich:

```

chucky chilla # ln -s /home/chilla/nslu/nslu2-kernel/linux-2.6.14.3 /usr/src/linux

chucky ~ # echo "net-misc/ixp4xx arm" >> /etc/portage/package.keywords

chucky ~ # CHOST=armeb-softfloat-linux-uclibc emerge ixp4xx
```

 Nun schieben wir noch die Kernelmodule auf die NSLU:

```
chucky ~ # scp /lib/modules/2.6.14.3/kernel/drivers/net/ixp400_eth.ko root@192.168.1.77:/mnt/gentoo/lib/modules/2.6.14.3/kernel/drivers/net/ixp400_eth.ko

chucky ~ # ssh root@192.168.1.77

root@sluggy:~# mkdir /mnt/gentoo/lib/modules/2.6.14.3/kernel/drivers/ixp400/

root@sluggy:~# exit

chucky ~ # scp /lib/modules/2.6.14.3/kernel/drivers/ixp400/ixp400.ko root@192.168.1.77:/mnt/gentoo/lib/modules/2.6.14.3/kernel/drivers/ixp400/ixp400.ko
```

Netzwerktreiber crosscompilen

Ich weiss zwar nicht den Grund, doch leider lässt sich der Netzwerktreiber nicht nativ kompilieren. Daher müssen wir auch ihn auf unserem Arbeitsplatzrechner kompilieren und danach die Module auf das Zielsystem übertragen:

```

# echo "net-misc/ixp4xx arm" >> /etc/portage/package.keywords  

# CHOST=armeb-softfloat-linux-uclibc emerge ixp4xx

# scp /lib/modules/2.6.14.3/kernel/drivers/net/ixp400_eth.ko root@192.168.1.77:/mnt/gentoo/lib/modules/2.6.14.3/kernel/drivers/net/

# scp /lib/modules/2.6.14.3/kernel/drivers/ixp400/ixp400.ko root@192.168.1.77:/mnt/gentoo/lib/modules/2.6.14.3/kernel/drivers/ixp400/
```

Nötige Systemtools installieren und Konfigurationen bearbeiten

Devfs raus, udev rein!

Der Stagetarball kommt mit devsd daher. Wir benutzen jedoch einen 2.6.14er kernel, welcher kein devfs mehr unterstützt. Somit steigen wir auf udev um:

```
sluggy / # emerge udev && emerge -C devfsd

```

Systemlogger

Syslog-ng ist zwar schon ein sehr ausgewachsener Syslogger, aber ich verwende ihn trotzdem, da die NSLU bei mir die Systemlogs von anderen Rechnern empfangen soll. 

```
sluggy / # emerge syslog-ng

sluggy / # rc-update add syslog-ng default
```

Cron

Und einen Cron-jobber brauchen wir ebenso:

```
# emerge vixie-cron

# rc-update add vixie-cron default
```

Cron

Falls benötigt, installiert man noch dhcpcd:

```
# emerge dhcpcd
```

Netzwerkconfiguration

Meine Netzwerkkonfiguration sieht folgendermaßen aus:

```
sluggy / # nano -w /etc/conf.d/net 

config_eth0=( "192.168.1.77 netmask 255.255.255.0 broadcast 192.168.1.255" )

routes_eth0=( "default via 192.168.1.1" )
```

/etc/fstab editieren. Meine sieht folgendermaßen aus:

```

sluggy / # cat /etc/fstab

/dev/sda1       /               ext3    defaults        1  1

/dev/sda2       swap            swap    defaults        0  0

proc            /proc           proc    defaults        0  0

usbfs           /proc/bus/usb   usbfs   defaults        0  0
```

Nun noch ein paar andere Konfigurationsdateien editieren:

```
sluggy / # nano -w /etc/conf.d/hostname

sluggy / # nano -w /etc/conf.d/domainname 
```

Wir sollten auch noch unser rootpassswort festplagen:

```
# passwd
```

Und ausserdem darauf achten, dass der ssh-server, sowie System-logger etc. beim Booten gestartet werden:

```
# rc-update add dropbear default

# rc-update add net.eth0 default

# rc-update add domainname default
```

Und ausserdem müssen wir noch die Module in die /etc/modules.autoload/kernel-2.6 eintragen:

```
# echo "ixp400" >> /etc/modules.autoload/kernel-2.6

# echo "ixp400_eth0" >> /etc/modules.autoload/kernel-2.6
```

 Kernelimage auf die NSLU übertragen und booten

Nun ist es fast geschafft. Es fehlt nurnoch der wichtigste Schritt: das Installieren des Kernels. Um dies zu tun, muss man die NSLU herunterfahren und wieder in den Upgrade-modus bringen. Wichtig ist hierbei wieder: Alle zusätzliche Hardware wie Festplatten, USB-Sticks oder sonstiges abklemmen. Am Gerät dürfen nurnoch Netzwerk und Strom angeschlossen sein. Wie ihr dann die NSLU in den Upgrade-Modus bringt ist bereits bei 1. beschrieben worden. Wenn sich das Gerät im Upgrademodus befindet (die Ready/Status Lampe rot-grün blinkt), dann setzen wir uns wieder an unseren Arbeitsplatz und führen folgendes (natürlich mit der Mac-adresse eurer NSLU)  aus:

```

upslug2 --target=00:13:10:d6:1d:f2  --kernel=/home/roman/nslu/nslu-kernel/linux-2.6.14.3/zImake.ok
```

Es ist geschafft. Nachdem das Kernelimage auf die NSLU übertragen wurde, sollte sie automatisch durchbooten, und unser Gentoo sollte per ssh erreichbar sein.

Möchte mich noch bedanken: 

 Bei den Jungs von openembedded, bzw openslug. Ohne deren Infos wäre ich nich so weit gekommen

 ganz großes Tennis von den embedded-gentoo-jungs. Das sie nerds*geeks² - sie haben nich zu letzt den stagetarball geschaffen  :Smile: 

 Im speziellen möchte ich Vapier und SpankY aus #embedded-gentoo danken, beide machen sehr gute Pakete ohne die ich aufgschmossen wäre (stage3-arm-tarball, crossdev, ixp4xx etc.)

 Und noch ein besonderer dank zuletzt and Morfic aus #gentoo-embedded. Er hat mir vieles Schritt für Schritt erklärt und viele Sachen (gerade der kernel mit den patches und der config) in diesem howto kommen von ihm!

Eigentlich sind sie alle klasse Jungs - waren nur zu faul, das mal Niederzuschreiben, was sie gemach haben  :Smile: 

Links zu den ganzen Seiten, wo ich mir infos geholt habe kommen in den nächsten Tagen.. nu wüsch ich euch allen erstma n guten rutsch  :Smile: 

was geht und was nich geht: 

Nativ kompilieren funzt logischerweise - aber es is laaaaaaaangsaaaaaaam:

[code]

sluggy dev # genlop -t sudo vim

 * app-admin/sudo

     Mon Jan  2 16:53:18 2006 >>> app-admin/sudo-1.6.8_p9-r2

       merge time: 12 minutes and 52 seconds.

 * app-editors/vim

     Mon Jan  2 06:36:51 2006 >>> app-editors/vim-6.4

       merge time: 46 minutes and 56 seconds.


---------------------------------------------------------------------

totes & todo & misc

---------------------------------------------------------------------

todo:

CONFIG_CMDLINE  in der kernelconfig um darin rootfs und sonstiges festzulegen

netzerkkarte ist ixp0 und nicht eth0

2.6.15 + patches von openembedded?

Blinklichter ebuild

fotos

anderes Gehäuse?

fest installierte serielle Schnittstelle

lcd von usblcd.de (mit lcdproc?)

übersetzung ins englische

Kernel kompilieren richtigstellen (nach /usr/src/linux)

Last edited by chilla on Sun Jan 08, 2006 2:44 pm; edited 41 times in total

----------

## nic0000

 *chilla wrote:*   

> Linksys, eine Tochterfirma von Cisco Systems hat vor einiger Zeit ein kleines Maschinchen basierend auf der embedded-arm Architektur herausgebracht, welches sich "NSLU2" nennt. Darauf lässt sich mit Sicherheit wunderbar ein Gentoo zum Laufen bringen.

 

Die haben auch einen Wlan-Router rausgebracht der auch unter Linux laufen kann:

 *Quote:*   

> wrt54g(s)

 

http://openwrt.org

Leider sind da so viele verschiedene Modelle unterwegs, das es keinen Spaß mehr macht ;-(

Ist das bei dem "NSLU2" genauso?

Wo kriege ich _garantiert_ die "richtige" (deine) Version von dem Gerät?

----------

## chilla

Jup. Den wrt-router habe ich auch. Die revisionen der wrt-router sind jedoch relativ gut zu unterscheiden, und ich glaube sogar, dass die unten auf so ner kleinen plakette drauf stehen. 

Bei der NSLU2 habe ich jedoch noch nie davon gehört, dass es unterschiedliche Versionen gibt. Kauf dir einfach eine, dann wirst du es sehen  :Wink:  Zur not kannst du immernoch die Linksys Firmware zurückflashen und das Gerät innerhalb 14 Tagen zurückgeben. Nur solche Spielchen wie das deuncerclocken solltest du innerhalb der 14 Tage lieber erstmal sein lassen  :Wink: 

----------

## tioan

 *chilla wrote:*   

> Jup. Den wrt-router habe ich auch. Die revisionen der wrt-router sind jedoch relativ gut zu unterscheiden, und ich glaube sogar, dass die unten auf so ner kleinen plakette drauf stehen. 

 

Hba hier auch einen Wrt54GS revision 1.2, und es ist definitv so das untem auf dme Gerät ein Aufkleber ist wo die genau Revision drauf steht.

----------

## chilla

hm wobei ich finde dass openwrt ebenso wie openslug irgendwie komisch ist. Mir fehlt bei solchen Mini-sachen immer das Gefühl an einem Linux zu sitzen, wie ich es von einem soliden x86 Arbeitsplatzrechner mit 2.6er kernel, udev und einem guten paketmanagement her kenne. Das is auch einer der Gründe, warum ich hier auf die nslu ein gentoo bratzen möchte  :Smile: 

----------

## nic0000

 *tioan wrote:*   

>  *chilla wrote:*   Jup. Den wrt-router habe ich auch. Die revisionen der wrt-router sind jedoch relativ gut zu unterscheiden, und ich glaube sogar, dass die unten auf so ner kleinen plakette drauf stehen.  
> 
> Hba hier auch einen Wrt54GS revision 1.2, und es ist definitv so das untem auf dme Gerät ein Aufkleber ist wo die genau Revision drauf steht.

 

Unterscheiden kann ich die Teile auch von einander, so Blöd bin ich dann ja doch noch nicht  :Wink: 

Aaaaber, ich habe in Hamburg keinen Laden mit Wrt54GS gesehen. Alle habe nur den Wrt54G, den ich doch nicht so Prall finde (halbes RAM/Halber Flash). 

Also muss ich die GS Version über I-Net bestellen, glaub mal nicht die hätten auch nur ein mal das richtige (wie vorher erkundigt UND zugesagt) geschickt!

Verschieden Läden, selbes Scenario. Dabei bestelle ich als Geschäftskunde und in der Regel mehrere auf einmal. 

Die Systeme der I-Net Läden halten anscheinend solche Details nicht fest wie Revison Nr.

Naja, mittlerweile ist die neuste GS Version auch nur eine G, daher ist das eh lattex. Vielleicht sollte ich mal einen ASUS Delux mit 2xUSB2.0 antesten  :Wink: 

Der hat aber leider keinen Jtag und dieses Feature hat mir schon so manchen WRT gerettet  :Wink:  Ich weiß noch nicht ob ich so mutig bin.

Zurück zum Thema:

@Chilla

Ok, ich werde es so machen wie du mir es empfohlen hast (und mich mit dem modden zurückhalten  :Wink: )

Ich werde mich dann wider melden  :Cool: 

----------

## tioan

HI,

also die neuste GS version nutzt vxworks und kein Linux mehr hat deshalb deutlich wneiger flash, nach protesten aus der openwrt szene, gibt es nun WRT54GL was eigentlich ncihts anderes als ein früherer GS ist ist also wieder mit 6 mb flash und 32 mb ram.

Zu Openwrt, also die packet verwaltung ist an apt angelehnt, da openwrt ipkg nutzt und apt ja auch auf ipkg basiert.

----------

## chilla

apt basiert auf ipkg? ich dachte umgekehrt. Zumindest scheint es mir so..

Naja aber ehrlichgesagt.. 6mb flash sind ein bisschen arg wenig, wenn man sich anschaut, was der speicher kostet. Ich sehs hier auch bei der NSLU: 8mb.. was zum teufel will man mit 8mb? Wenn die ihre firmware aufstocken wollenn, n paar plugins reinbasteln wollen, das webinterface erweiterln wollen oder was auch immer: keine chance - da is einfach kaum mehr platz.

Wenn sie schon ein extra Gerät mit mehr flash rausbringen - wieso dann nicht gleich mit 16 oder 32mb flash?

Ebenso limitieren sie auf der NSLU den Bereich für den Kernel auf 1mb.. als wärn wir n paar jahre zurück. 2-4 mb sollten heutzutage für nen kernel schon drin sein - gerade wenn die Geräte wirklich hochfunktional werden.

----------

## nic0000

 *tioan wrote:*   

> HI,
> 
> also die neuste GS version nutzt vxworks und kein Linux mehr hat deshalb deutlich wneiger flash, nach protesten aus der openwrt szene, gibt es nun WRT54GL was eigentlich ncihts anderes als ein früherer GS ist ist also wieder mit 6 mb flash und 32 mb ram.

 

Ich lese immer wieder wiedersprüchliches von der GL Version. Laut Openwrt Beschreibung ist es aber nur eine G Version:

http://wiki.openwrt.org/TableOfHardware#head-6b2369a6aabba3642915213936b680fdedcffe0d

WRT54GL

Broadcom 5352 @ 200MHz

4MB

16MB

Broadcom (integrated)

 *chilla wrote:*   

> Naja aber ehrlichgesagt.. 6mb flash sind ein bisschen arg wenig, wenn man sich anschaut, was der speicher kostet. Ich sehs hier auch bei der NSLU: 8mb.. was zum teufel will man mit 8mb? 

 

Damit geht schon eine Menge. Es gab ja auch mal Zeiten da hatten die Computer 512 KB siehe Amiga 500. Ich kann nicht behaupten damit keinen spaß gehabt zu haben  :Wink: 

Zum Thema Preis kann ich dir allerdings zustimmen.

 *chilla wrote:*   

> Wenn sie schon ein extra Gerät mit mehr flash rausbringen - wieso dann nicht gleich mit 16 oder 32mb flash?

 

Es geht darum das Cisco auch bessere Geräte im Angebot hat. Sie wollen sich den Markt nicht dadurch kaputt machen das irgendwelche Freaks aus ihren "billig" Routern/NAS irgendwelchen Ersatz für teure Lösungen basteln.

 *chilla wrote:*   

> Ebenso limitieren sie auf der NSLU den Bereich für den Kernel auf 1mb.. als wärn wir n paar jahre zurück. 2-4 mb sollten heutzutage für nen kernel schon drin sein - gerade wenn die Geräte wirklich hochfunktional werden.

 

Typische Beschränkung halt. Es geht immer darum guten Willen zu zeigen aber anderseits dem Kunden nicht zu viel für sein Geld zu geben. Immerhin darf man nicht vergessen das Linksys und Linux nur ein Betriebsunfall war. Sie dachten das merkt keiner wenn sie mal schnell eine Firmware auf einer GPL Software entwickeln. Die User haben es aber gemerkt und jetzt ist Linksys und ein paar andere Firmen unter Druck geraten. Jetzt wo es "rauskam" das es sehr Wohl möglich ist Linux für so etwas zu benutzen würde es einen enormen Image Schaden und Vertrauensverlust in die Marke bedeuten sich da wieder zurück zu ziehen.

Die Industrie will immer nur _und_ immer wieder verkaufen. Ich habe hier ein paar DSL-Modems auseinandner gebaut und sich mal im Netz nach den Bausteinen "erkundigt". Ein NEOTEC Modem von Hansenet hat 64MB Ram und 16MB Flash! Ist also in Wirklichkeit garantiert ein Router. Nur wie flasche ich das Teil?

Egal, die Industrie ist nicht unser Freund und wenn wir mehr wollen als sie uns geben, dann müssen wir uns das schon selbst holen!  :Arrow:  openWRT/openNSLU

----------

## Aproxx

Hast du vielleicht auch einen Link wo man das Teil herbekommt? (Am besten in Österreich) Is ja richtig schnukelig das Baby. Auf jeden Fall schonmal Vielen Dank für das Howto, werde darauf zurückkommen wenn ein paar von den Dingern es sich bei mir gemütlich gemacht haben.

----------

## chilla

hmm ich weiss leider nicht, wo wir die gekauft haben. Mein chef hat ein paar davon gekauft und mir auch eine zu weihnachten geschenkt.. ich hab mich natürlich gleich verliebt  :Wink: 

Wenn ich mal wieder im büro bin, frag ich mal nach, denn er hatte ne relativ günstige quelle dafür. vielleicht schreibt er es dir auch selbst, ich habe ihm das howto gezeigt, er wird hier sicherlich noch reinschauen - er is auch verliebt in das ding, wenn auch als suse-nutzer nur sehr  unglücklich  :Very Happy: .

edit: guenstiger.at, erster link:

http://www.peluga.at/main.php?action=78&ARANUMMER=13068

----------

## Aproxx

 *chilla wrote:*   

> hmm ich weiss leider nicht, wo wir die gekauft haben. Mein chef hat ein paar davon gekauft und mir auch eine zu weihnachten geschenkt.. ich hab mich natürlich gleich verliebt 
> 
> Wenn ich mal wieder im büro bin, frag ich mal nach, denn er hatte ne relativ günstige quelle dafür. vielleicht schreibt er es dir auch selbst, ich habe ihm das howto gezeigt, er wird hier sicherlich noch reinschauen - er is auch verliebt in das ding, wenn auch als suse-nutzer nur sehr  unglücklich .
> 
> edit: guenstiger.at, erster link:
> ...

 

Vielen Dank, die erste wird sichs bald bei mir gemütlich machen  :Smile: 

----------

## Frankieboy

Hi,

danke für die tolle Howto! Ich würde gerne gentoo auf meiner NSLU2 zum Laufen bringen. Ich bin dem howto gefolgt, lief alles soweit ohne Probleme, das Booten klappt aber irgendwie nicht. Es sieht so aus als würde er die root Partition finden und davon booten (Festplattenzugriff etc.). Allerdings bin ich auch nach längerer Zeit nicht in der Lage dann zu connecten. Irgendeine Idee wie ich rausbekommen kann woran es liegt? Ich sehe ja leider nicht wo er hängt.  :Wink: 

Eventuell ein Problem mit dem Netzwerktreiber (ixp400)? Ich habe schon versucht USB_NET in den Kernel zu kompilieren, um meinen Linksys USB200M zum Laufen zu bringen, aber dann will der Kernel nicht mehr kompilieren. Idee wie das geht, eventuell vor dem Patchen die .config ändern?

Kann man vielleicht irgendwo einen compiliertes zImage.ok laden, damit ich ausschließen kann, dass beim kernel kompilieren was schief gelaufen ist?

Wäre für ein paar anregende Tipps woran es liegen könnte dankbar.  :Smile: 

Grüße

Frank

PS. Noch ein kleine Korrekturen zur Howto:

Beim Module entpacken auf der NSLU2 muss das

```
cp -r nslu2-2.6.14.3-modules/lib/modules/2.6.14.3 /lib/modules/
```

wohl cp -R (ein großes R sein damit er das 2.6.14.3 erstellt? Oder?

Hier ist beim Kernel upsluggen ein Tippfehler

 *Quote:*   

> --kernel=/home/roman/nslu/nslu-kernel/linux-2.6.14.3/zImake.ok

 

nslu2-kernel muss es wohl sein.

Und noch ein Tipp. Ich hatte Probleme mit dem Datum, weil es in der Vergangenheit lag, so ging das emergen in eine Endlosschleife. Man sollte also das Datum nach dem chroot auf jeden Fall setzen.

----------

## chilla

schön, dass du es ausprobiert hast  :Smile: 

was ich noch nich reingeschreiben habe: wenn du ixp4xx emergest und die treiber rüberkopierst, dann nennt sich die karte nicht eth0 sondern ixp0. Daran kann es liegen. 

Ich empfehle dir, einfach in boot und default jeweils ein paar kleine sripte reinzuschieben, die dir dmesg und vielleicht den output von ifconfig -a und ifconfig in irgendeine datei auf der platte schreiben. Wenn du merkst, dass der ssh nich online kommt, kannst du einfach die platte abstöpseln, an einen anderen rechner hängen und die schnell die dateien anschauen und entsprechend handeln. 

... Ich weis, das is eigentlich vollkommen hirnrissig - es bleibvt einem jedoch nich allzuviel anderes übrig, wenn man sich die serielle schnittstelle noch nich drangefummelt hat. Was meinst du, wie oft ich die platte umgehängt und die slug neu gebootet habe  :Razz: 

Ansonsten kannst du ja nochmal schauen, ob openssh oder dropbear, was auch immer du nimmst ordentlich gestartet wird etc. vielleicht hast du ja auch einfach "net.bla" nich im runlevel drin  :Wink: 

Ein tipp noch: wenn du das gentoo nich booten kannst, aber trotzdem die arm-binaries auf der platte ausführen möchtest: einfach die slug in dem upgrademodues bringen und nochmal openslug2 draufnudeln (dabei unbedingt die usb-platte vorher abhängen). Das dauert zwar so 2-3 minuten, danach kannst du jedoch openslug booten, dich einloggen und auf die gentoo-platte chrooten um dort irgendwelche arm-programme auszuführen  :Smile: 

Das mit dem kernel ist momentan alles noch ein bisschen fricklig. Es wird demnächst ein paket namens "embedded-sources" erscheinen. Dies wird einen useflag namens "+nslu2" haben.  Diese kann man sichdann einfach nativ auf dem gerät kompilieren, wobei für die nslu2 schon alles fertig und bereit, sowie alles notwendige fest drin ist.

----------

## MadEagle

Moin zusammen!

Dieses How-To ist genau das, was ich gesucht habe, leider funktioniert es bei mir nicht. Ich meine, daß ich den Anweisungen genau gefolgt bin und habe alles relevante (Kernel, Module, Netzwerkeinstellungen etc) mehrfach kontrolliert. Das Problem ist, daß es trotzdem nicht funktioniert. Vielleicht hat ja jemand eine Idee:

Nach dem Upload des Kernels schließe ich die Platte wieder an und boote das System neu. Das geht sehr schnell, die beiden oberen LEDs leuchten dann auch grün aber nicht die LED des USB-Ports. Damit ist natürlich kein Zugriff auf die Platte möglich und das Netzwerk startet nicht.

Irgendwelche Ideen?

MadEagle

----------

## lolly83

Hallo zusammen, und hallo chilla,

danke für das howto! ich hab heute den nachmittag damit verbracht gentoo auf meine slug zu bauen.

alles ist gut gegangen bis ich zum booten gekommen bin.. Mein bootvorgang sieht momentan bei angeschlossener Festplatte genauso aus wie ohne:

Grüne Ready- und Ethernet-Led, Beide DISK-Leds bleiben aus. Ready wechselt dann ein paar mal kurz auf orange und rot, dann gibts zwei mal kurz festplattenzugriff (wenn sie dran ist...), beim zweiten mal springt dann ready auf rot und das wars. Für mich sieht das so aus, als ob er die Festplatte/(npartition) nicht findet... In der Kernel-Config steht ja die Console auf /ttyS? hat da schon jemand versucht was anzuschließen? kommt da was raus, was nach kernel-boot-infos aussieht? laut nslu2-linux.org braucht man ja auch jeden fall einen max232 um es an einen normalen com-port anzuschließen. würde ungern das aufbauen und dann merken, dass da garnix kommt. In der Kernel-Konfig steht auch root-fs-typ sei ext2... wär es evtl ratsam das auf ext3 zu ändern? 

Gruß, Lolly

----------

## lolly83

Hallo nochmal,

ich hatte noch eine fertige schaltung mit einem max232 rumliegen... und siehe da da kommt was.. und zwar richtig viel!

den fehler werde ich morgen suchen, aber so kann man doch schon viel besser damit arbeiten  :Smile: 

das sieht doch alles sehr vertraut aus.. bis auf den fehler natürlich aber darum kümmere ich mich morgen:

 *Quote:*   

> 
> 
>  +Ethernet eth0: MAC address 00:14:bf:62:cb:4f                                              
> 
> IP: 192.168.0.1/255.255.255.0, Gateway: 192.168.0.1                                                   
> ...

 

----------

## chilla

 *MadEagle wrote:*   

> Moin zusammen!
> 
> Dieses How-To ist genau das, was ich gesucht habe, leider funktioniert es bei mir nicht. Ich meine, daß ich den Anweisungen genau gefolgt bin und habe alles relevante (Kernel, Module, Netzwerkeinstellungen etc) mehrfach kontrolliert. Das Problem ist, daß es trotzdem nicht funktioniert. Vielleicht hat ja jemand eine Idee:
> 
> Nach dem Upload des Kernels schließe ich die Platte wieder an und boote das System neu. Das geht sehr schnell, die beiden oberen LEDs leuchten dann auch grün aber nicht die LED des USB-Ports. Damit ist natürlich kein Zugriff auf die Platte möglich und das Netzwerk startet nicht.
> ...

 

Die Lämpchen des USB-ports zeigen auch nicht mehr den durchsatz vom usb an  :Smile:  Es ist in diesem falle sinnvoll, das ohr auf die platte zu legen, damit du hörst, ob die platte rattert. Wenn die platte richtig rattert, dann bedeutet das, dass der kernel geladen und das rootfs gemountet wurde, und dass das meiste schon erledigt ist. 

Ich wiederhole mich gerne: wenn ihr keinen usb2serial converter habt, und auch nicht den nativen seriellen port nutzt, schreibt euch ein paar kleine sachen in die initscripte rein: beispielsweise dass dmesg und ifconfig-a und ps aux  in eine datei geschrieben werden. Dann könnt ihr ganz einfach die festplatte schnell an einen anderen rechner hängen, und nachschauen, was in diesen dateien drin steht.

----------

## chilla

 *lolly83 wrote:*   

> Hallo zusammen, und hallo chilla,
> 
> danke für das howto! ich hab heute den nachmittag damit verbracht gentoo auf meine slug zu bauen.
> 
> alles ist gut gegangen bis ich zum booten gekommen bin.. Mein bootvorgang sieht momentan bei angeschlossener Festplatte genauso aus wie ohne:
> ...

 

Die 2 kurzen festplattenzugriffe sind glaube ich nur vom controller und werden nicht von der software gesteuert. ich habe das gefühl, dein kernel ist nicht richtig. Entweder er ist zu groß (größer als 1 mb), im falschen format (nicht für arm kompiliert) oder du hast ihn nicht mit "prepimage" bearbeitet. Versuche einfach mal meinen hier: 

http://chilla.biz/projekte/gentoo-slug/files/zImage.ok    <- das kannst du einfach mit upslug2 --taget=bla --kernel=zImage.ok  hochladen.

Und zum ttyS: Wie im howto obenbeschrieben: die slug hat eine native serielle schnittstelle. Da muss jedoch noch ein kleiner rs232 chip und ein stecker ran, das wars - dafür habe ich auch den bootparameter rangehängt. Da du den rs232chip jedoch mit sicherheit noch nicht drangelötet hast bringt dir der parameter leider nichts  :Sad: 

----------

## lolly83

Hallo chilla,

danke für deine antwort.. ich hatte deine config-file genommen und das ganze auch schön cross-compiliert. wie auf meinem letzten post hat er dann auch gebootet, aber die partition nicht gemountet. ich hab dann ein bisschen an den parametern vom usb-controller rumgespielt:

Device Drivers>USB->EHCI HDC (USB2.0) support

und da drunter die optionen Fullspeed ISO Transaction sowie Root Hub Transaction abgeschaltet, compiliert und siehe da es geht! Aber der clou ist: danach habe ich die optionen wieder reingemacht und es geht immernoch!? allerdings ohne ein make clean vorher... evtl macht das dann irgendwas komisch.

Im moment bügle ich noch ein paar tippfehler aus, aber mein gentoo bootet schon brav  :Smile: 

achja was ich noch gebraucht habe war folgendes:

da mir das gentoo-boot-script fehlermeldungen um die ohren geschlagen hat, dass die modules.dep fehlen würde musste ich die noch anlegen.

Openslug gebootet, übertragen der System.map aus dem nslu-kernel-dir auf die slug.

Da Openslug den 2.7beta? den kernel 2.6.12.2 verwendet habe ich dann

```
cd /lib/modules

ln -s 2.6.14.3 2.6.12.2

depmod -a -F System.map
```

gemacht und dann in nano die datei /lib/modules/2.6.14.3/modules.dep editiert und alle "2.6.12.2" strings in "2.6.14.3" geändert.

Gerade läuft noch ein e2fsck auf meinem Client aber ich bin guter dinge, dass ich innerhalb der nächsten stunde ein laufendes gentoo haben werde  :Smile: 

Gruß, Lolly

----------

## chilla

herzlichen glückwunsch  :Smile:  Dann hast du das meiste schon hinter dir. Wahrscheinlich wird dir noch messages mit allen möglichen fehlermeldungen von der inittab zugespammt, da es keine konsolen gibt (musste sie aus platzgründen aus dem kernel nehmen). Udev legt die dateien trotzdem an, aber nich als characterdevices...  ich hab die dinger jetz einfach aus der inittab auskommentiert. 

Werde mich jedoch die tage mal ranmachen und ne ordentlichen 2.6.15er zum laufen bringen.

läuft denn auch das netzwerk schon?

----------

## MadEagle

Soderle ... nach den Anweisungen auf dem Gentoo-Wiki habe ich ein Gentoo-System zum Kaufen gebracht, das aber noch den OpenSlug 2.7-Kernel verwendet und dabei viel über OpenSlug und Gentoo gelernt (so soll das ja auch sein, oder?  :Wink: )

Jetzt wird das System erstmal rund gemacht (screen, ufed, cfg-update ... was man so braucht), und dann mache ich mich an den Kernel.

Noch ein paar Hinweise zum How-To:

- Irgendwie fehlt mir die Anweisung, am Ende ein "turnup disk /dev/sda1" zu machen, damit das System das rootfs der Platte nimmt. Oder steht das in der Kernel-Config drin?

- Es geht viel schneller, eine stage und den portage-Snapshot auf das System zu bringen, wenn man die Platte an seinem Arbeitsrechner vorbereitet (partitionieren, formatieren, stage3 und Snaphsot drauf).

- Unter der zitierten Wiki-URL gibt es noch ein paar gute Hinweise auf Nacharbeiten (Anpassungen der inittab bzgl. Terminals, Anpassung Netzkonfig bzgl. MAC-Adresse, Beschleunigung "emerge sync" etc.), kann man vielleicht hier übernehmen?

Bin gespannt, wie das mit dem 2.6.15er Kernel wird, dann werde ich das nochmal probieren.

MadEagle

----------

## chilla

 *MadEagle wrote:*   

> [...]
> 
> - Irgendwie fehlt mir die Anweisung, am Ende ein "turnup disk /dev/sda1" zu machen, damit das System das rootfs der Platte nimmt. Oder steht das in der Kernel-Config drin?
> 
> 

 

Das brauch/kann man nur machen, wenn man openslug im flash hat und dieses auch bootet. So wird das beispielsweise im Wikiartikel gemacht. Der Weg, den ich hier beschrieben habe, verwendet jedoch garkein openslug mehr. Wenn gentoo mal auf der platte ist, ist im flash des Geräts nurnoch das Kernelimage - kein openslug und auch keine andere ramdisk. 

Bei dem System im wikiartikel kann man grob sagen, dass openslug gebootet wird, und dann nach gentoo gechrootet wird. Das fällt bei meinem Weg weg. Daher boote ich auch nicht vom flash sondern von der festplatte. Der rootfs-parameter wird in der kernelconfig festgelegt. 

 *Quote:*   

> 
> 
> - Es geht viel schneller, eine stage und den portage-Snapshot auf das System zu bringen, wenn man die Platte an seinem Arbeitsrechner vorbereitet (partitionieren, formatieren, stage3 und Snaphsot drauf).
> 
> 

 

Da hast du recht  :Smile: 

 *Quote:*   

> 
> 
> - Unter der zitierten Wiki-URL gibt es noch ein paar gute Hinweise auf Nacharbeiten (Anpassungen der inittab bzgl. Terminals, Anpassung Netzkonfig bzgl. MAC-Adresse, Beschleunigung "emerge sync" etc.), kann man vielleicht hier übernehmen?

 Ja. Aber ich denke, ich werde auch mal einen Artikel ins deutsche wiki schreiben, damit ihr alle  was reinschreiben könnt. Alleine an so einem howto zu arbeiten is irgendwie doof  :Smile: 

 *Quote:*   

> Bin gespannt, wie das mit dem 2.6.15er Kernel wird, dann werde ich das nochmal probieren.

 Das wird nicht anders werden als mim 2.6.14er auch  :Wink: 

MadEagle[/quote]

----------

## lolly83

Hallo chilla und der ganze rest,

ja so siehts aus  :Smile:  es tut.. mit alles und scharf!   :Laughing: 

unten hängt ein log vom bootup

Kernel-Flash via RedBoot und upslug2:

 *Quote:*   

> +Ethernet eth0: MAC address 00:14:bf:6f
> 
> IP: 192.168.0.1/255.255.255.0, Gateway: 192.168.0.1
> 
> Default server: 0.0.0.0, DNS server IP: 0.0.0.0
> ...

 

RedBoot durchlauf mit geflashtem Linux-Kernel:

 *Quote:*   

> 
> 
> +Ethernet eth0: MAC address 00:14:bf:62:cb:4f
> 
> IP: 192.168.0.1/255.255.255.0, Gateway: 192.168.0.1
> ...

 

Und ab gehts: (Die stellen bei denen sich bei mir noch ein paar Nackenhaare aufstellen hab ich mal markiert)

 *Quote:*   

> 
> 
> Uncompressing Linux.................................................................... done, booting the kernel.
> 
> Linux version 2.6.14.3 (openslug@openslug.org) (gcc version 3.4.5 (Gentoo 3.4.5, ssp-3.4.5-1.0, pie-8.7.9)) #7 PREEMPT Sat Jan 28 11:25:07 CET 2006
> ...

 

jo sieht ja alles cool aus soweit  :Smile:  Gerade hab ich webmin installiert, damit ich auch ein web-frontend hab   :Very Happy:   tut auf anhieb!

will jemand ein festplatten-image?  :Wink: 

gruß, lolly

----------

## chilla

schön, dass es bei dir lüppt  :Smile: 

 *Quote:*   

> Warning: bad configuration page, trying to continue 

  Kommt bei mir auch..  is aber wurst und macht nix  :Smile: 

 *Quote:*   

> EXT2-fs warning (device sda1): ext2_fill_super: mounting ext3 filesystem as ext2 << ich nehm an mit nem anderen kernelparameter wär das gegessen?! 

 

Obacht! Der Kernel im flash darf maximal 1 mb groß sein, sonst passt er nich in seine "kernel-partition" des flashs. Daher habe ich ext2 fest in den kernel einkompiliert. ext3 habe ich nich ausprobiert, jedoch bin ich mit 992kb hart an der grenze, und ich glaube nicht, dass da noch ext3 statt ext2 raufpasst.  Muss ich mal ausprobieren... vielleicht find ich auch noch irgendwas, was ausm kernel raus kann, damit man noch ein bisschen paltz bekommt. Dass man andere fs-typen als modul ablegen kann, is denke ich mal klar. Wenn du die Fehlermeldung loswerden willst: entweder bau ext3 fest in deinen Kernel ein, mach ext2 raus, änder in der kernelconfig "CONFIG_CMDLINE" und die /etc/fstab so ab, dass da ext3 statt 2 steht, dann passt das. oder du nimmst dir ein tool und machst aus der ext3 partition ne ext2 (glaube tune2fs kann sowas). 

 *Quote:*   

>  * Starting udevd ... [ !! ] << ist das normal? 

  Du wirst den gleichen weg wie ich gegangen sein: devfs raus, udev rein. dann solltest du eigentlich erfreut darüber sein, dass udev startet  :Smile: 

 *Quote:*   

> 
> 
>  * Error loading key mappings
> 
> [ !! ]
> ...

 

/etc/inittab die terminals auskommentieren. Keine konsolen vorhanden, also auch kein support vorhanden -> raus damit. 

```

[...]# TERMINALS

#c1:2345:respawn:/sbin/agetty 38400 tty1 linux

#c2:2345:respawn:/sbin/agetty 38400 tty2 linux

#c3:2345:respawn:/sbin/agetty 38400 tty3 linux

#c4:2345:respawn:/sbin/agetty 38400 tty4 linux

#c5:2345:respawn:/sbin/agetty 38400 tty5 linux

#c6:2345:respawn:/sbin/agetty 38400 tty6 linux

```

----------

## MadEagle

 *lolly83 wrote:*   

> 
> 
> EXT2-fs warning (device sda1): ext2_fill_super: mounting ext3 filesystem as ext2          << ich nehm an mit nem anderen kernelparameter wär das gegessen?!
> 
> 

 

Damit sagt Dir Dein Kernel, daß er zwar gemerkt hat, daß es ein ext3-FS ist, er es aber als ext2 mountet. Der Grund dafür dürfte sein, daß ext2 in chilla's Kernel fest einkompiliert ist, ext3 aber nur als Modul. Versuch mal, ext3 fest einzukompilieren, wenn der Kernel dann nicht zu groß wird.

 *Quote:*   

> 
> 
>  * Starting udevd ...                                                     [ !! ]                 << ist das normal? 
> 
> 

 

Warum nicht? Wenn der Udevd da ist, dann sollte er auch verwendet werden bzw. er MUß verwendet werden, weil ab 2.6.13 oder so devfs nicht mehr unterstützt wird, daher hast Du auch den udevd installiert und den devfsd rausgeschmissen.

 *Quote:*   

> 
> 
> << Chilla hat ja vorhin geschrieben, dass der console-support fehlt 
> 
> 

 

Dafür einfach die entsprechenden Zeilen in /etc/inittab auskommentieren, dann sind die Fehler weg.

Mich würde nochmal interessieren, wohin Gentoo die Ausgabe der Startskripte schreibt, damit man sie so wie Du hier lesen kann. Das gleiche gilt für die Logs von RedBoot!?!

MadEagle

----------

## lolly83

hallo zusammen,

ja ich wunder mich ja auch nciht dass der udevd gestartet wird, sondern dass die [!!] mir anzeigen dass irgendwas schief geht. die frage war ob das bei euch auch so ist und ob er trotzdem geht.. geladen ist er zumindest.

Gruß, Lolly

----------

## Rene-dev

Vielen dank für das howto,

hast vergessen zu schreiben

```

cp /etc/resolv.conf /mnt/gentoo/etc/resolv.conf

```

vor dem chroot

nochmals danke, 

rene

----------

## int2str

Chilla/Alle,

Ich habe diese super Anleitung befolgt um Gentoo auf meinem NSLUG2 zu installieren.

Leider started es aboer nicht korrekt.

Ich habe den kernel von Chilla, sowie meine eigenen versucht, ohne Erfolg...

Bei einem reboot mit der Platte angehaengt scheint von der Platte gelesen zu werden. Nach einer Weile wirds aber ruhig und die LEDs bleiben auf orange oben und gruen darunter stehen und nichts geht mehr. Die NSLUG holt sich keine IP addresse und ist daher im Netz nicht verfuegbar. Habs auch mal mit fester IP probiert, aber das gleiche Problem gehabt.

Irgendwelche Ideen?

Danke!

----------

## int2str

Update:

Sieht so aus als das Problem in /etc/init.d/clock liegt. hwclock --hctosys haengt sehr lange. Wenn ich "fake_it=1" in clock setze booted die machine in 1:20min!

----------

## chilla

Dieses Problem hatte ich zwar nicht, aber es freut mich, dass es schon ein paar leute gemacht haben  :Smile: 

Ich schreibe das Howto momentan neu - und zwar in einem Wiki, damit ihr euch daran beteiligen könnt  :Smile: 

http://de.gentoo-wiki.com/Gentoo_on_NSLU2   <- evtl auch in englischer übersetzung.

----------

## Vollkorn

Bitte sagt mir wenn ich mit meinem Problem hier am falschen Platz bin.

Wenn ich genau nach Anleitung vorgehe erhalte ich folgende Fehlermeldung von crossdev auf meinem Desktop:

env LANG="C" crossdev armeb-softfloat-linux-uclibc

 *Quote:*   

> 
> 
> [...]
> 
>  * gcc failed :(
> ...

 

/var/log/portage/cross-armeb-softfloat-linux-uclibc-info.log

 *Quote:*   

> 
> 
> jan@jan ~ $ cat /var/log/portage/cross-armeb-softfloat-linux-uclibc-info.log
> 
> ----------------------------------------------------------------------------------------------------------------------------------------
> ...

 

/var/log/portage/cross-armeb-softfloat-linux-uclibc-gcc-stage1.log

 *Quote:*   

> 
> 
> [...]
> 
>  * Done with patching
> ...

 

Was mich wundert:

 *Quote:*   

> 
> 
> jan nslu2-kernel # ls -la /usr/i686-pc-linux-gnu/bin/ld
> 
> lrwxrwxrwx  1 root root 45 27. Dez 01:27 /usr/i686-pc-linux-gnu/bin/ld -> /usr/i686-pc-linux-gnu/binutils-bin/2.16.1/ld
> ...

 

Also ist die Datei ja da, oder?

Ein "env-update && source /etc/profile" hat nichts gebracht.

Google hat mir keine Hilfe geben können.

Wie kann ich das Problem eingrenzen?

Vielen Dank

Jan

----------

## Vollkorn

Okay, ich bin weiter gekommen indem ich eine andere gcc-Version gewählt habe:

 *Quote:*   

> 
> 
> jan ~ # crossdev --g 3.4.4 armeb-softfloat-linux-uclibc
> 
> ----------------------------------------------------------------------------------------------------------------------------------------
> ...

 

/var/log/portage/cross-armeb-softfloat-linux-uclibc-linux-headers.log

 *Quote:*   

> 
> 
> >>> Unpacking linux-2.6.11.tar.bz2 to /var/tmp/cross/armeb-softfloat-linux-uclibc/portage/linux-headers-2.6.11-r2/work
> 
>  * gentoo-headers-2.6.11-5.tar.bz2 unpacked
> ...

 

Almählich beschleicht mich das Gefühl, dass an meinem System iorgendetwas ganz schön im Argen ist.

Jan

----------

## Vollkorn

Nur zur Information:

Habe jetzt den Kernel über Nacht auf der Slug selbst kompiliert und das lief alles bestens.

Also eindeutig ein reines Problem meiner Crosscompile-Umgebung auf dem Desktop.

Gruß

Jan

----------

## bcsthsc

Hallo,

ich versuche mich auch gerade an der Konvertierung des NSLU in ein gentoo System.

Zur Zeit gibts ein Problem mit dem Kernel, bzw dem ixp4xx modul.  Die folgende Ausgabe

ist die letzte aus der dmesg:

 *Quote:*   

> ...
> 
> NET: Registered protocol family 17
> 
> ieee80211_crypt: registered algorithm 'NULL'
> ...

 

Danach kann keine Netzwerk-Device gefunden werden.

Hat jemand eine Idee, was da schiefgegangen ist ?

Oder ist das so ok und ich habe etwas bei den rc-scripten falsch gemacht ?

----------

## Vollkorn

Bei mir sieht es gerade sehr ähnlich aus. dmesg hat genau den gleichen Inhalt.

Allerdings sagt das noch nicht segr viel. Installier mal showconsole-1.08 (frühere Versionen kompilieren nicht gegen die uclibc) und setze in der /etc/conf.d/rc die Variable RC_BOOTLOG="yes". Dann bekommst du eine Logdatei vom Bootvorgang: /var/log/boot.msg, die bei mir gerade so aussieht:

```

 * Remounting root filesystem read/write ...                              [ ok ]

 * Setting hostname to nslu2 ...                                          [ ok ]

 * Calculating module dependencies ...                                    [ ok ]

 * Using /etc/modules.autoload.d/kernel-2.6 as config:

 *   Loading module ixp400 ...                                            [ ok ]

 *   Loading module ixp400_eth0 ...

 *   Failed to load ixp400_eth0

                                                                          [ !! ]

 * Autoloaded 1 module(s)

 * Checking all filesystems ...                                           [ ok ]

 * Mounting local filesystems ...                                         [ ok ]

 * Mounting USB device filesystem (usbfs) ...                             [ ok ]

 * Activating (possibly) more swap ...                                    [ ok ]

 * Setting system clock using the hardware clock [UTC] ...                [ ok ]

 * Configuring kernel parameters ...                                      [ ok ]

 * Updating environment ...                                               [ ok ]

 * Cleaning /var/lock, /var/run ...                                       [ ok ]

 * Cleaning /tmp directory ...                                            [ ok ]

 * Caching service dependencies ...                                       [ ok ]

```

Wie man eindeutig sieht ist mein ixp400_eth0-Modul im Eimer ohne irgendeine Nachricht im dmesg zu hinterlassen. Dementsprechend findet sich auch ein Eintrag in /var/log/messages, der besagt, dass das Device ixp0 nicht existiert.

Hast du auch darauf geachtet? Das Netzwerkdevice heißt ixp0 und nicht eth0!

Hoffentlich hast du jetzt ein par Ansätze  :Smile: 

----------

## bcsthsc

 *Vollkorn wrote:*   

> Bei mir sieht es gerade sehr ähnlich aus. dmesg hat genau den gleichen Inhalt.
> 
> Allerdings sagt das noch nicht segr viel. Installier mal showconsole-1.08 (frühere Versionen kompilieren nicht gegen die uclibc) und setze in der /etc/conf.d/rc die Variable RC_BOOTLOG="yes". Dann bekommst du eine Logdatei vom Bootvorgang: /var/log/boot.msg, ...

 

Danke, das ist ein guter Tip.

 *Quote:*   

> Wie man eindeutig sieht ist mein ixp400_eth0-Modul im Eimer ohne irgendeine Nachricht im dmesg zu hinterlassen. Dementsprechend findet sich auch ein Eintrag in /var/log/messages, der besagt, dass das Device ixp0 nicht existiert.
> 
> 

 

Den "Eindruck" hatte ich auch schon. Mir ist übrigens aufgefallen, das openslug2.7 ein Modul namens ixp425 benutzt.  Leider gibts sowas nicht im Gentoo.

 *Quote:*   

> Hast du auch darauf geachtet? Das Netzwerkdevice heißt ixp0 und nicht eth0!

 

Da kümmere ich mich drum wenn das Modul funktioniert.  Hätte man aber besser beschreiben können. 

 *Quote:*   

> Hoffentlich hast du jetzt ein par Ansätze 

 

Mein letzter Ansatz war, einen 2.6.15 Kernel zu nehmen und alles nochmal bei null anzufangen.  

Leider funktioniert ixp4xx nicht mit diesem kernel.  Zum selber patchen hatte ich noch keine Zeit, daher liegt die Sache bei mir erstmal brach.

Trotzdem Danke für die Hilfe.  Und meld dich, wenn du weiter kommst.

----------

## chilla

also bei mir rennt der kernel mit dem Modul. 

 *Quote:*   

> 
> 
> localhost ~ # lsmod
> 
> Module                  Size  Used by
> ...

 

2.6.15 ging vor ein paar wochen noch nicht, da der ixp4xx treiber nich gegen den kompiliert. 

Die Bezechning ixp400 ist schon richtig. ixp424 heist das Modul nur bei Openslug.

----------

## Vollkorn

Was für ein peinlicher Fehler!

Wie gesagt, genau die gleichen Symptome wie du, bcsthsc. Ich habe alles mögliche als Fehlerquelle vermutet, aber ich bin nicht auf die Idee gekommen mir mal ein 'modprobe ixp400_eth0' innerhalb der local.start in eine Logdatei zu schreiben. Dann wäre es mir sofort aufgefallen:

Der Modulname ist falsch! Es heißt ixp400_eth (ohne "0" am Ende!)

Das kommt davon wenn man Anleitungen ohne Nachdenken per Copy & Paste befolgt.  :Wink: 

jetzt funktioniert auch alles wie es soll.  :Very Happy: 

Viel Erfolg noch

----------

## chilla

arghs..  :Wink:  sorry  :Very Happy: 

Aber genau deswegen habe ich ja nun den Wikiartikel angefangen... dmait ihr alle (vorrausgesetzt ihr wollt) mitarbeiten und euern senf dazugeben könnt  :Smile: 

----------

## bcsthsc

 *Vollkorn wrote:*   

> Der Modulname ist falsch! Es heißt ixp400_eth (ohne "0" am Ende!)
> 
> ...
> 
> jetzt funktioniert auch alles wie es soll. 

 

Wow, das is ja n Ding.  Hier gehts jetzt auch.  Danke Vollkorn.

----------

## bcsthsc

Hallo,

ich habe jetzt ein nettes NSLU gentoo auf der Platte. Was mich jetzt noch stört, ist das das root-FS

auf der Platte liegt.  Am liebsten hätte ich es, wenn alles auf dem Memory Stick läge.

Leider ist es mir nicht gelungen, das zu bewerkstelligen. Es sieht so aus, als ob der kernel nach 

dem booten geladen wird, denn der Stick blinkert ein paar Sekunden lang lustig vor sich hin.

Danach geht allerdings nix mehr.  In /var/log findet sich auch noch kein Hinweis.

Gibts da ein prinzipielles Problem oder habe ich nur irgendwas verkonfiguriert ?

Gibts irgendwelche Tips, wie man die Sache z.B. mit einer initrd aufziehen könnte ?

----------

## chilla

 *bcsthsc wrote:*   

> Hallo,
> 
> ich habe jetzt ein nettes NSLU gentoo auf der Platte. Was mich jetzt noch stört, ist das das root-FS
> 
> auf der Platte liegt.  Am liebsten hätte ich es, wenn alles auf dem Memory Stick läge.
> ...

 

Der kernel wird nicht nach dem booten geladen. Der kernel wird geladen um gebootet zu werden.  :Smile: 

Du solltest mal ausprobieren, die rootfsdelay zeit hochzustellen. Eine festplatte brauch beim booten etwa 10 sekunden, bis sie geladen wird. ein usb-stick kann unter umständen etwas länger brauchen. 

Eine serielle konsole könnte dir dabei weiterhelfen. Denn dann würdest du in minicom genau sehen, woran es liegt. Evtl kannst du auch eine usb-netzwrekkarte kaufen, für die es native treiber im kernel gibt, diese fest einkompilieren und dann das neue network-logging-feature vom kernel ausprobieren. damit würdest du es ebenfalls sehen.

----------

## think4urs11

Anscheinend sehe ich gerade den Wald vor lauter NLSUs nicht mehr  :Wink: 

Derzeit hänge ich an der Stelle 'Patches für Kernel holen' - sämtliche Quellen die ich im Thread/Wiki gefunden habe exisitieren entweder nicht oder wollen ein Paßwort von mir.   :Embarassed: 

Und ob das Teilchen so begeistert ist mit dem 2.7beta-OpenSlugkernel zu booten und einem 3/4 installiertem Gentoo da bin ich mir auch nicht so sicher ...

Hardwareumbauten wollte ich eigentlich nicht daran machen, jedenfalls nicht bis es mal vollständig läuft.

Kann mir jemand aus dem Wald heraushelfen?

----------

## chilla

ja, ich bin mit meinem server umgezogen... muss erstma die alten backups wieder suchen und aufspielen.. ich hoffe, das werde ich bis heute abend getan haben.

gruß

----------

## nic0000

 *chilla wrote:*   

> ja, ich bin mit meinem server umgezogen... muss erstma die alten backups wieder suchen und aufspielen.. ich hoffe, das werde ich bis heute abend getan haben.

 

Dein Abend ist aber lang....

Habe das selbe Problem wie Think4UrS11. Irgendwie sind die Patches überall weg und ich finde keine Info wohin bzw. warum.

----------

## think4urs11

 *nic0000 wrote:*   

> Dein Abend ist aber lang....
> 
> Habe das selbe Problem wie Think4UrS11. Irgendwie sind die Patches überall weg und ich finde keine Info wohin bzw. warum.

 

*g* du kannst Gedanken lesen - ich wollte auf gerade mal wieder nachfragen.

Oder weiß jemand wo man sonst die passenden 'Materialien' herbekommen könnte?

----------

## nic0000

 *Think4UrS11 wrote:*   

> *g* du kannst Gedanken lesen

 Jupp, aber nur von einfachen Lebewesen  :Razz: 

 *Think4UrS11 wrote:*   

> Oder weiß jemand wo man sonst die passenden 'Materialien' herbekommen könnte?

 

Ich hänge zwar immer noch am update des Systems fest, aber ich glaube zu Not kann auch dieser Weg befolgt werden:

http://gentoo-wiki.com/HARDWARE_Linksys_NSLU2#Copy_kernel_modules

Ansonsten habe ich das hier gefunden habe aber noch nicht die Zeit gehabt sich weiter darum zu kümmern:

http://ipkgfind.nslu2-linux.org/details.php?package=kernel-dev&official=&format=

Da stehen schon mal die Patches, aber leider keine Quellen  :Sad: 

@Think4UrS11

Ich bin bis morgen Abend Internet-los am Baggersee unterwegs, kannst du eventuell mal eine Mail dort hinschicken?

----------

## think4urs11

 *nic0000 wrote:*   

>  *Think4UrS11 wrote:*   *g* du kannst Gedanken lesen Jupp, aber nur von einfachen Lebewesen 

 

 :Shocked:  wenn ich jetzt nicht wüßte das der Spruch ausgerechnet von dir kommt ....   :Twisted Evil: 

 *nic0000 wrote:*   

> Ansonsten habe ich das hier gefunden habe aber noch nicht die Zeit gehabt sich weiter darum zu kümmern:
> 
> http://ipkgfind.nslu2-linux.org/details.php?package=kernel-dev&official=&format=
> 
> Da stehen schon mal die Patches, aber leider keine Quellen 

 

mal sehen vielleicht kann ich mich dazu aufraffen ansonsten warten wir eben auf chilla  :Smile: 

----------

## chilla

*lechz* 

ubbala, ganz vergessen  :Smile:   Soo... moment, ich mach das ma jetzt gleich. *in 5 minuten wieder da bin*

soo  :Smile: 

http://nyrbs.de/~chilla/projekte/NSLU2/   hier haberter schonma nen teil. Leider bin ich momentan in berlin. Meine defaultconfig liegt zu hause irgendwo rum. ich schau ma, ob ich die auch noch dazuschiessen kann. 

Grüße.

Edit: Das tut mir leid.. die einzige Slug, die bei mir zu Hause gerade läuft hat leider kein /proc/config support im kernel drin.. ansosnten hätt ich euch die config auch noch gegeben...  Ich schau ma, ob ich sonst noch irgendwie rankomme.

----------

## nic0000

 *chilla wrote:*   

> Edit: Das tut mir leid.. die einzige Slug, die bei mir zu Hause gerade läuft hat leider kein /proc/config support im kernel drin.. ansosnten hätt ich euch die config auch noch gegeben...  Ich schau ma, ob ich sonst noch irgendwie rankomme.

 

Cool der Chilla lebt ja doch noch  :Smile: 

Sage mal, ist das mit dem Kernel immer noch so, das kein neuer geht? Mir ja eigentlich egal, nur so Interesse halber.

Ansonsten gibt es irgendwo schon gepatchte Sources zum runterladen? (Ich klinge ja schon wie der nicht aufraffer Think4UrS11  :Twisted Evil:  )

----------

## chilla

na klar leb ich  :Smile: 

Errm.. es is so: prinzipiell geht jeder 2.6er kernel. 

Mein Problem is jedoch der netzwerkkartentreiber ixp4xx. Die jungs von Openslug haben auch für die ganz neuen Kernel gescheite patchsets. Und irgendwie scheinen die es auch zu schaffen, den ixp-netzwerktreiber gegen nen aktuellen kernel kompilieren zu lassen. Als die damals gerade bei 2.6.14.3 waren, hat vapier einfach ma n ebuild gemacht und das teil in portage geschmissen. Leider lässt sich das ebuild nich gegen nen neueren Kernel kompilieren  :Sad:  Zumindest  bei mir nicht. 

Aber wie gesagt: die jungs von openslug nutzen neue kernel und haben keine Probleme damit. Man muss sich ma bei denen erkundigen, wie die die netzwerktreiber da kompilieren oder vorher patchen.. ich find dieses intel-zeugs nur sehr verwirrend. 

Falls du jedoch auf die chipeigene netzwerkkarte verzichten kannst und vielleicht nen lan/wlan-stick benutzt, der nativ vim kernel unterstützt wird, kannst du auch ohne sorgen nen aktuellen kernel benutzen. 

Das einzige was mich bei 2.6.14.3 hält ist dieser dämliche ixp4xx  :Sad:  Aber vielleicht findet hier ja jemand ne lösung.

----------

## nic0000

 *chilla wrote:*   

> na klar leb ich 

 Suppi  :Smile: 

 *chilla wrote:*   

> Errm.. es is so: prinzipiell geht jeder 2.6er kernel. 

 OK

 *chilla wrote:*   

> Mein Problem is jedoch der netzwerkkartentreiber ixp4xx. 

 Nicht nur deines  :Wink: 

 *chilla wrote:*   

> Man muss sich ma bei denen erkundigen, wie die die netzwerktreiber da kompilieren oder vorher patchen.. ich find dieses intel-zeugs nur sehr verwirrend. 

 Ich habe da letztens mal eine Mail geschickt mit der Anfrage wo ich denn die Patches finden kann. Bis jetzt kam da keine Antwort. Entweder mein Englisch kam nicht gut an, oder ich habe wohl mal wieder irgendwo in einen toten Briefkasten geschrieben :-/

 *chilla wrote:*   

> Falls du jedoch auf die chipeigene netzwerkkarte verzichten kannst und vielleicht nen lan/wlan-stick benutzt, der nativ vim kernel unterstützt wird, kannst du auch ohne sorgen nen aktuellen kernel benutzen. 

  Können könnte ich schon auf die onboard NIC verzichten, aber ich will nicht  :Wink: 

 *chilla wrote:*   

> Das einzige was mich bei 2.6.14.3 hält ist dieser dämliche ixp4xx  Aber vielleicht findet hier ja jemand ne lösung.

 

Also ich habe gelesen das man auch einfach das Modul aus einem openslug Packet nehmen kann sofern die Kernelversionen gleich sind. Ich dachte aber das ich auf funktionalität verzichte bzw. der Kernel wichtige Sachen nicht kann wenn ich den Kernel nicht mit den Patches versehe. Wozu sind denn eigentlich denn die Patches gut? Denn die Namen klingen doch schon überwiegend wichtig finde ich (wobei ich von Kernelentwicklung keine Ahnung habe)

EDIT:

Oh man, ich bin manchmal so doooof. Kann es sein das ich die Patches auch auf einen Aktuellen Kernel anwenden kann? Wohl schon, oder? Oh man!

----------

## chilla

hiho

 *Quote:*   

> Ich habe da letztens mal eine Mail geschickt mit der Anfrage wo ich denn die Patches finden kann. Bis jetzt kam da keine Antwort. Entweder mein Englisch kam nicht gut an, oder ich habe wohl mal wieder irgendwo in einen toten Briefkasten geschrieben :-/ 

  Wo du die patches für den Kernel findest, kann ich dir sagen: http://nslu.cvs.sourceforge.net/nslu/kernel/

da gibts die aktuellen patches. Und irgendwie bauen die da auch das ixpmodul. hab mir das ganze noch nich richtig angeschaut. wenn du dahinter gekommen bist, kannst es ja ma kurz aufschreiben. 

 *Quote:*   

> Also ich habe gelesen das man auch einfach das Modul aus einem openslug Packet nehmen kann sofern die Kernelversionen gleich sind.

 So nen scheiss macht man, wenn man debian benutzt oder anderweitige probleme psychosozialer herkunft hat  :Wink:  Klar kann man das, und ich glaube, das funzt auch. Aber nichts desto trotz willst du deinen kernel mit deiner config inden quellen vorliegen haben, kompilieren und einsetzen können. 

Stell dir vor, du willst den usb-vibrator deiner freundin am die nslu2 anschliessen und stellst fest, dass deine distribution den treiber für den vibrator garnich in den kernel eingebaut hat und du auch kein modul dafür runterladen kannst..  :Smile: 

 *Quote:*   

> Wozu sind denn eigentlich denn die Patches gut?

 Mit zunehmenbder Kernelversion werden sie immer unwichtiger, da einige sachen in den offiziellen vanillakernel einzug erhalten haben. Nichts desto trotz bekommst du die slug noch nich mit nem standardkernel zum laufen  :Sad:  für etliche hardware brauchst du die patches einfach. 

 *Quote:*   

> Oh man, ich bin manchmal so doooof. Kann es sein das ich die Patches auch auf einen Aktuellen Kernel anwenden kann? Wohl schon, oder? Oh man!

 

Jein.. Schau dir ma den Link an, den ich dir oben gegeben habe: manche patches sind wirklic für alle versionen die gleichen. Andere sind versionsspezifisch. 

Wie gesagt: wenn du es geschafft hast, ohne python, monochrome und den ganzen bitbake scheiss nen >=2.6.16 mit passendem ixp4xx treiber zu backen, schreibs für die nachwelt nieder  :Smile: 

gruß

----------

## nic0000

 *chilla wrote:*   

> findest, kann ich dir sagen: http://nslu.cvs.sourceforge.net/nslu/kernel/

 Danke, ich habe es nicht gefunden  :Sad: 

 *chilla wrote:*   

> wenn du dahinter gekommen bist, kannst es ja ma kurz aufschreiben. 

 Werde ich machen  :Smile: 

 *chilla wrote:*   

> So nen scheiss macht man, wenn man debian benutzt oder anderweitige probleme psychosozialer herkunft hat  

 *rotf* Debian nein, aber das andere schon  :Wink: 

 *chilla wrote:*   

> Klar kann man das, und ich glaube, das funzt auch. Aber nichts desto trotz willst du deinen kernel mit deiner config inden quellen vorliegen haben, kompilieren und einsetzen können.  

 Das geht dann aber immer noch. Kernel bauen, Modul von openslug zu den anderen Modulen von den neuen Kernel packen, in der   /etc/modules.autoload.d/kernel-2.6 kernelmodul eintragen. Das ist der Plan, und hat eigentlich immer so funktioniert. (habe ich aber schon sehr lange nicht mehr gemacht)

 *chilla wrote:*   

> Stell dir vor, du willst den usb-vibrator deiner freundin am die nslu2 anschliessen und stellst fest, dass deine distribution den treiber für den vibrator garnich in den kernel eingebaut hat und du auch kein modul dafür runterladen kannst.. 

 Wirklich, das währe eine Katastrophe. Ich müsste mir wieder etwas anhören, Viagra kaufen gehen usw. Welch ein Aufwand, du hast mich überzeugt, ich fange sofort an Kernelentwickler zu werden  :Wink: 

 *chilla wrote:*   

> Nichts desto trotz bekommst du die slug noch nich mit nem standardkernel zum laufen  für etliche hardware brauchst du die patches einfach.

 Schade, klingt mal wieder zu kompliziert für mich. 

 *chilla wrote:*   

> Jein.. Schau dir ma den Link an, den ich dir oben gegeben habe: manche patches sind wirklic für alle versionen die gleichen. Andere sind versionsspezifisch. 

 Das mache ich.

 *chilla wrote:*   

> Wie gesagt: wenn du es geschafft hast, ohne python, monochrome und den ganzen bitbake scheiss nen >=2.6.16 mit passendem ixp4xx treiber zu backen, schreibs für die nachwelt nieder 

 Wie gut das der Vibrator meiner Frau keine USB Treiber braucht  :Wink: 

EDIT:

Oh man ist das kompliziert, es werden ja immer mehr patches  :Sad: 

@chilla

Sage mal, wann kommst du denn wieder an deine .config ran?

Kannst du mir irgendwo auch deine gepatchten sources zum download stellen?

----------

## chilla

Jau kann ich dir gleich geben.. wenn ich linux gebootet habe.  :Smile: 

edit: soo.. http://nyrbs.de/~chilla/projekte/NSLU2/files/  die kernelconfig steht drin.

 *Quote:*   

> Oh man ist das kompliziert, es werden ja immer mehr patches 
> 
> @chilla
> 
> Sage mal, wann kommst du denn wieder an deine .config ran?
> ...

 

Kein Stress. Die Jungs haben für jede kernelversion eine "series" datei dazu gelegt. Damit kannst du den kernel ganz einfach patchen:

wart ma.. ich probier gerade was aus.. kann sein, dass du den ganzen mist da garnich mehr machen musst. Obs funzt schreib ich dir in ner halben stunde

----------

## chilla

So.. isn n bisschen mehr als ne halbe stunde..  :Smile: 

Du kannst dir sogar nen 2.6.17er kernel bauen. 

Über svn besorgst du dir den ganzen scheiss:

```
mkdir kerneltest

cd kerneltest

svn http://svn.nslu2-linux.org/svnroot/kernel/
```

Dann wechselst du da rein und editierst die makefile, dass der obere teil so aussieht:

```
     22 #ENDIAN = l

     23 ENDIAN = b

     24 MAJORVER = 2.6

     25 BASEVER  = 2.6.17

     26 MINORVER = 2.6.17

     27 PATCHVER = 2.6.17

     28 REVISION := $(shell sed -e 's/-git.*//' patches/${PATCHVER}/KERNEL)

     29 SNAPSHOT := $(shell cat patches/${PATCHVER}/KERNEL)

     30

     31 MADWIFIVER = r1503-20060415

     32

     33 ifeq (${ENDIAN},b)

     34 DEBIAN_ARCH = armeb

     35 else

     36 DEBIAN_ARCH = arm

     37 endif

     38

     39 KERNEL_SOURCE   = http://kernel.org/pub/linux/kernel/v${MAJORVER}/linux-${BASEVER}.tar.bz2

     40 KERNEL_PATCH    = http://kernel.org/pub/linux/kernel/v${MAJORVER}/testing/patch-${REVISION}.

        bz2

     41 KERNEL_SNAPSHOT = http://kernel.org/pub/linux/kernel/v${MAJORVER}/snapshots/patch-${SNAPSHOT

        }.bz2

     42

     43 MADWIFI_SOURCE   = http://snapshots.madwifi.org/madwifi-ng/madwifi-ng-${MADWIFIVER}.tar.gz

     44

     45 #CROSS_COMPILE = ${DEBIAN_ARCH}-linux-gnu-

     46 CROSS_COMPILE ?= ${DEBIAN_ARCH}-softfloat-linux-uclibc-

```

also eigentlich nur endianess und cross_compile ändern. 

Dann versuchst du es einfachmal mit "make". Der kernel sollte bauen. Er wird wegen 3 dateien fragen, die du dir von intel runterladen musst... ich hab die namen und links an dem rechner hier gerade nich.. google einfach danach, und du wirst sie sofort finden. Beachte aber dabei, dass du glaube ich die erste datei von BSD_blabla nach IPL_blabla umbenennen musst. alle dateien die du brauchst stehen auf einer bestimmten seite von intel. wie gesagt: über google findest du das sofort. Die haust du dann einfach in den ordner "downloads".. (was du auch siehst, weil er rummeckert, dass er die dateien in dem ordner nich finden können wird) und dann kannst du dein "make" einfach nochmal ausführen. Er macht immer bei dem schritt weriter, wo er vorher aufgehört hat. 

Somit solltest du zu einem guten 2.6.17 kommen. Die kernelconfig ist jedoch scheisse. Du brauchst ne angepasst Commandline für den kernel, damit er rafft, dass du von sda1 booten sollst und ausserdem brauchst du ext3 fest im kernel drin... (es sei denn, dene / is ne ext2, was aber scheiss egal is, denn auch ext2 is als modul in dem kernel drin) hmm ausser natürlich, du machst das ganze über ne initrd, die in nem jffs2 image im ram liegt. das wär so ziemlich das beste... aber auch irgendwie aufwendig ^^  :Smile:  dafür musst du nachdem du den kernel einmal komplett gebaut hast mal in das kernelverzeichnis linux-2.6.17 wechseln und dort ein "make ARCH=arm CROSS_COMPILE=armeb-softfloat-linux-uclibc- menuconfig" absetzen, damit du dir den kernel erstmal richtig zusammenfuchteln kannst.  

danach wieder einfach nur im Hauptverzeichnis make ausführen - oder eben selbst mal nen blick in die Makefile werfen, denn dort steht  auchnoh etlicher anderer mist rum. 

Viel spass beim experimentieren.. und falls du was rausbekommst: aufschreiben!  :Smile: 

----------

## nic0000

 *chilla wrote:*   

> So.. isn n bisschen mehr als ne halbe stunde.. 

 Ehehe

Sagemal muss ich das ganze auf der nslug machen oder auf meiner workstation?

Ich habe bis jetzt alles auf der nslug gemacht weil die crosscompile geschichte nicht laufen will und ich eh alles auch darauf machen konnte (nachdem ich ersteinmal einen kleinen Wiederstand ausgelötet habe  :Wink: ).

Sage mal wo hast du denn eigentlich die ganze Infos her, ich google mir einen arm ab und finde nichts gescheites...

EDIT:

OK, ich ahne es schon: Auf meiner Workstation

----------

## chilla

 *Quote:*   

> EDIT:
> 
> OK, ich ahne es schon: Auf meiner Workstation

 hrhr  :Very Happy:  Ja, ich mach sowas auf meinem Desktoprecher. Geht einfach fixer und den kernel flash ich sowieso von meinem desktoprechner per upslug2 auf die nslu. 

Das crosscompilezeugs muss dafür natürlich laufen... woran hängts denn?

Man kann das ganze zeug auch nativ auf der slug machen. Wenn du die slug alles selbst machen lässt, wirds jedoch sehr langsam. die normalen pakete aus portage baue ich auchalle nativ auf der slug, wie eben auf nem normalen rechner auch. Allerdings hab ich dafür auf 2 anderen arbeitsplatzrechnern und einem zusätzlichen laptop hier im netzwerk nen distcc-crosscompiler eingerichtet. So läuft zwar gentoo auf der slug, aber die eigentlich kompilierarbeit läuft auf anderen schnelleren maschinen ab - es sei denn, die sind nicht online, dann baut meine slug eben selbst. Merken tu ich davon nichts - ausser eben an der geschwindigkeit. Crossdev + distcc ist eine sehr feine sache.

 *Quote:*   

> Sage mal wo hast du denn eigentlich die ganze Infos her, ich google mir einen arm ab und finde nichts gescheites... 

 

Lass dich in #gentoo-embedded und in #openslug im freenode blicken, dann bleibst du auf dem laufenden  :Smile: 

Mit den Kernelpatches is eigentlich alles dafür getan, dass jeder auf seiner nslu2 ein richtig geiles voll funktionsfähiges linzux laufen lassen kann. Die jungs haben richtig gute arbeit geleistet. Das entscheidende, was fehlt ist die dokumentation, damit die leute einfach n bisschen googlen und dann auf die gewünschten ergebnisse kommen können. Die leute sind einfach zu faul, ihre sachen niederzuschreiben  :Sad:  Daher hab ich auch sehr lange gebraucht, um gentoo auf der nslu2 lauffähig zu bringen, weil ich von der ganzen sache eigentlich garkeine ahnung hatte.

----------

## nic0000

OK, ich habe jetzt mal versucht das umzusetzen. 

Da ich keine Cross-Dev habe, mache ich es nativ auf der NSLU. 

Subversion auf der NSLU brauche ich nicht wirklich, daher benutze ich für diesen Teil einen 

Host mit Subversion:

```
svn checkout http://svn.nslu2-linux.org/svnroot/kernel/
```

Dabei mache ich auch gleich die Änderungen...

```
mcedit kernel/trunk/Makefile

22 #ENDIAN = l 

23 ENDIAN = b 

45 #CROSS_COMPILE = ${DEBIAN_ARCH}-linux-gnu- 

46 CROSS_COMPILE ?= ${DEBIAN_ARCH}-softfloat-linux-uclibc- 

tar cjvf kernel.tar.bz2 kernel 

scp kernel.tar.bz2  root@192.168.11.11:/mnt/gentoo/
```

Auf der NSLU...

 ...wartet schon im chroot unter /mnt/gentoo eine Gentoo installation.

```
screen

tar xvjf kernel.tar.bz2

cd kernel/trunk/Makefile

make
```

Die Kiste fängt alles schön zu downloaden, patchen und bauen an. 

Wenn irgendetwas anhält dann Ursache lesen und wenn möglich beheben und den Vorgang neu starten. (Manchmal bleibt er auch so stehen, beim nächsten versuch klappt es dann) 

Die von Chilla erwähnten Dateien, welch von Intel per Hand besorgt werden sollen, habe ich noch nicht holen müssen daher noch keine Info, die kommt später.

EDIT:

Nach dem installieren der Kernelmodule beschwert sich make das devio nicht da ist.

devio ist durch "~arm" maskiert 

```
echo "=sys-block/devio-1.2">>/etc/portage/package.keywords

emerge devio 
```

Jetzt geht es los mit dem Dateien von Intel

 *Quote:*   

> http://downloadfinder.intel.com/scripts-df-external/Detail_Desc.aspx?agr=Y&DwnldID=10146&ProductID=2100

 

Im Kasten: "Intel® IXP400 Software Access Library - Version 2.1"

"Intel Hardware Access Software" unter "Download" in der "Version 2.1 " runterladen (Die Version 2.1.1 Funktioniert noch nicht)

Und darunter den "NPE Microcode" in der gleichen Version runterladen

Die Datei lässt sich nicht per wget abholen da ja die Lizenz usw. bestätigt werden wollen.

Also via Lieblingsbrowser (Konqueror bie mir) den Kram auf die Platte der Workstation holen und anschließend per scp auf die NSLU übertragen:

```
scp IPL_ixp400NpeLibrary-2_1.zip root@192.168.11.11:/mnt/gentoo/kernel/trunk/downloads/

scp BSD_ixp400AccessLibrary-2_1.zip root@192.168.11.11:/mnt/gentoo/kernel/trunk/downloads/IPL_ixp400AccessLibrary-2_1.zip
```

Dabei bennen wir die "BSD_ixp400AccessLibrary-2_1.zip" in "IPL_ixp400AccessLibrary-2_1.zip" um.

jetzt ein make und es fällt auf das unzip fehlt, also

```
emerge app-arch/unzip
```

behebt dieses Problem.

Jetzt wieder ein "make" welches die Intel-Sachen durchrattert aber bei 

```
trunk # make

( . ixp400_xscale_sw/buildUtils/environment.linux.sh ; \

  export KERNEL_DIR=`pwd`/linux-2.6.17 ; \

  export IX_XSCALE_SW=`pwd`/ixp400_xscale_sw ; \

  export IX_TARGET=linuxbe ; \

  make -C ixp400_xscale_sw ARCH=arm \

    CROSS_COMPILE=armeb-softfloat-linux-uclibc- ixp400.ko )

make[1]: Entering directory `/kernel/trunk/ixp400_xscale_sw'

make[1]: *** No rule to make target `ixp400.ko'.  Stop.

make[1]: Leaving directory `/kernel/trunk/ixp400_xscale_sw'

make: *** [lib/modules/2.6.17/kernel/drivers/ixp400/ixp400.ko] Error 2
```

aussteigt  :Sad: 

Chilllaaaaaa!!!!

----------

## nic0000

Also ich habe jetzt den Kernel noch mal mit der config von chilla erstellt (JA, "oldconfig" hatte ich gemacht!), es nützt aber nichts, es bleibt an der selben Stelle hängen  :Sad: 

Mit dem Makefile komme ich nicht klar, alles schei*se  :Sad:  *frust*

Chillaaaaa!!! Hilfeeeeee!!!!  :Wink: 

P.S.

Wenn viele rufen dann kommt der Chilla vielleicht schneller raus...

EDIT:

```
 # less buildUtils/environment.linux.sh

# Change the following line to point to your linux kernel source tree

linuxbe_KERNEL_DIR=/path/to/the/be/os/linux-2.4

linuxle_KERNEL_DIR=/path/to/the/le/os/linux-2.4

# Change the following line to point to the root of your Monta Vista install

HARDHAT_BASE=/opt/montavista/pro

# You may want to edit the following to point to your ixp400_xscale_sw

# directory. Otherwise you must source this file from that directory.

IX_XSCALE_SW=/path/to/the/ixp400_xscale_sw

PATH=/usr/bin:$HARDHAT_BASE/host/bin:$HARDHAT_BASE/devkit/arm/xscale_be/bin:$HARDHAT_BASE/devkit/arm/xscale_le/bin:$PATH

#NOTE: All flag definitions below are case sensitive

# For IXDP425 platform, set IX_DEVICE to ixp42X

# For IXDP465 platform, set IX_DEVICE to ixp42X or ixp46X

IX_DEVICE=ixp42X

# For IXDP425 platform, set IX_PLATFORM to ixdp42x

# For IXDP465 platform, set IX_PLATFORM to ixdp46x

IX_PLATFORM=ixdp42x

# For Big endian, set IX_TARGET to linuxbe

# For Little endian, set IX_TARGET to linuxle

IX_TARGET=linuxbe

export linuxbe_KERNEL_DIR linuxle_KERNEL_DIR HARDHAT_BASE IX_XSCALE_SW PATH IX_DEVICE IX_PLATFORM IX_TARGET

```

Keine Ahnung aber vielleicht muss hier etwas eingestellt werden?

----------

## chilla

hmm das is komisch.. 

Ich will dich ja wirklich zu nichts drängen, was du nicht wirklich möchtest, oder was dir irgendwie unangenehm sein könnte. Und du solltest es auch nur tun, wenn du es wirklich willst und dich dafür bereit fühlst. Du bist erwachsen und kannst das tun wenn du möchtest. Wenn es dir wehtut kannst du ja sofort aufhören, niemand wird dich dafür auslachen. 

Aber wenn du es wirklich möchtest, dann sag dochmal, warum du beim erstellen einer crosscompileumgebung auf deinem Arbeitsplatzrechner keien Erfolg hast. Denn nicht nur die Wartezeiten machen das ganze extrem unangenehm, nein, es kann auch sein, dass der gcc das teil auf arm einfach nich kompilieren will. ich habs ehrlichgesagt noch nich ausprobiert. Kannst du noch ein bisschen mehr von dem output vorher hierrein posten?

Gruß

----------

## nic0000

 *chilla wrote:*   

> hmm das is komisch.. 

 

Komisch finde ich das nicht  :Sad: 

Der beschwert sich das er keine Regel findet dieses *.ko Modul zu bauen. Ich kenne mich aber zu wenig aus um da jetzt noch ernsthaft etwas unternehmen zu können. Ich habe mir die Makefiles angeschaut aber nichts gefunden...

 *chilla wrote:*   

> Ich will dich ja wirklich zu nichts drängen, was du nicht wirklich möchtest, oder was dir irgendwie unangenehm sein könnte. Und du solltest es auch nur tun, wenn du es wirklich willst und dich dafür bereit fühlst. Du bist erwachsen und kannst das tun wenn du möchtest. Wenn es dir wehtut kannst du ja sofort aufhören, niemand wird dich dafür auslachen. 

 Du solltest eine Selbsthillegruppe anführen  :Wink: 

 *chilla wrote:*   

> Aber wenn du es wirklich möchtest, dann sag dochmal, warum du beim erstellen einer crosscompileumgebung auf deinem Arbeitsplatzrechner keien Erfolg hast. 

 Weil der Dildo meiner Frau... Nein, Scherz bei Seite, Ernst in die Ecke.  :Smile: 

Ich habe es einmal wie in (d)einer Beschreibung beschrieben versucht und es ist wegen etwas abgebrochen und wollte nicht weitermachen. Dann habe ich noch gelesen das es damit ständig nur Probleme gibt und das eh viele kein Erfolg haben bzw. nativ es dann doch ging. Also deshalb meine Neurose in bezug auf die krasse crosscompileumgebung.

 *chilla wrote:*   

> Denn nicht nur die Wartezeiten machen das ganze extrem unangenehm, nein, es kann auch sein, dass der gcc das teil auf arm einfach nich kompilieren will. ich habs ehrlichgesagt noch nich ausprobiert. Kannst du noch ein bisschen mehr von dem output vorher hierrein posten?

 naja, das ist alles. Er währt nach dem Kernel bauen alle Modulle an die richtige stelle und dann kommt direkt auch das was ich da gepostet habe. Wenn ich nur ein make absetze kommt dann nur noch das. Was er will verstehe ich, nur helfen kann ich ihm nicht. Das hat dann auch nichts mit dem gcc zu tun sondern ehe mit dem Makefile (ich sollte aber nicht zu sehr etwas erklären wollen was ich selbst nicht verstehe)  :Smile: 

Juppi, der Chilla ist wieder da!!! Alles wird gut!

Ich versuche jetzt auch tapfer zu sein und baue eine crosscompileumgebung.

----------

## chilla

 *Quote:*   

> Nein, Scherz bei Seite, Ernst in die Ecke.

 

Kopf -> Tisch!

 *Quote:*   

> Ich habe es einmal wie in (d)einer Beschreibung beschrieben versucht und es ist wegen etwas abgebrochen und wollte nicht weitermachen. Dann habe ich noch gelesen das es damit ständig nur Probleme gibt und das eh viele kein Erfolg haben bzw. 

 

Errmmm... Und einmal, im Ferienlager....  :Smile: 

Daran is wirklich nichts besonderes. Versuch einfach ma ein  "crossdev -t armeb-softfloat-linux-uclibc". Eigentlich solltest du damit keine Probleme haben.

----------

## nic0000

 *chilla wrote:*   

> Errmmm... Und einmal, im Ferienlager.... 

 

 *chilla wrote:*   

> Daran is wirklich nichts besonderes. Versuch einfach ma ein  "crossdev -t armeb-softfloat-linux-uclibc". Eigentlich solltest du damit keine Probleme haben.

 

Ja, es hat geklappt (Was habe ich denn eigentlich vorher gemacht??)

```
 # crossdev -t armeb-softfloat-linux-uclibc

-----------------------------------------------------------------------------------------------------------------------------------------------------------

 * Host Portage ARCH:     x86

 * Target Portage ARCH:   arm

 * Target System:         armeb-softfloat-linux-uclibc

 * Stage:                 4 (C/C++ compiler)

 * binutils:              binutils-[latest]

 * gcc:                   gcc-[latest]

 * headers:               linux-headers-[latest]

 * libc:                  uclibc-[latest]

 * PORTDIR_OVERLAY:       /usr/local/portage

 * PORT_LOGDIR:           /var/log/portage

 * PKGDIR:                /usr/portage/packages/cross/armeb-softfloat-linux-uclibc

 * PORTAGE_TMPDIR:        /var/tmp/cross/armeb-softfloat-linux-uclibc

  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~

 * Forcing the latest versions of binutils-config/gcc-config ...                                                                                     [ ok ]

 * Log: /var/log/portage/cross-armeb-softfloat-linux-uclibc-binutils.log

 * Emerging cross-binutils ...                                                                                                                       [ ok ]

 * Log: /var/log/portage/cross-armeb-softfloat-linux-uclibc-gcc-stage1.log

 * Emerging cross-gcc-stage1 ...                                                                                                                     [ ok ]

 * Log: /var/log/portage/cross-armeb-softfloat-linux-uclibc-linux-headers.log

 * Emerging cross-linux-headers ...                                                                                                                  [ ok ]

 * Log: /var/log/portage/cross-armeb-softfloat-linux-uclibc-uclibc.log

 * Emerging cross-uclibc ...                                                                                                                         [ ok ]

 * Log: /var/log/portage/cross-armeb-softfloat-linux-uclibc-gcc-stage2.log

 * Emerging cross-gcc-stage2 ...                                                                                                                     [ ok ]

```

So soll das doch aussehen, oder?

----------

## nic0000

Es kann sein das "quilt" das Problem ist,  das wenn es nicht installiert ist er zwar deshalb aussteigt aber später nicht wieder versucht???

So ich musste wieder 2 Ornder Löschen und dann ging es weiter. Jetzt musste ich noch dieses File "GPL_ixp400LinuxEthernetDriverPatch-1_5.zip" dowloaden 

http://downloadfinder.intel.com/scripts-df-external/Detail_Desc.aspx?agr=N&DwnldID=9519&ProductID=2100&lang=deu

Und am Ende sollte ich doch Siegreich sein!!!

Ich halte jetzt das selbstkompillierte "ixp400_eth.ko" in meinen Händen!

Danke euch allen, besonders dir Chilla! Ohne deine Hilfe währe ich nie so weit gekommen...

...und nun zurück in der harten Realität. Mal gucken ob das Modul funzt  :Wink: 

Du chilla, kannst mal die aktuelle Konfig rüberschieben?

btw. Warum benutzt du eigentlich keinen I/O scheduler?

EDIT:

Irgendwie will jetzt der Kernel nicht rüber:

```
$ upslug2 --kernel=/home/nico_berlin/gentoo/openslug/selfmade/vmlinuz-nslu2-2.6.17

NSLU2     00:14:bf:66:71:39 Product ID: 1 Protocol ID: 0 Firmware Version: R23V63 [0x2363]

/home/nico_berlin/gentoo/openslug/selfmade/vmlinuz-nslu2-2.6.17: file too large or too small: fatal error [N10NSLU2Image9FileErrorE]
```

Das Compillieren des Kernels klappt immer, aber beim backen des Moduls hat er Fehler. Das Merkwürdige ist das selbst wenn ich die .config wieder zurücksetze, der Fehler bleibt.

Irgendwie bin ich schon Müde und komme nicht weiter...

Chillllaaaaaa!!! Wach auf!!  :Very Happy: 

EDIT2:

Gibt es einen Hack den 1Mb Kernelsize Limit zu umgehen?

Irgendwie kriege ich nicht alles rein in das Teil was ich brauche :-/

Ich will ein Raid1 Verbund darauf fahren *fuessenstampf*

----------

## chilla

Nimm das ixp-modul so wie es is, sicher es dir und gut is. Mach am besten garnixmehr dran  :Smile: 

Ja.. du kannst den kernel deswegen nich flashen, weil er eben nunmal zu groß ist. Die linksys hat glaub ich 8 mb flash. Der flash is aufgeteilet in mehrere partitionen. In Partition 2 liegt der kernel. Und diese Partition ist nunmal leider nur 1mb groß.  :Sad: 

Aber das macht ja eigentlich garnix. Den relevanten Kernel bekommst du so klein und alles andere kannst du als Module bauen. geh dazu erstmal in das Verzeichnis, wo deine Makefile liegt und dann ins "linux-2.6.17" rein (Auf deinem Arbeitsplatzrechner). 

Hier musst du jetzt eh erstmal deinen Kernelumbauen. Denn das, was da gebaut wurde is ein Monsterkernel... der jedooch weder ext3 noch ext2 fest drin hat - das is doof  :Wink:  Der Kernel is darauf ausgelegt, dass du die nslu2 ohne platte betreibst. Das willst du ja jedoch garnich.  Denk dran, deinen crosscompiler zu verwenden: Wenn du auf deinem x86 Desktoprechner irgendwas am kernel machst, musst du dies nun immer so tun:

```
 make ARCH=arm CROSS_COMPILE=armeb-softfloat-linux-uclibc-  menuconfig
```

Frag mich nich nachdem warum  :Wink: 

Nuja.. führ also mal dein menuconfig aus und bau dir den kernel ein bisschen gescheiter zusammen. Achte darauf, dass ext2 oder 3, jeh nachdem, was den /-fs ist fest einkompiliert is. Und nehm evt. noch n bisschen was ausdem Kernel raus, damit du auf die entsprechende größe kommst. Module kannst du ruhig drin lassen, auch wenn du die meisten garnich brauchen wirst. 

danach gehst du wieder ins Hauptverzeichnis und baust das teil neu. Sicher dir deine erstelle kernelconfig irgendwohin.. am besten bevor du baust.

----------

## chilla

ach ja.. was mir gerade noch einfällt: Der redboot bootloader führt den Kernel ja ohne parameter aus, daher musst du ihm noch die parameter fest einkompilieren. Trag dafür einfach in die config das entsprechende zeug ein:

 *Quote:*   

> CONFIG_CMDLINE="console=ttyS0,115200,8n root=/dev/sda1 rootfstype=ext3 rootdelay=15 noirqdebug mem=32M@0x00000000 re        boot=s x1205.hctosys=1"

 

----------

## nic0000

So da bin ich wieder  :Smile: 

 *chilla wrote:*   

> Trag dafür einfach in die config das entsprechende zeug ein:
> 
>  *Quote:*   CONFIG_CMDLINE="console=ttyS0,115200,8n root=/dev/sda1 rootfstype=ext3 rootdelay=15 noirqdebug mem=32M@0x00000000 re        boot=s x1205.hctosys=1" 

 Hatte ich gemacht, aber leider hängt mein Kernel irgendwo  :Sad: 

Ich komme nicht dahinter was es sein könnte, denn die Platte rührt als wenn der boot erfolgreich währe. Die oberste Lampe bleibt leider Rot und ich kann nicht übers Netz drauf. Auf das Netzwerk reagiert die LED drunter, wird wohl aber ein Reflex sein.

Naja, so eine Serielle Konsole währe ja schon ganz fein, wo kann man das billig kaufen bzw. ein Fertiges Kabel schnell mal umbauen. Habe keine Lust alles selbst zu Löten.

Ansonsten habe ich in die /etc/conf.d/local.start paar Zeilen reingeschreiben aber das ist wohl schon zu spät, denn da kam nichts auf die Platte. 

Noch Vorschläge?

----------

## Vollkorn

Moin,

bin auch mal wieder dabei mit meiner Slug zu kämpfen. Inzwischen habe ich ein little-endian armeb-softfloat-linux-gnu System, doch ein Detail fehlt noch: Der Kernel ;)

Also habe ich folgendes gemacht:

```
svn co http://svn.nslu2-linux.org/svnroot/kernel/

make ARCH=arm CROSS_COMPILE=armeb-softfloat-linux-gnu-
```

mein kernel/trunk/downloads sieht so aus:

```
jan trunk # ls -lah downloads/

insgesamt 44M

drwxr-xr-x  2 root root  4,0K 12. Jul 04:02 .

drwxr-xr-x 10 root root  4,0K 12. Jul 12:20 ..

-rw-r--r--  1 jan  users  25K 12. Jul 04:01 BSD_ixp400AccessLibrary-2_1_1.zip

-rw-r--r--  1 root root  2,3M 12. Jul 00:13 BSD_ixp400AccessLibrary-2_1.zip

-rw-r--r--  1 root root   30K 12. Jul 00:13 GPL_ixp400LinuxEthernetDriverPatch-1_5.zip

-rw-r--r--  1 jan  users 2,2M 12. Jul 04:01 IPL_ixp400AccessLibrary-2_1.zip

-rw-r--r--  1 jan  users 165K 12. Jul 04:01 IPL_ixp400NpeLibrary-2_1.zip

-rw-r--r--  1 root root   40M 12. Jul 00:13 linux-2.6.17.tar.bz2

```

Ist das schon alles was man benötigt? Oder fehlt mir vielleicht etwas?

Und mein Fehler ist jener:

```
make[1]: Entering directory `/root/kernel/trunk/ixp400_xscale_sw'

--- Makefile:  Building object file lib/linuxle/qmgr/IxQMgrQCfg.o from C

armeb-softfloat-linux-gnu-gcc -D__KERNEL__ -I/root/kernel/trunk/linux-2.6.17/include -Wall -Wno-trigraphs -fno-common -pipe -msoft-float -DMODULE -Isrc/include -D__linux -DCPU=33 -DXSCALE=33 -D__LINUX_ARM_ARCH__=5 -march=armv5te -Wa,-mcpu=xscale -mtune=xscale  -mabi=apcs-gnu -DIX_NPEDL_READ_MICROCODE_FROM_FILE -DIX_UTOPIAMODE=0 -DIX_MPHY=1 -DIX_MPHYSINGLEPORT -mlittle-endian -DIX_UTOPIAMODE=1 -DNDEBUG -I/root/kernel/trunk/ixp400_xscale_sw/../ixp_osal/ -I/root/kernel/trunk/ixp400_xscale_sw/../ixp_osal/os/linux/include/ -I/root/kernel/trunk/ixp400_xscale_sw/../ixp_osal/os/linux/include/modules/ -I/root/kernel/trunk/ixp400_xscale_sw/../ixp_osal/os/linux/include/modules/ioMem/ -I/root/kernel/trunk/ixp400_xscale_sw/../ixp_osal/os/linux/include/modules/core/ -I/root/kernel/trunk/ixp400_xscale_sw/../ixp_osal/os/linux/include/modules/bufferMgt/ -I/root/kernel/trunk/ixp400_xscale_sw/../ixp_osal/os/linux/include/core/ -I/root/kernel/trunk/ixp400_xscale_sw/../ixp_osal/os/linux/include/platforms/ -I/root/kernel/trunk/ixp400_xscale_sw/../ixp_osal/os/linux/include/platforms/ixp400/ -I/root/kernel/trunk/ixp400_xscale_sw/../ixp_osal/os/linux/include/core/ -I/root/kernel/trunk/ixp400_xscale_sw/../ixp_osal/include/ -I/root/kernel/trunk/ixp400_xscale_sw/../ixp_osal/include/modules/ -I/root/kernel/trunk/ixp400_xscale_sw/../ixp_osal/include/modules/bufferMgt/ -I/root/kernel/trunk/ixp400_xscale_sw/../ixp_osal/include/modules/ioMem/ -I/root/kernel/trunk/ixp400_xscale_sw/../ixp_osal/include/modules/core/ -I/root/kernel/trunk/ixp400_xscale_sw/../ixp_osal/include/platforms/ -I/root/kernel/trunk/ixp400_xscale_sw/../ixp_osal/include/platforms/ixp400/ -I/root/kernel/trunk/ixp400_xscale_sw/../ixp_osal/include/platforms/ixp400/ixp425/ -I/root/kernel/trunk/ixp400_xscale_sw/../ixp_osal/os/linux/include/platforms/ixp400/ixp425/   -D__ixp42X -O2 \

        -Isrc/qmgr/ -Isrc/qmgr/ -Isrc/qmgr  -Isrc/qmgr  -DIX_COMPONENT_NAME=ix_qmgr -DKBUILD_BASENAME=IxQMgrQCfg  src/qmgr/IxQMgrQCfg.c -c -o lib/linuxle/qmgr/IxQMgrQCfg.o

cc1: Fehler: ungültige Option »abi=apcs-gnu«

make[1]: *** [lib/linuxle/qmgr/IxQMgrQCfg.o] Fehler 1

make[1]: Leaving directory `/root/kernel/trunk/ixp400_xscale_sw'

make: *** [lib/modules/2.6.17/kernel/drivers/ixp400/ixp400.ko] Fehler 2
```

Wie habt ihr den Kernel kompiliert? Bei euch nicht so'n Fehler?

Das ganze geschieht auf meinem Desktop mit sauber eingerichteter Cross-Compile-Umgebung.

Gibt's irgendwo ein wenig Doku zu dem Inhalt des Repositories? Ich stochere bei diesem Ding ein wenig im Dunkeln, besonders was die benötigten Dateien angeht etc.

Gruß

Jan

----------

## Vollkorn

Hier habe ich den Hinweis gefunden, dass die Option -mabi=apcs-gnu deprecated ist:

```
http://www.codesourcery.com/archives/arm-gnu/msg00656.html
```

Darum habe ich meinen make-Befehl jetzt so gewählt:

```
make ARCH=arm CROSS_COMPILE=armeb-softfloat-linux-gnu- CFLAGS_ETC=
```

Damit hat der Kernel samt Module auch kompiliert, auch wenn es am Ende solche, m.E. beunruhigende Meldungen gab:

```
WARNING: vmlinux: 'pci_set_consistent_dma_mask' exported twice. Previous export was in vmlinux

WARNING: vmlinux: 'pci_set_dma_mask' exported twice. Previous export was in vmlinux

WARNING: "ixEthAccQMgrRxNotificationDisable" [/root/kernel/trunk/ixp400_eth/ixp400_eth.ko] undefined!

WARNING: "ixQMgrNotificationDisable" [/root/kernel/trunk/ixp400_eth/ixp400_eth.ko] undefined!

WARNING: "ixFeatureCtrlSwConfigurationCheck" [/root/kernel/trunk/ixp400_eth/ixp400_eth.ko] undefined!

WARNING: "ixNpeMhInitialize" [/root/kernel/trunk/ixp400_eth/ixp400_eth.ko] undefined!

WARNING: "ixFeatureCtrlSwConfigurationWrite" [/root/kernel/trunk/ixp400_eth/ixp400_eth.ko] undefined!

WARNING: "ixNpeDlNpeStopAndReset" [/root/kernel/trunk/ixp400_eth/ixp400_eth.ko] undefined!

WARNING: "ixOsalPoolInit" [/root/kernel/trunk/ixp400_eth/ixp400_eth.ko] undefined!

WARNING: "ixEthAccPortInit" [/root/kernel/trunk/ixp400_eth/ixp400_eth.ko] undefined!

WARNING: "ixEthAccPortRxFrameAppendFCSDisable" [/root/kernel/trunk/ixp400_eth/ixp400_eth.ko] undefined!

WARNING: "ixEthAccPortTxFrameAppendFCSEnable" [/root/kernel/trunk/ixp400_eth/ixp400_eth.ko] undefined!

WARNING: "ixEthAccTxSchedulingDisciplineSet" [/root/kernel/trunk/ixp400_eth/ixp400_eth.ko] undefined!

WARNING: "ixEthMiiPhyConfig" [/root/kernel/trunk/ixp400_eth/ixp400_eth.ko] undefined!

WARNING: "ixEthMiiPhyReset" [/root/kernel/trunk/ixp400_eth/ixp400_eth.ko] undefined!

WARNING: "ixEthMiiPhyScan" [/root/kernel/trunk/ixp400_eth/ixp400_eth.ko] undefined!

WARNING: "ixEthAccInit" [/root/kernel/trunk/ixp400_eth/ixp400_eth.ko] undefined!

WARNING: "ixNpeDlNpeInitAndStart" [/root/kernel/trunk/ixp400_eth/ixp400_eth.ko] undefined!

WARNING: "ixEthAccUninit" [/root/kernel/trunk/ixp400_eth/ixp400_eth.ko] undefined!

WARNING: "ixEthDBUnload" [/root/kernel/trunk/ixp400_eth/ixp400_eth.ko] undefined!

WARNING: "ixQMgrDispatcherLoopGet" [/root/kernel/trunk/ixp400_eth/ixp400_eth.ko] undefined!

WARNING: "ixQMgrInit" [/root/kernel/trunk/ixp400_eth/ixp400_eth.ko] undefined!

WARNING: "ixEthAccMibIIStatsGetClear" [/root/kernel/trunk/ixp400_eth/ixp400_eth.ko] undefined!

WARNING: "ixEthAccMiiWriteRtn" [/root/kernel/trunk/ixp400_eth/ixp400_eth.ko] undefined!

WARNING: "ixEthAccMiiReadRtn" [/root/kernel/trunk/ixp400_eth/ixp400_eth.ko] undefined!

WARNING: "ixEthDBFilteringPortMaximumFrameSizeSet" [/root/kernel/trunk/ixp400_eth/ixp400_eth.ko] undefined!

WARNING: "ixEthAccPortTxFrameSubmit" [/root/kernel/trunk/ixp400_eth/ixp400_eth.ko] undefined!

WARNING: "ixEthAccPortDisable" [/root/kernel/trunk/ixp400_eth/ixp400_eth.ko] undefined!

WARNING: "ixEthDBPortAgingEnable" [/root/kernel/trunk/ixp400_eth/ixp400_eth.ko] undefined!

WARNING: "ixEthAccPortEnable" [/root/kernel/trunk/ixp400_eth/ixp400_eth.ko] undefined!

WARNING: "ixEthAccPortRxCallbackRegister" [/root/kernel/trunk/ixp400_eth/ixp400_eth.ko] undefined!

WARNING: "ixEthAccPortUnicastMacAddressSet" [/root/kernel/trunk/ixp400_eth/ixp400_eth.ko] undefined!

WARNING: "ixEthAccPortMulticastAddressJoin" [/root/kernel/trunk/ixp400_eth/ixp400_eth.ko] undefined!

WARNING: "ixEthAccPortMulticastAddressJoinAll" [/root/kernel/trunk/ixp400_eth/ixp400_eth.ko] undefined!

WARNING: "ixEthAccPortPromiscuousModeClear" [/root/kernel/trunk/ixp400_eth/ixp400_eth.ko] undefined!

WARNING: "ixEthAccPortPromiscuousModeSet" [/root/kernel/trunk/ixp400_eth/ixp400_eth.ko] undefined!

WARNING: "ixEthAccPortMulticastAddressLeaveAll" [/root/kernel/trunk/ixp400_eth/ixp400_eth.ko] undefined!

WARNING: "ixEthAccPortTxDoneCallbackRegister" [/root/kernel/trunk/ixp400_eth/ixp400_eth.ko] undefined!

WARNING: "ixEthDBDatabaseMaintenance" [/root/kernel/trunk/ixp400_eth/ixp400_eth.ko] undefined!

WARNING: "ixEthTxFrameDoneQMCallback" [/root/kernel/trunk/ixp400_eth/ixp400_eth.ko] undefined!

WARNING: "ixEthRxPriorityPoll" [/root/kernel/trunk/ixp400_eth/ixp400_eth.ko] undefined!

WARNING: "ixEthAccPortDuplexModeSet" [/root/kernel/trunk/ixp400_eth/ixp400_eth.ko] undefined!

WARNING: "ixEthMiiLinkStatus" [/root/kernel/trunk/ixp400_eth/ixp400_eth.ko] undefined!

WARNING: "ixEthAccPortRxFreeReplenish" [/root/kernel/trunk/ixp400_eth/ixp400_eth.ko] undefined!

WARNING: "ixOsalMbufFree" [/root/kernel/trunk/ixp400_eth/ixp400_eth.ko] undefined!

WARNING: "ixOsalMbufAlloc" [/root/kernel/trunk/ixp400_eth/ixp400_eth.ko] undefined!

WARNING: "ixOsalIrqUnlock" [/root/kernel/trunk/ixp400_eth/ixp400_eth.ko] undefined!

WARNING: "ixOsalIrqLock" [/root/kernel/trunk/ixp400_eth/ixp400_eth.ko] undefined!

make[1]: Leaving directory `/root/kernel/trunk/linux-2.6.17'
```

Trotzdem habe ich lib/ mal auf meine Slug kopiert, den Kernel auf die Slug geflasht und schaue jetzt zu wie nichts passiert ;)

Jemand von euch schon weiter gekommen?

Gruß

Jan

----------

## nic0000

 *Vollkorn wrote:*   

> bin auch mal wieder dabei mit meiner Slug zu kämpfen. Inzwischen habe ich ein little-endian armeb-softfloat-linux-gnu System, doch ein Detail fehlt noch: Der Kernel 

 Ich weiß zwar nicht genau wo du jetzt genau bist, aber lolly war so freundlich mir sein root-fs und kernelimage zur verfügung zu stellen. Das hat auch super geklappt, leider wollte ich mal wieder mehr und habe alles fleissig upgateded. Ende vom Lied ist das es jetzt wieder nicht geht  :Sad: 

Ich hann dir aber das Image von Lolly gerne zur Verfügung stellen wenn du es brauchst. Ist aber ein älterer Kernel.

Ich habe jetzt eine Magen und Scheiß Grippe und bewege mich nicht all zu schnell aber zu not würde ich es machen... *schwitz* *sterb*

----------

## chilla

na gute besserung dir erstmal. 

Also ich versteh ehrlichgesagt nich ganz, wo es bei euch hängt. N 2.6.14er Kernel solltet ihr unter allen Umständen gebaut bekommen. 

Nen 2.6.16er oder gar 17er Kernel bekommt man auch lauffähig gebaut. 

Ihr vergesst bei diesem Makefile, erstmal ne gescheite config zu erstellen. Ne Kernelkonfig für euer Gerät, wo auch das Dateisystem von / fest einkompiliert ist. Das darf maximal 1000kb groß sein. 

Was ich mir auch vorstellen kann is, dass der Euer / nich haben will, weil USB noch nich initialisiert ist. Ein "rootdelay 15" in den fest einkompilierten kernelparametern gibt ihm vorm mounten von / ein bisschen Zeit, die USB-platte erstmal zu finden usw. 

Wenn ihr wollt, könnt ihr mir auch einfach mal euer kernelimage schicken. Ich hab ja ne serielle konsole und kann daherbesser schauen, woran es leigt.

----------

## derm1ke

Hallo zusammen,

verfolge das Thema schon ne Weile und compiliere jetzt schon seit drei Tagen auf der Slug rum.

Was bisher geschah:

OpenSLUG 3.10 geflashed, USB-Harddisk an USB-Port1 ( /dev/sda ), Harddisk partitioniert, Harddisk an Gentoo-Rechner gehangen und alle nötigen Daten drauf, USB-HDD wieder an Slug und mit der Standardinstall begonnen.

Was bisher läuft:

Crosscompile via distcc auf meinen Server.

Aktuell hänge ich am Kernel-Bau.

genkernel läuftnicht ( ok, verständlich )

make menuconfig quittiert mit:

# /usr/lib/gcc/armeb-softfloat-linux-uclibc/3.4.4/../../../../armeb-softfloat-linux-uclibc/bin/ld: scripts/kconfig/conf.o: Relocations in generic ELF (EM: 3)

# scripts/kconfig/conf.o: could not read symbols: File in wrong format

# collect2: ld returned 1 exit status

# distcc[9749] ERROR: compile (null) on localhost failed

# make[1]: *** [scripts/kconfig/conf] Error 1

# make: *** [defconfig] Error 2

den Dienst.

Ebenso der emerge der kernel-headers.

Selbst mit deaktiviertem distcc

Wäre schön, zumindest über diese Hürde zu kommen.

BTW: funktioniert der emerge ipx4xx?

Habe schon das make.profile umgestellt auf 2.6er-Kernel, daher wundert mich das Anmeckern der kernel-sources eigentlich nicht.

Wäre schön, mal ein aktuelles howto zu dem Thema zu finden, da sich ja doch einiges getan hat.

----------

## chilla

naja.. viel hat sich nich geändert. 

Du kannst nach wie vor den 2.6.14er kernel benutzen - ihn nach dem howto auf deinem x86-rechner mit crosscompileumgebung bauen - und dort auch emerge ixp4xx ausführen und das kernelpaket dann auf die slug bratzen. Das funktioniert wie gesagt nach wie vor.

Alles andere ist (noch) nicht dafür gedacht, dass es nativ auf der glug gebaut werden kenn. Bei mir funzt zwar das meiste (mal mit ausnahme des Kernels und den netzwerkkartentreibern) aber meinen Kernel will ich vorerst sowieso nich auf der slug bauen  :Wink: 

----------

## derm1ke

Na juut,

werde gleich mal nen CorssCompile auffem server anstossen.

Melde mich dann mal, wenns geklappt hat.

Das HowTo ist eine sehr gute Anleitung und dieses Forum wirklich eine gute Hilfequelle.

Respekt und Anerkennung.

----------

## derorrim

kann jemand nochmal irgendwo das prepimage script hochladen oder beschreiben was es macht?

ist das der kram den das openskug Makefile gleich miterledigt?

Dane im vorraus, derorrim

----------

## chilla

ja, das macht das Makefile des openslugkernels auch:

```

    168 vmlinuz-nslu2-${REVISION}: vmlinuz-${REVISION}

    169 ifeq (${ENDIAN},b)

    170     devio '<<'$< >$@ \

    171         'wb 0xe3a01c02,4' 'wb 0xe3811055,4' \

    172         'cp$$'

```

in Bash (das prepimagescript) sieht das so aus:

```
chucky linux-2.6.14.3 # cat prepimage

for a in 343 240 034 002 343 201 020 125 ; do echo -n -e "\0$a" >> preimage.bin ; done ; cat preimage.bin zImage > zImage.ok

```

bittesehr

----------

## derorrim

danke seht, so hatte ich mir das auch schon gedacht.

hat sich dann auch erübrigt, da ich den kernel aus dem svn baue und somit das makefile nutze.

im übrigen (für die die es interessiert) hatte ich probleme mit der HEAD revision und hab nu den

aktuellsten TAG für die NSLU ausgecheckt und siehe da, es funktioniert.

Das Makefile von Openslug jungens lönnte etwas besser kommentiret sein, aber ansonsten

ist es kein problem sich damit nen halbwegs aktuellen kernel zusammen zustöpseln.

----------

## Vollkorn

Hi Chilla,

um mal auf dein Angebot zurück zu komme: Kannste mal mein Kernel-Image testen und die Ausgaben auf der seriellen Console posten?

Mein zu debuggender Kernel liegt hier: http://vollkorn.dyndns.org/zImage.swap

Ich befürchte, dass meine Probleme mit dem ganzen little/big-endian-Schmu zusammenhängen. Das habe ich noch immer nicht ausreichend verstanden und leider auch noch keine vernünftige Dokumentation dazu gefunden.

Danke im Voraus

Jan

----------

## nic0000

Wie ich diese Konzerne hasse!

Jetzt hat mal wieder intel seinen ganzen Sche*ß umgestellt und man darf sich wieder Anmelden um die Software herunterzuladen. Vor kurzem war die BSD_ixp400AccessLibrary-2_1_1.zip noch offiziel zugänglich jetzt ist sie wieder verschwunden und stattdessen ist nur die 2_1_2.zip verfügbar. Wo finde ich jetzt den Kram? Jemand eine Idee?

----------

## Vollkorn

Google hat mir diesen Link gegeben: http://wh0rd.org/?C=M;O=A

Sonst gib mal deine Mailadresse per Forum-PN und ich sende sie dir als Anhang.

Gruß

Jan

EDIT: Sonst einfach mal die 2.1.2 in 2.1.1 umbennen, die Änderungen dürften minimal sein. Bugfixes oder so.

----------

## nic0000

 *Vollkorn wrote:*   

> EDIT: Sonst einfach mal die 2.1.2 in 2.1.1 umbennen, die Änderungen dürften minimal sein. Bugfixes oder so.

 Die habe ich auch gefunden aber das es so klein war dachte ich nicht das es sein kann. Trotzdem habe ich es versucht und es hat geklappt um kurze Zeit später hier stehen zu bleiben:

 *Quote:*   

> oMem/ -I/root/kernel/trunk/ixp400_xscale_sw/../ixp_osal/include/modules/core/ -I/root/kernel/trunk/ixp400_xscale_sw/../ixp_osal/include/platforms/ -I/root/kernel/trunk/ixp400_xscale_sw/../ixp_osal/include/platforms/ixp400/ -I/root/kernel/trunk/ixp400_xscale_sw/../ixp_osal/include/platforms/ixp400/ixp425/ -I/root/kernel/trunk/ixp400_xscale_sw/../ixp_osal/os/linux/include/platforms/ixp400/ixp425/   -D__ixp42X -O2 \
> 
>         -Isrc/atmdAcc/ -Isrc/atmdAcc/ -Isrc/atmdAcc -Isrc/atmdAcc -DIX_COMPONENT_NAME=ix_atmdAcc -DKBUILD_BASENAME=IxAtmdDescMgmt  src/atmdAcc/IxAtmdDescMgmt.c -c -o lib/linuxbe/atmdAcc/IxAtmdDescMgmt.o
> 
> make[1]: /opt/montavista/pro/devkit/arm/xscale_be/bin/xscale_be-gcc: Kommando nicht gefunden
> ...

 

Die suche hat das hier ergeben, aber ich weiß wieder nicht weiter.

MP3 encoding on a slug

Läuft bei dir das aktuelle CVS durch?

*edit - Think4UrS11* Überlangen Link repariert

EDIT: Sorry & Dank an Think4UrS11

----------

## Vollkorn

Bei mir kompilierts, aber ich versuche auch ein little-endian System aufzusetzen, daher nicht wirklich vergleichbar.

Trotzdem: Mit welchem Befehl rufst du make auf?

Nativ oder cross compile?

Laut dem Link, den du gegeben hast, ist ein symbolischer Link hilfreich:

```
ln -s armeb-linux-gcc /opt/montavista/pro/devkit/arm/xscale_be/bin/xscale_be-gcc
```

irgendwie kommt mir das aber trotzdem komisch vor. Als ob die Makefile von Intel hardcoded einen bestimmten compiler aufruft...

Gruß

Jan

----------

## nic0000

 *Vollkorn wrote:*   

> Bei mir kompilierts, aber ich versuche auch ein little-endian System aufzusetzen, daher nicht wirklich vergleichbar.

 Ist zwar nicht das Thema, aber ich bin neugierig: Wozu ist das jetzt gut, bzw was ist da jetzt anders?

 *Vollkorn wrote:*   

> Nativ oder cross compile?

 Cross compile. Nativ klappt nicht weil da (zumindest letztes mal, als alles noch lief) bestimme von make geforderte programme sich nicht auf die Schnecke installierten lassen. 

 *Vollkorn wrote:*   

> Laut dem Link, den du gegeben hast, ist ein symbolischer Link hilfreich:

 Ja, nur wo finde ich den "armeb-linux-gcc". ;-(

 *Vollkorn wrote:*   

> irgendwie kommt mir das aber trotzdem komisch vor. Als ob die Makefile von Intel hardcoded einen bestimmten compiler aufruft...

 Jupp, sehr merkwürdig. Anscheinend braucht man jetzt diesen compiler der da beschrieben wurde. Irgendwie wird das wieder sehr kompliziert.

EDIT:

 *Quote:*   

>  # gcc-config -l
> 
>  [1] armeb-softfloat-linux-uclibc-3.4.6 *
> 
>  [2] armeb-softfloat-linux-uclibc-3.4.6-hardenednopie
> ...

  ;-( Finden tue ich aber den "armeb-softfloat-linux-uclibc-3.4.6 " aber auch nicht... Irgendwie fehlt mir die gcc Kompetenz

EDIT2:

gefunden, bin ich blööd

----------

## chilla

 *nic0000 wrote:*   

>  *Vollkorn wrote:*   EDIT: Sonst einfach mal die 2.1.2 in 2.1.1 umbennen, die Änderungen dürften minimal sein. Bugfixes oder so. Die habe ich auch gefunden aber das es so klein war dachte ich nicht das es sein kann. Trotzdem habe ich es versucht und es hat geklappt um kurze Zeit später hier stehen zu bleiben:
> 
>  *Quote:*   oMem/ -I/root/kernel/trunk/ixp400_xscale_sw/../ixp_osal/include/modules/core/ -I/root/kernel/trunk/ixp400_xscale_sw/../ixp_osal/include/platforms/ -I/root/kernel/trunk/ixp400_xscale_sw/../ixp_osal/include/platforms/ixp400/ -I/root/kernel/trunk/ixp400_xscale_sw/../ixp_osal/include/platforms/ixp400/ixp425/ -I/root/kernel/trunk/ixp400_xscale_sw/../ixp_osal/os/linux/include/platforms/ixp400/ixp425/   -D__ixp42X -O2 \
> 
>         -Isrc/atmdAcc/ -Isrc/atmdAcc/ -Isrc/atmdAcc -Isrc/atmdAcc -DIX_COMPONENT_NAME=ix_atmdAcc -DKBUILD_BASENAME=IxAtmdDescMgmt  src/atmdAcc/IxAtmdDescMgmt.c -c -o lib/linuxbe/atmdAcc/IxAtmdDescMgmt.o
> ...

 

Was machst du da? Ich will ja nix sagen.. aber das teil, das du da runtegeladen hast ist die Version für die Linuxdistribution Montavista. 

 :Wink: 

Du benutzt gerade die Makefile von dem ixp4xxtreiber, der für Montavista freigegeben is. Das kannst du aber gleich mal vergessen.. Du solltest wenn, dann die Makefile des aktuellen svn-nslu2-kernels benutzen. Oder passiert das etwa dabei?

----------

## nic0000

 *chilla wrote:*   

> Was machst du da? Ich will ja nix sagen.. aber das teil, das du da runtegeladen hast ist die Version für die Linuxdistribution Montavista. 

 Das erklärt so einiges  :Sad: 

 *chilla wrote:*   

> Du benutzt gerade die Makefile von dem ixp4xxtreiber, der für Montavista freigegeben is. Das kannst du aber gleich mal vergessen.. Du solltest wenn, dann die Makefile des aktuellen svn-nslu2-kernels benutzen. Oder passiert das etwa dabei?

 Ich habe keine Ahnung was ich wieder falsch mache und entschuldige mich schon mal im vorfeld für meine blödheit  :Sad: 

Also ich tue das hier:

```
mkdir /da/wo/schön/ist/

cd /da/wo/schön/ist/

svn checkout http://svn.nslu2-linux.org/svnroot/kernel/
```

denn editiere ich das Makefile unter:

```
mcedit /da/wo/schön/ist/kernel/trunk/Makefile
```

und änder das hier:

 *Quote:*   

> #ENDIAN = l
> 
> ENDIAN = b
> 
> #CROSS_COMPILE = ${DEBIAN_ARCH}-linux-gnu-
> ...

 

dann mache ich ein simples "make" und er backt dann einen Kernel. Dann fragt er nach 2 Dateien

 *Quote:*   

> BSD_ixp400AccessLibrary-2_1.zip
> 
> BSD_ixp400AccessLibrary-2_1_1.zip  

 

Zwischen durch hat das Makefile Probleme denn es merkt nicht das Sachen fehlen. Ich musste die Dateien selbst entpacken.

 *Quote:*   

> IPL_ixp400NpeLibrary-2_1.zip

 

Was mache ich wieder falsch??? ;-( ;-( ;-(

----------

## nic0000

 *nic0000 wrote:*   

>  *Vollkorn wrote:*   Laut dem Link, den du gegeben hast, ist ein symbolischer Link hilfreich: Ja, nur wo finde ich den "armeb-linux-gcc". ;-(

 [/quote]So ich habe es jetzt gefunden und gelinkt aber es kommt dann trotzdem zum abbruch. Wie Chilla schreibt ist das wohl aber eh eine falscher Weg...

```
mkdir -p /opt/montavista/pro/devkit/arm/xscale_be/bin/

cd /usr/bin

ln armeb-softfloat-linux-uclibc-gcc /opt/montavista/pro/devkit/arm/xscale_be/bin/xscale_be-gcc
```

Es bleibt aber nach 2 Metern wieder stecken  :Sad: 

 *Quote:*   

>     CROSS_COMPILE=armeb-softfloat-linux-uclibc-  ixp400 )
> 
> make[1]: Entering directory `/root/kernel/trunk/ixp400_xscale_sw'
> 
> --- Makefile:  Building object file lib/linuxbe/atmdAcc/IxAtmdDescMgmt.o from C
> ...

 

Irgendwie ist da der Wurm drinn. Es redet auch von Kerel 2.4 ???

----------

## Vollkorn

Hi Chilla,

sag mal, welchen seriellen Connector benutzt du für die Slug? Ich habe das Ding auf der italienischen Seite, die im HowTo verlinkt ist, ins Auge gefasst: http://www.picbasic.it/interfacce/page2.html

Das sieht ja schon ganz toll aus, nur kann ich kein italienisch ;)

Hast du irgendwelche Erfahrungen dazu, die du mir zulassen kommen könntest?

Gruß

Jan

----------

## chilla

@vollkorn: ich verbaue maxsense rs232dbh oder wie die dinger heissen. das sind ganz normale ttl2rs232 wandler für 3 volt. Aufpassen, dass du nich die 5 volt version nimmst  :Wink: 

wir benutzen die slug als steuereinheit für einen rfid-reader und eine elektronisch geöffnete türe. Dafür haben wir ne kleine platine entwickelt, die neben dem rs232 chip noch nen pfc chip drauf hat, mit dem wir 230v relais schalten können.  :Very Happy:  Werd ma schauen, was wir für die platine letztendlich bezahlen, wenn wir davon hundert stk abnehme

Das teil macht so spaß  :Very Happy:  Im realen beispiel wird über die realsu n magnet geschaltet, der ne tür öffnet...  Damit kannst du aber auch deinen Staubsauger, die Kaffeemaschine oder die Zimmerlampe ein und ausschalten.. und das ganze einfach mit einem "echo 255 > /sys/bus/i2c/devices/dev-00200blabla/write" - und schon machts klack und das licht geht an  :Smile: 

Dass du das natürlich herrlich kombinieren kannst is klar  :Smile: 

der laptop, der am bett steht, wird benutzt um n bashscript zu starten, welches per ssh auf die slug geht und dort das stromrelais für die kaffeemaschine anschaltet, damit die schonma vorgeheizt ist, wenn man runter kommt  :Smile: 

----------

## nic0000

 *chilla wrote:*   

> @vollkorn .... 

 Schön das ihr euch so gut unterhaltet *gggg*

Aber ich bin auch noch da  :Wink: 

Also ich habe jetzt aus meinen alten Backup die alte CVS rausgekramt. Rev 346 (aktuell ist 354). (Kernel ist aber immer noch 2.6.17)

Hier läuft die Sache so, das beim ersten durchlauf alles glatt läuft und selbst wenn nichts verändert wird steigt das make bei den Intelkram aus.

Ich habe jetzt wieder bisschen rumgespielt um den Fehler einzukreisen.

Also, wenn ich das erste mal starte baut make ein Kernel. Dieser Kernel braucht dann mindenstens noch folgende Anpassung:

 *Quote:*   

> CONFIG_CMDLINE="console=ttyS0,115200,8n root=/dev/sda3 rootfstype=ext3 rootdelay=15 noirqdebug mem=32M@0x00000000 reboot=s x1205.hctosys=1"
> 
> CONFIG_EXT3_FS=y

 

Damit er von dem ext3 Image booten kann. Das funktioniert bei so kleinen änderungen noch, änder ich mehr, dann steigt make wie oben beschriben aus. Ein "oldconfig" auf eine config von chilla oder sonstjemanden hat noch nie funktioniert  :Sad: 

Beim ersten booten findet er mal wieder keine Netzwerkreiber. Ein 

```
depmod -a
```

 behebt den Zustand wieder. Beim nächsten Start findet er wieder das Netzwerkmodul. Allerdings ist das Netzwerk jetzt "net.ieth0" und nicht mehr "net.ixp0" wie beim 2.6.14.3 Kernel.

Allerdings kommen beim booten mehrer Felhlermeldungen:

 *Quote:*   

>  * Setting system clock using the hardware clock [UTC] ...
> 
>  * Cannot access the Hardware Clock via any known method.
> 
> Use the --debug option to see the details of our search for an access method.Cannot access the Hardware Clock via any known method.
> ...

 

Da ich den kernel noch keinen Stück angepasst habe, war das zu erwarten.

 *Quote:*   

> 
> 
>  * Wiping /tmp directory ...                                              [ ok ]
> 
>  * Device initiated services: net.eth0
> ...

  Wieso sich das jetzt vordrängeln will vertsehe ich nicht. Ich habe keinen Parallelstart oder ähnliches aktiviert.

Das ist wichtig und macht mir kopfzebrechen: *Quote:*   

>  * Re-caching dependency info (mtimes differ)...
> 
>  * Could not get dependency info for "net.eth0"!
> 
>  * Please run:
> ...

 Keine Ahnung was da wieder abgeht.

 *Quote:*   

> 
> 
>  * Restoring ixp400 modules... ...cannot stat `/lib/modules/ixp400_drivers/*': No such file or directory
> 
>  * Failed to restore ixp400 modules
> ...

 Da muss wohl etwas angepasst werden. Wohl nicht so schlimm...

Also wenn ich einen "halt" mache geht die Schnecke aus, bei einen "reboot" bleibt sie kurz davor hängen  :Sad: 

Ich kämpfe weiter, wenn jemand eine Idee hat was ich wieder besser machen kann, dann bitte....

----------

## Vollkorn

Hi Nico,

ich wäre froh, wenn meine Slug überhaupt mal den Kernel bootet. Bisher noch nicht ein Anzeichen dafür, dass die Festplatte überhaupt angesprochen wird. Solange ich meine serielle Console noch nicht habe werde ich da auch wenig drüber erfahren. :(

Darum nochmal die Bitte an dich, chilla, meinen Kernel von http://vollkorn.dyndns.org/zImage.swap zu testen und mir die Ausgaben der seriellen Console zukommen zu lassen!

Danke

Jan

----------

## chilla

was is denn die .swap datei?

das soll ein kernel sein? little endian? big endian? oder is das n komplettes abbild deines flashs?

----------

## nic0000

Wir lasen mal den Chilla weiter Fragen stellen und kömmern uns mal selbst um die Sache:

 *Quote:*   

> nico@kubuntu-desktop:~$ cu -l /dev/ttyS0  -s 115200
> 
> Connected.
> 
> +Ethernet eth0: MAC address 00:14:bf:66:71:39
> ...

 

Wenn ddu mich fragst, dann sieht die Sache nicht gesund aus...

----------

## chilla

gnarf.. du pappenheimer..  :Smile: 

das sieht schon gesund aus. Das is ne falsche einstellug vom seriellen port. Hab ich auch hin und wieder mal. Der Kernel bekommt zwar parameter für fden seriellen Port aber der ausgang vom sluggy verschiebt hin und wieder n paar bits, wenn im speicher mist steckt.

----------

## chilla

morgen fahr ich ma wieder ins büro und löt meinen seriell zu ttl-wandler wieder gesund.. mein vogel hat an den pins geknabbert....

----------

## nic0000

 *chilla wrote:*   

> gnarf.. du pappenheimer.. 

  ehehe  :Wink: 

 *chilla wrote:*   

> das sieht schon gesund aus. Das is ne falsche einstellug vom seriellen port. Hab ich auch hin und wieder mal. Der Kernel bekommt zwar parameter für fden seriellen Port aber der ausgang vom sluggy verschiebt hin und wieder n paar bits, wenn im speicher mist steckt.

 Was heisst das jetzt genau? Also sonst funzt die Konsole super, nur bei diesem Kernel kommt dieser Müll. Exakt immer das selbe  :Sad: 

Edit:

Ausserdem und überhaupt, kann mir einer etwas zu meinen Problem sagen?

----------

## Vollkorn

Hi chilla!

Ist ein ganz normaler Kernel, der vom RedBoot-Manager geladen können werden sollte und dann den Prozessor in little-endian umschaltet.

Benenne die Datei sonst einfach um in zImage, war nur zufällig so genannt und hatte dann keine Lust mehr das zu ändern   :Smile: 

Habe mir gerade ein Datenkabel für ein altes Siemens bei ebay ersteigertt und morgen gehe ich diese kleinen Jumperteilchen von Conrad kaufen. Dann wird hier bald gelötet und eine serielle Console eingerichtet!

Gruß

Jan

----------

## nic0000

 *Vollkorn wrote:*   

> Hi chilla!
> 
> Ist ein ganz normaler Kernel, der vom RedBoot-Manager geladen können werden sollte und dann den Prozessor in little-endian umschaltet.
> 
> Benenne die Datei sonst einfach um in zImage, war nur zufällig so genannt und hatte dann keine Lust mehr das zu ändern  
> ...

 

Ich werde wohl nun total ignoriert  :Sad: 

----------

## chilla

 *nic0000 wrote:*   

>  *chilla wrote:*   gnarf.. du pappenheimer..   ehehe 
> 
>  *chilla wrote:*   das sieht schon gesund aus. Das is ne falsche einstellug vom seriellen port. Hab ich auch hin und wieder mal. Der Kernel bekommt zwar parameter für fden seriellen Port aber der ausgang vom sluggy verschiebt hin und wieder n paar bits, wenn im speicher mist steckt. Was heisst das jetzt genau? Also sonst funzt die Konsole super, nur bei diesem Kernel kommt dieser Müll. Exakt immer das selbe 
> 
> Edit:
> ...

 

wat weiss denn ich, was da für n chipsatztreiber für den seriellen port der slug in den kernel einkompiliert wurden.. das kann alles mögliche oder einfach nur n dummer bug sein.

----------

## nic0000

 *chilla wrote:*   

> wat weiss denn ich, was da für n chipsatztreiber für den seriellen port der slug in den kernel einkompiliert wurden.. das kann alles mögliche oder einfach nur n dummer bug sein.

 Das ist zwar nicht mein Problem sondern von Vollkorn aber gut, der Sommer ist heiss und der arme chilla ist wohl gestresst.  :Wink: 

Zurück zu mir und meinen Problem. Ich habe jetzt mittlerweile mit sehr viel Geduld die Schnecke auf einem 2.6.17 Kernel am laufen.

Hat sonst noch jemand ein 2.6.17 Kernel im Einsatz?

Wenn ja dann bitte ich um die config, denn bei mir läuft die Uhr nicht (zumindest habe ich keinen Zugriff drauf). ;-(

Ansonsten handelt es sich um Kleinigkeiten welche ich bald gelöst habe.

----------

## chilla

also um ehrlich zu sein, lief mein 2.6.17er glaub ich tadellos  auch mit der uhr hatte ich keine probleme. 

Da gabs n paarsachen, die du beachten musst.. dieser xtc rttc chip hat noch irgendwelche abhängigkeiten, die nich dokumentiert sind. Schau mal in die i2c-section vom kernel rein. Oder am besten ma auf die platine drauf: http://www.nslu2-linux.org/gallery/nslu2_pcbs/NSLU2_board_front_rev2?full=1

Hier siehst du ganz unten links die led-weiterleitungen. Rechts davon siehst du irgendwo U11.  auf dem Foto is die schrift leider nich zu erkennen und ich hab gerade keine slug hier. Aber schau mal auf deine drauf und guck, was auf diesem chip steht. und dann such im kernel nach treibern für diesen - damit sollte deine uhr auch wieder funen. 

edit: wenn mich ncihalles täuscht, dann nennt sich das teil xtc1205 oder sowas. 

gruß

----------

## nic0000

 *chilla wrote:*   

> also um ehrlich zu sein, lief mein 2.6.17er glaub ich tadellos  auch mit der uhr hatte ich keine probleme. 

 Glückwunsch!

 *chilla wrote:*   

> Da gabs n paarsachen, die du beachten musst.. dieser xtc rttc chip hat noch irgendwelche abhängigkeiten, die nich dokumentiert sind. Schau mal in die i2c-section vom kernel rein. 

 Jupp, habe ich dann auch hinbekommen  :Very Happy: 

 *chilla wrote:*   

> edit: wenn mich ncihalles täuscht, dann nennt sich das teil xtc1205 oder sowas. 

 x1205 (und nicht wieder an die Love Parade denken  :Wink: )

So die Uhr wird beim booten richtig erkannt allerdings beschwert sich "clock" beim starten das es keinen Zugriff auf die Uhr hat ;-(

Liget wohl daran das hwclock auf /dev/rtc sucht und die x1205 aber sich als /dev/rtc0 anmeldet. Ein Symlink auf /dev/rtc -> /dev/rtc0 führt zum stillstand des Skriptes, also auch keine Lösung. Also die Uhr ist jetzt wenigstens beim Booten richtig und "date" liefert aktuelle Ergebnisse, das ich fast keine Lust mehr habe dem nachzugehen. Leider bin ich nun mal ein Pedant und fühle mich nicht gut wenn ich nicht weiß was die Probleme in der Zukunft sein könnten. Mit der Zeit und Unix ist nicht zu spaßen. Wenn fsck die Platte von in der Zukunft liegenden Daten "befreit" währe ich nicht gerade angetan. Ich kämpfe weiter  :Smile: 

----------

## nic0000

So, da bin ich wieder.

Also jetzt habe ich wieder neue Probleme, denn das ixp400_eth modul will sich nicht mehr laden lassen. Es scheint das des auch irgendwelche nicht dokumentierten Abhängigkeiten im Kernel hat. Ein Modul welches ich vorher gebaut habe, ist um paar KB größer und lässt sich mit 

```
modprobe -f ixp400_eth 
```

 manchmal laden. manchmal gibt es dann einen Segfault  :Sad: 

Immerhiin habe ich eine Äbhängigkeit herrausgefunden:

Wenn nicht

 *Quote:*   

> System Type  --->
> 
> Intel IXP4xx Implementation Options  --->
> 
>  [*] XDP465

 Ausgewählt ist, dann bricht der Bau von ixp400_eth mit einen Fehler ab. 

Ich muss jetzt wieder etwas anderes machen, wenn jemand eine funktionierende Kernelkonfig hat dann bitte posten oder per PM.

Was beim mir nicht läuft:

1) hwcklock kann auf die Uhr nicht zugreifen

2) reboot hängt System auf (halt funktioniert gut)

3) ixp400_eth.ko lässt sich nicht laden (Fehler liegt in einer Kernelabhängigkeit)

----------

## linbox

Did anybody else run into a simular problem when they tried to emerge ixp4xx. I tried to compile it with the 2.6.16 kernel source.

Here is the output

```

os/linux/include/platforms/ixp400/ixp425/IxOsalOsIxp425Sys.h:164: error: `IXP4XX_EXP_BUS_CS2_BASE_PHYS' undeclared here (not in a function)

os/linux/include/platforms/ixp400/ixp425/IxOsalOsIxp425Sys.h:164: error: initializer element is not constant

os/linux/include/platforms/ixp400/ixp425/IxOsalOsIxp425Sys.h:164: error: (near initialization for `ixOsalGlobalMemoryMap[4].physicalAddress')

os/linux/include/platforms/ixp400/ixp425/IxOsalOsIxp425Sys.h:172: error: initializer element is not constant

os/linux/include/platforms/ixp400/ixp425/IxOsalOsIxp425Sys.h:172: error: (near initialization for `ixOsalGlobalMemoryMap[4]')

make[1]: *** [lib/ixp425/linux/linuxbe/src/modules/ioMem/IxOsalIoMem.o] Error 1

make[1]: Leaving directory `/var/tmp/portage/ixp4xx-2.1/work/ixp_osal'

make: *** [osal_module] Error 2

!!! ERROR: net-misc/ixp4xx-2.1 failed.

Call stack:

  ebuild.sh, line 1539:   Called dyn_compile

  ebuild.sh, line 939:   Called src_compile

  ixp4xx-2.1.ebuild, line 45:   Called die

!!! failed to build kernel modules

!!! If you need support, post the topmost build error, and the call stack if relevant.

```

any idea

thanks 

guenter

----------

## chilla

 *linbox wrote:*   

> Did anybody else run into a simular problem when they tried to emerge ixp4xx. I tried to compile it with the 2.6.16 kernel source.
> 
> Here is the output
> 
> ```
> ...

 

Think about the Boardname, where you post in and the langeuage you should use there. this is the german board. 

The ixp4xx ebuild only builds against a 2.6.14 (or maybe especially against 2.6.14.3) and only for armeb.

----------

## linbox

tut mir leid mit der Sprache chilla.

Wie kann Ich dann gegen den 2.6.16 kernel die ixp4xx kompalieren?

Ich weis das andere Leute das schon gemacht haben.

Ich habe das kernel image von der Webseite herunter geladen

http://nyrbs.de/~chilla/projekte/NSLU2/

Wie ist das root passwort fuer dieses image?

der Slug booted up Ich kann nur nicht einlogen

Ich habe schon die gaengigen passwoerter versucht 

Ich habe das passwort gefunden "nslu2"

guenter

----------

## chilla

 *linbox wrote:*   

> tut mir leid mit der Sprache chilla.
> 
> 

 Kein Problem. Ich wollte dich nich dumm anmachen, sondern nur drauf hinweisen  :Wink: 

 *linbox wrote:*   

> Wie kann Ich dann gegen den 2.6.16 kernel die ixp4xx kompalieren?
> 
> Ich weis das andere Leute das schon gemacht haben.

 

ja, andere haben es schon gemacht. Aber nicht mit dem ebuild. Zumindest nicht so, dass ich was davon wüsste. Du kannst dir den aktuellen patchset aus dem oben ein paar posts weiter oben beschriebenen svn-repo holen. Dort ist eine makefile dabei, welche dir automatisch das modul zu deinem kernel baut. Damit kannst du auch 2.6.16er bauen.

Vielleicht schreib ich dazu mal eine halbwegs vollständige Anleitung - oder ich biete euch mal nen kompletten kernel zum runterladen an. 

Du verstehst mich?

ich helfe dir auch gerne auf englisch weiter - nur für die allgemeinheit hier erstmal auf deutsch.

----------

## derorrim

wenn ihr alle son stress mit dem kernel habt, dann nehmt doch den von openslug.

der ist fertig kompiliert und die meisten module kann man auch besorgen.

ausserdem muss man bei nem  kernelupdate nur schnell das neue openslug flashen

und gut ist. ich hab auch erst selbst nen kernel gebaut, allerdings ist das mit diesem intel

kram auf dauer stressig.

ich habe noch keinen fall entwickelt in dem der openslug kernel nicht passen lönnte (wenn

man denn die module hat), und er läuft out of the box.

besser wäre noch ein mantainter ebuild für die kernelquellen mit patches etc.

gibts eigentlich neuigkeiten zum htema kernel aus gentoo ändern, ohne upslug?

und wie siehts aus, hat irgendwer mal versucht nen glibc system auf die slug zu knallen?

müsste doch möglich sein. oder?

ich hab nämlich festgestellt das sich viele pakete auf arm nicht kompilieren lassen, zum einen

wegen der architektur, zum anderen wegen ulibc. ist j fast alles hartmaskiert.

viel spass beim kabelfrickeln noch, derorrim

----------

## chilla

 *derorrim wrote:*   

> wenn ihr alle son stress mit dem kernel habt, dann nehmt doch den von openslug.
> 
> der ist fertig kompiliert und die meisten module kann man auch besorgen.
> 
> ausserdem muss man bei nem  kernelupdate nur schnell das neue openslug flashen
> ...

 

Für die openslugkernel gibt es nich alles als module und man kann den kernel nicht nach seinen wünschen anpassen. 

Der Kernel liegt einfach so im mtdblock. Dieser ist mit den entsprechenden Treibern beschreibbar. Somit kann man auch den Kernel ohne upslug aus Gentoo heraus updaten. 

Auf dauer is das mit nem intelkram garnich stressig. Denn wenn man ihn einmal gebaut hat, dann passt das. Und den kernel kann man über menuconfig einfach so ereitern und anpassen wie man möhte. 

glibc geht auf Gentoo -haben schon einige gemacht. Aber ohne ein Speicherupgrade is das betreiben der glibc auf ner 32mbram maschine ganzschön laaahm.

----------

## Vollkorn

derorrim: Ich versuche gerade ein little-ednian glibc gentoo auf meiner Slug zu installieren und hänge am Kernel. dafür lässt sich leider gar nicht der openslug kernel benutzen. Der ist nämlich big-endian :(

Wenn ich das ganze jemals fertig bekomme und ein wenig Zeit habe wird das alles schön auf gentoo-wiki.org dokumentiert :)

Gruß

Jan

----------

## chilla

 *Vollkorn wrote:*   

> derorrim: Ich versuche gerade ein little-ednian glibc gentoo auf meiner Slug zu installieren und hänge am Kernel. dafür lässt sich leider gar nicht der openslug kernel benutzen. Der ist nämlich big-endian 
> 
> Wenn ich das ganze jemals fertig bekomme und ein wenig Zeit habe wird das alles schön auf gentoo-wiki.org dokumentiert 
> 
> Gruß
> ...

 

Sagst du mir mal eben, welche schritte du gegangen bist um dazu zu kommen? 

Welches stagearchiv benutzt du? wie sieht deine make.conf aus?

Den kernel kann ich dir bauen, wenn meine serielle konsole wieder funzt.

----------

## derm1ke

Nachdem ich nun zum vierten Mal probiere, auf der slug alles gegen glibc zu kompilieren reicht es mir.

Ich hätte da die Idee, unter VMware ein generisches ( also für für alle x86 taugliches ) Image zu erstellen, wo man in einer chroot-Umgebung via cross-compiler alles mögliche für die slug kompilieren kann.

Müsste doch eigentlich möglich sein, unter x86 einen kompletten Verzeichnis-Baum aufzubauen, in dem man dann direkt über den Cross-Compiler Sachen bauen kann, oder bin ich da auf dem Holzweg?

Wenn es möglich ist, würde ich mich daran versuchen und das fertige Image zur Verfügung stellen.

Besteht dafür überhaupt Interesse?

----------

## Vollkorn

dermike: Das habe ich bereits versucht und bin an diversen Cross-compile-Problemen unter gentoo gescheitert. Beispielsweise, dass man nicht per Umgebungsvariable das profile festlegen kann. Jedenfalls haben die diversen Probleme und komplexen Zusammenhänge mein Verständnis überstiegen und ich habe aufgegeben. Ist jetzt eine Weile her. Aber generell halte ich es (uind einige Devs auf #gentoo-embedded bzw gentoo-embedded@lists.gentoo.org) für möglich. Nur eben ein etwas steiniger Weg.

Interesse besteht!

chilla: Mein Weg war eine Debian-Installation nach dieser Anleitung http://www.cyrius.com/debian/nslu2/

Und dann nach dem normalen Gentoo-Handbook mit diesem stage3-Archiv: gentoo/experimental/arm/stages/arm/stage3-arm-20040510.tar.bz2

Lief bisher sauber.

Klar, bau mir nen Kernel! M.E. muss an der Config vom SVN nicht viel geändert werden. Nur, dass man little-endian auswählt, das target auf arm-softfloat-linux-gnu stellt und in der .config vom Kernel die Bootparameter anpasst (Bootpartition ist bei mir /dev/hda2, auf hda1 ist das debian) und ext2 fest einkompiliert. Ich hatte dann noch Probleme mit der Option '-mabi=apc-gnu', die vom gcc-3.4.x wohl nicht mehr unterstützt wird und musste in der trunk/ixp400_xscale_sw/Makefile das erste Vorkommnis davon auskommentieren und an das make noch den Parameter 'CFLAGS_ETC=' anhängen, damit der Kernel und die Module kompilieren.

Danke im Voraus

Jan

----------

## derm1ke

na suuper,

jetzt weiss ich, warum ich andauernd das System neu aufsetzen kann:

Nach dem De-Underclocken wird anscheinend das System zu heiss ( zumindest die CPU ist zu heiss zum Anfassen ).

hatte andauernd merkwürdige Verbindungsabbrüche bei SSH-Sessions ( heute war sogar das System nicht mehr anpingbar ).

Hab jetzt mal das Gehäuse weggelassen und werde mal in meiner Grabbelkiste nach nem alten Kühlkörper schauen und den mal draufkleben. Im Gehäuse müsste für nen Passivkühlkörper von ner alten GraKa oder 486er noch Platz sein.

Hoffe nur, daß beim 'Entfernen' des Widerstandes nicht zu rabiat war....

Oder gibt es vielleicht allgemeine Probleme mit der neuesten OpenSlug-Firmware?

Ansonsten werde ich mich doch mal an ner chroot-Umgebung versuchen, vorausgesetzt, daß das Entpacken des Portage-Snapshots nicht schon wieder abbricht auf der Slug.

Übrigens noch ein paar Erfahrungen, die ich gerne teilen möchte:

Ich habe mal die Emerge-Optimierungsmöglichkeiten ausprobiert ( http://de.gentoo-wiki.com/Emerge_beschleunigen ), mit dem Erfolg, daß bei mir nur der Einsatz von python-cdb,ccache und distcc was gebracht haben. Die eix-Empfehlung hat mir letztendlich das System zerschossen, bei nem eix-sync sofort System tot......

----------

## chilla

 *Quote:*   

> Nach dem De-Underclocken wird anscheinend das System zu heiss ( zumindest die CPU ist zu heiss zum Anfassen ). 

 

Macht bei mir keine Probleme. CPU is warm, nicht heiss. 

 *Quote:*   

> hatte andauernd merkwürdige Verbindungsabbrüche bei SSH-Sessions ( heute war sogar das System nicht mehr anpingbar ). 

 Wenn das syste nich mehr anpingbar is, dann ist es tot. (du hast vermutlich keinen seriellen anschluss). 

Aber nur ein Verbindugnsabbruch in einer ssh-session is kein indiz dafür, dass die platine sich verabschiedet hat. Ganz im gegenteil: wenn die verbindung abbricht und du sie kurze zeit später wider herstellen kannst (und wenn dann die uptime trotzdem weitergelaufen ist), dann kannst du dir sicher sein, dass sich die kiste nicht aufgehängt hat, sondern dass vielleicht ein wackler irgendwo im netzwerkkabel liegt. 

Diese aktuellen sommerlichen temperaturen halten viele switches nich aus  :Wink: 

 *Quote:*   

> Oder gibt es vielleicht allgemeine Probleme mit der neuesten OpenSlug-Firmware? 

 Openslug ist keine Firmware. Openslug ist nur eine zusammenstellung von diversen Softwarepaketen, welche für die Slug vorkompiliert wurden. Die Firmware ist der Linuxkernel. Und mit der gibt es eigentlich keine "allgemeinen probleme"  :Wink: 

Die portageoptimierungen mögen zwar n bisschen was bringen.. aber /usr/portage nehm ich bei der slug sowieso von nem nfs share. Das einzige, was ich benutze sind n paar crosscompiler, die die slug per distcc anspricht, wenn sie was emergen will.

----------

## Vollkorn

Moin,

heute mal mit 'links -g' unterwegs, weil mein Xorg gerade modularisiert wird. Ein ganz neues Gefühl  :Smile: 

Mal eine frage an jene, die eine serielle Konsole haben: Ab wieviel Grad Celsius ist das Lötzinn eurer Slug geschmolzen? Ich arbeite mit 320°C und es schmilzt gerade so, noch zu wenig um das Lötztinn in einem der 4 Löcher vollständig zu verflüssigen. Und sowieso: Wenn ich keinen Lötzinnsauger habe, was kann ich dann machen um die Löcher frei zu bekommen? Außer einen zu kaufen!?

Gruß

Jan

----------

## derm1ke

 *chilla wrote:*   

> Wenn das syste nich mehr anpingbar is, dann ist es tot. (du hast vermutlich keinen seriellen anschluss). 
> 
> Aber nur ein Verbindugnsabbruch in einer ssh-session is kein indiz dafür, dass die platine sich verabschiedet hat. Ganz im gegenteil: wenn die verbindung abbricht und du sie kurze zeit später wider herstellen kannst (und wenn dann die uptime trotzdem weitergelaufen ist), dann kannst du dir sicher sein, dass sich die kiste nicht aufgehängt hat, sondern dass vielleicht ein wackler irgendwo im netzwerkkabel liegt. 
> 
> Diese aktuellen sommerlichen temperaturen halten viele switches nich aus 

 

Hi,

die ssh-sessions sind meistens bei CPU-intensiven Aktionen abgebrochen und ein Reconnect führte zu ssh_auth_exchange-Failure oder so. Parallel dazu lief ein Ping ( bis auf heute mittag ) immer noch durch. SerialConsole=>leider nein.

Auch ein Drücken des PowerOff-Buttons hat nicht gezogen.

Die Probleme mit den ssh-Sessions traten sowohl mit dem dropbear aus der OpenSlug-Distri ( ich hoffe, diesmal stimmts  :Wink:  ), als auch mit openssh unter von Platte gebootetem Gentoo auf.

Generell traten die Abbrüche nach ca. 1-2 Tagen Laufzeit unter hoher Last auf. Dachte zuerst daran, daß der ssh-daemon nicht genügend CPU-Zeit kriegt, und hab daraufhin alles was ich gemacht runtergeniced, mit gleichem Erfolg.

Schön war auch die Situation, daß beim Formatieren von 200G mit ext3 auf einmal angeblich Probleme auf dem Bus auftraten ( zumindest sagte ein freundliches df -h und auch ein cat /proc/partitions ). Kurze Zeit später wieder gleiches Phänomen: Ready-LED blinkt fleissig ( wie bei CPU-Aktivität ), System anpingbar, aber kein ssh mehr möglich.

Hab auch schonmal zwei Stunden gewartet ( hatte nen emerge --sync angestossen, vom lokalen rsync-server ), aber nachdem auch mein Server sagte, daß da keine Verbindung mehr ist, bzw. keine Daten mehr laufen, und PowerOff nix brachte, hab ich erstmal die Software als Fehlerquelle ausgeschlossen ( obwohl natürlich OpenSlug immernoch Beta ist ).

Ansonsten könnte ich als Fehlerquelle nur noch die USB-Platte in Auge fassen. Die hatte nämlich vor ner Woche auch schon ein kleines Hitzeproblem ( selber Schuld, wenn man wirklich alle Lüfter abklemmt, dachte aber im 5,25"-Zoll-Gehäuse könnte genügend Luft zirkulieren ), aber jetzt mit laufendem Lüfter hoffe ich das nicht. Kann ich aber gegentesten mit ner kleineren 2,5"-Notebook-Platte am aktiven USB-Hub.

Naja, wie dem auch sei, nen passiver Kühlkörper kann ja nicht schaden, und falls mal jemand die gleichen Probleme mit der slug haben sollte, kann er vielleicht mit den Hilfestellungen was anfangen.

Viele Grüße aus dem viel zu heißen Köln,

derm1ke

----------

## Vollkorn

Juchu!

Endlich habe ich es geschafft und habe jetzt meine vier Pins für die serielle Konsole an der Slug und sie läuft (gleich hoffentlich) mit 266 MHz  :Smile: 

Jetzt fehlt nur noch das Siemens-Datenkabel von dem Ebay-Typen, der sich ein wenig sehr viel Zeit lässt, und los gehts!

Dann brauchst du mir den Kernel auch nicht mehr zu bauen, chilla.

Gruß

Jan

----------

## derm1ke

Ich mal wieder...

Habe jetzt mal aus Lust und Laune mit Debian auf der Slug gespielt, gleiche Probleme gehabt ( Abbrüche etc. ).

Per Zufall habe ich mal mit der Swap-Größe gespielt.

Hatte bisher immer 1G Swap-Partition ( kann ja nicht schaden, oder doch? ), und bin jetzt mal auf 256M runtergegangen, und siehe da, System stabil ( mit offenem gehäuse, der Hitze wegen ).

Also mal das nette Verfahren der Intervallschachtelung angewendet, und ab SwapSpace>512M habe ich Probleme mit der Slug.

Kann jemand dieses Verhalten bestätigen, oder besser noch, hat jemand ne Erklärung? Könnte mir nur vorstellen, daß der Prozi nicht mit dem PATten/NATten klarkommt. Wieviel Mem kann der ARMe ( kleines Wortspiel  :Wink:  ) adressieren?

----------

## chilla

 *derm1ke wrote:*   

> Ich mal wieder...
> 
> Habe jetzt mal aus Lust und Laune mit Debian auf der Slug gespielt, gleiche Probleme gehabt ( Abbrüche etc. ).
> 
> Per Zufall habe ich mal mit der Swap-Größe gespielt.
> ...

 

Hm also patten und natten sagt mir nix  :Wink: 

Aber ich kann dir sagen, dass die swapgröße nur vom kernel beschränkt ist, nicht von der hardware. Und "echten" Ram .. ich glaub, es hat schonma jemand 512 mb sd-ram draufgelötet. aber von mehr hab ich nox nix gehört.

----------

## Vollkorn

Moin!

Nun bin auch ich stolzer Besitzer einer seriellen Konsole und kann mir anschauen woran es bei mir hapert. Und es hapert genau daran, wo ich befürchtete, dass es der grund sein würde: Am little-endian/big-endian-Kram.

Schaut euch mal diese hübsche Meldung an und versucht sie zu lesen  :Wink: 

```
Ethernet eth0: MAC address 00:13:10:d6:1d:5f

IP: 192.168.0.1/255.255.255.0, Gateway: 192.168.0.1

Default server: 0.0.0.0, DNS server IP: 0.0.0.0

RedBoot(tm) bootstrap and debug environment [ROMRAM]

Red Hat certified release, version 1.92 - built 15:16:07, Feb  3 2004

Platform: IXDP425 Development Platform (XScale)

Copyright (C) 2000, 2001, 2002, Red Hat, Inc.

RAM: 0x00000000-0x02000000, 0x000723a0-0x01ff3000 available

FLASH: 0x50000000 - 0x50800000, 64 blocks of 0x00020000 bytes each.

== Executing boot script in 2.000 seconds - enter ^C to abort

RedBoot> boot;exec 0x01d00000

have eRcOmM

copy kernel code from flash to RAM

copy ramdisk file from flash to RAM

run kernel

Using base address 0x01d00000 and length 0x000f6640

ocnUerpmnissiL g.xun dabpizggam n ciebmu-

yS -metslah
```

Mein Kernel ist der openslug-Kernel aus dem SVN kompiliert wie ich es bereits beschrieben habe:

im Makefile ENDIAN=l und CROSS_COMPILE = ${DEBIAN_ARCH}-softfloat-linux-gnu- gesetzt.

Dann kompiliert und geflasht.

*grmbl*

Hat jemand einen Tipp für mich was ich noch beachten muss um die Endianess korrekt hinzubekommen?

Gruß

Jan

----------

## derm1ke

Nabend,

hab mich zwar noch nicht mit dem Kernel beschäftigt, aber DebianSlug ist doch auch little-endian. Kann man nicht aus deren Makefile die entsprechenden Infos ziehen oder zumindest herausfinden, wie das Umschalten auf little-endian gelöst wurde? Habs mir ( noch ) nicht angeschaut, weil ich noch woanders hänge ( seit mehreren Tagen ).

Würde mich übrigens interessieren, ob du den arm-softfloat-linux-gnu-gcc irgendwie gebaut bekommen hast ( also zumindest nativ hänge ich immer bei nem segfault der glibc, per crosscompile hab ichs noch nicht probiert, die VM ist noch in der Mache ). Bei den Suchmaschinen der Wahl finde nur den Hinweis, daß der gcc3.4.6 wohl bei weak-Funktionen nicht sauber abprüft ( wenn dies denn der Fehler sein sollte ).

EDIT:

Habe mal den slugos-source entpackt und durchgeschaut ( leider nicht durchschaut ), aber vielleicht helfen diese Zeilen aus slugos-3.10-beta/openembedded/packages/linux/nslu2-kernel.inc:

```

# This function adds the required prefix to the image to deal with two

# problems:

#

# 1) The machine type set by RedBoot is wrong - the type for an ixdp425, not an NSLU2

#    e3a01c02 e3811055

# 2) For LE kernels it is necessary to prefix change-to-le code to the kernel image:

#    ee110f10 e3c00080 ee010f10

#    and to byte swap the (LE) image to match the BE flash layout

#

# The argument to the function is the destination directory

redboot_fixup_arm() {

        rm -f "$1".new

        devio '<<arch/${ARCH}/boot/${KERNEL_IMAGETYPE}' >"$1".new \

                'wb 0xe3a01c02,4' \

                'wb 0xe3811055,4' \

                'wb 0xee110f10,4' \

                'wb 0xe3c00080,4' \

                'wb 0xee010f10,4' \

                'xp $,4' || {

                echo 'ERROR: arch/${ARCH}/boot/${KERNEL_IMAGETYPE}: failed to byteswap zImage' >&2

                return 1

        }

        mv "$1".new "$1"

}

```

----------

## chilla

So.. 

endlich mal wieder n bisschen zeit und gestern abend war ich noch im Büro und hab endlich meinen seriellen port wieder zusammengelötet, damit ich mal nen neuen kernel bauen kann.

Leider muss ich gerade feststellen, das die aktuelle Makefile ausm svn den kernel nich baut, sondern bei der IXP Accesslib dann irgendwann mitnem fehler abbricht. Hat jemand von euch dafür schon ne lösung oder nen 2.6.17er Kernel mit der Makefile gebaut? 

Gruß

----------

## Vollkorn

Moin,

ich habe einen 2.6.17er Kernel mit den Modulen gebaut. Inzwischen bekomme ich ihn sogar gebootet. Momentan habe ich ein ... ähhh ... peinliches Problem. Beim Aufsetzen der Slug habe ich vergessen module-init-tools zu emergen. Und jetzt komme ich mit der seriellen Konsole nicht an die Slug (Eingaben erreichen die Slug nicht, obwohl ich die Ausgaben erha!te?) und DebianSlug holt sich keine IP-Adresse wie in der Config vermerkt und ich verstehe die Debian-Config einfach nicht gut genug um die richtigen Dateien unter /etc zu editieren und eine feste IP zuzuweisen.

Aber darum werde ich mich jetzt gleich kümmern und dann weiß ich ob mein little endian arm glibc Gentoo läuft!

@derm1ke: Danke für Deinen Hinweis, war genau der richtige. Eine Nachfrage auf nslu2-linux bei yahoo hat meinen Anfängerfehler offenbart: Ich habe das falsche Kernel-Image auf die Slug geladen. Nicht arch/arm/boot/zImage sondern direkt im trunk/ liegen einige Images herum von dem ich vmlinuz-nslu2-2.6.17 brauche.

@chilla: Poste deine Fehlermeldung doch mal, ich hatte auch ein paar, die ich aber Überwinden konnte.

Gruß

Jan

----------

## Amarok

so nun stelle ich frage hier mal an euch alle.

Nachdem ich nun einige tage meine sluggi befummelt habe und wieder nicht zu den gewünschen erfolg gekommen bin und mich mein geliebtes weib schon geschreckt hatte als sie am morgen heraus kam und dachte da sitzt ein fremder (aussehen ändert sich ja gewaltig nach einigen nächten vorm pc) äussere ich nun mal ne bitte

habt ihr vielleicht ein HD-IMAGE einer fertigen installation nach dem chilla-howto

bräuchte zumindest einmal einen laufenden sluggi

dann kann ich in ruhe auf nen anderen weiterspielen wenn zwischendurch mal zeit ist und fehler suchen.

wäre ne tolle sache.

lg Amarok

----------

## Vollkorn

Moin,

sorry Amarok, habe so ein Image leider nicht anzubieten, da keine funktionierende Installation vorliegt. Und außerdem segfaultet mein partimage andauernd.  :Sad: 

Was ist denn dein aktuelles Problem? Poste hier und wir können dir sicherlich helfen. Ich habe bereits mehrfach nach Chillas Anleitung und auf ähnlichen Wegen ein System zum Laufen bekommen.

So, jetzt bin ich soweit gekommen, dass meine serielle Konsole auch Zeichen sendet, aber sobald ich meinen Usernamen bei meinem DebianSlug (als Hostsystem installiert um gentoo aufzusetzen) eingebe und mit Enter bestätige kommt die Passwortabfrage und danach reagiert die Slug nicht mehr bis nach 60 Sekunden die Meldung kommt, dass der Login ausgetimet ist und ich darf meinen Usernamen erneut angeben. Langweiliges Spiel, kennt Jemand das Problöem? Hat jemand eienn Lösungsvorschlag?

Oder weiß jemand warum mein DebianSlug plötzlich keine Lust mehr hat sich im Netzwerk zu zeigen? Weder mit statischer noch mit dynamischer IP?

Gruß

Jan

----------

## Amarok

morgen 

zur zeit ist mein problem dieses hier

ixp400: module license 'unspecified' taints kernel.

Sep 11 02:53:13 slugger ixp400: Module init.

Sep 11 02:53:13 slugger ixp400_eth: Initializing IXP400 NPE Ethernet driver software v. 1.5

Sep 11 02:53:13 slugger ixp400_eth: CPU clock speed (approx) = 266 MHz

Sep 11 02:53:13 slugger [error] ixEthMiiPhyScan : unexpected Mii PHY ID 00008201

Sep 11 02:53:13 slugger ixp400_eth: Found PHY 0 at address 1

Sep 11 02:53:13 slugger ixp400_eth: ixp0 is using NPEB and the PHY at address 1

Sep 11 02:53:13 slugger ixp400_eth: Use default MAC address 00:02:b3:01:01:01 for port 0

Sep 11 02:53:22 slugger rc-scripts: eth0 does not exist

Sep 11 02:53:22 slugger rc-scripts: ERROR:  Problem starting needed services.

und ich bekomms einfach nicht hin.

dabei macht mit die rote led vorerst weniger sorgen  :Wink: 

die bösen blicke meiner frau dagegen schmerzen ganz schön (selbst kaffee muss ich mir schon selbst besorgen) *g*

Amarok

----------

## Vollkorn

Moin Amarok,

der Fehler ist ein ganz einfacher: Das Interface haißt ixp0 und nicht eth0! Sieht man auch schon in der Ausgabe vom Modul "ixp0 is using NPEB and the PHY at address 1"

Also einfach ein /etc/init.d/net.ixp0 erstellen usw.

Viel Erfolg

Jan

----------

## Amarok

das war eines der dinge die ich zwar im kopf hatte aber dann dochnicht getestet habe.

bin eben dabei die openslug-gentoo variante fertig zu machen (postfix) weil mir zeit davon läuft.

hab aber da schon gesehen das da der fehler war.

wenn nun postfix droben ist werde ich das nochmals mit anderen kernel versuchen und mal gucken wie weit er dann kommt.

amarok

----------

## chilla

was zum teufel ist eine "openslug-gentoo" variante? 

Und wieso verdreht sich mein Magen, wenn ich das lese? 

 :Wink: 

Openslug = böse!

----------

## Amarok

@chilla

vermutlich hast du shclechtes gegessen

ich meinte die da http://www.gentoo-wiki.com/HARDWARE_Linksys_NSLU2

welch eine freude die läuft nun auch.

aber ist nicht das was ich letzlich haben möchte.

habe zwar nun net.ixp0 jedoch schreit es unaufhörlich nach depscan 

hab ich in die local.start reingetan was meinem sluggi recht egal ist.

kein netz

hab eben sluggi mit nen 2.6.14-3 kernel gebootet und nochmals per hand die hd gemountet und chroot

und mal dort den depscan und modules-update

vielleicht bringts ja etwas wenn nicht dann doch vorerst diese halbe lösung (siehe oben)

amarok

----------

## Pfeiffer

Hallo zusammen!

Nachdem ich nun wochenlang an meinem NSLU-Kernel hantiert hab und das Teil immer noch nicht rennt, werd ich nun mal posten, was klappt und was nicht und hoffe, dass irgendjemand was damit anfangen kann.

Ich benutze das 2.6.17er-Zeug aus dem svn-Repository. Kernel und Module werden brav gebaut, wenn ich den gcc-4.1.1 in meiner crossdev-Umgebung benutzte. Bei allem unter 4.1.1 bricht das ganze irgendwo ab. Außerdem darf ich im Gegensatz zu dem, was nic0000 ein paar Beiträge vorher geschrieben hat, IXDP465 in meiner config nicht auswählen, da sonst die Module nicht gebaut werden.

Soweit, so gut. Kommen wir zum Bootvorgang. Hier die üblichen Probleme: RTC und ixp400_eth.

Das ixp400-Modul lässt sich zwar nach einem depmod -a laden, dass ixp400_eth gibt allerdings folgende Fehlermeldung zurück:

'FATAL: Error inserting ixp400_eth (/lib/modules/2.6.17/kernel/drivers/net/ixp400_eth.ko): Operation not permitted'

Zur Uhr: ich hab unter Device-Drivers --> RTC --> den x1205-Treiber in meinen Kernel einkompiliert. Allerdings wird auf der NSLU nie ein /dev/rtc erstellt.

Hat vielleicht irgendjemand schon Lösungsvorschläge für mich?

Gruß

pfeiffer

----------

## nic0000

 *Pfeiffer wrote:*   

> Außerdem darf ich im Gegensatz zu dem, was nic0000 ein paar Beiträge vorher geschrieben hat, IXDP465 in meiner config nicht auswählen, da sonst die Module nicht gebaut werden.

 Seltsam??? Naja, ich habe das irgendwann im Try&Error Verfahren herausgekitzelt. Ich werde mich bei Gelegenheit mal wieder damit beschäftigen.

 *Pfeiffer wrote:*   

> Zur Uhr: ich hab unter Device-Drivers --> RTC --> den x1205-Treiber in meinen Kernel einkompiliert. Allerdings wird auf der NSLU nie ein /dev/rtc erstellt.

 es wird ja auch ein /dev/rtcX erstellt. Ich habe es mit einem Symlink vergeblich versucht  :Sad: 

Leider habe ich schon wieder fast alles zu diesem Thema vergessen, aber ich bin mit dir  :Wink: 

----------

## chilla

hmpf..

Also jungs, (die die ihren kernel schon mit nach dem svn gebaut haben) wie siehts aus? könnte einer von denen ma bitte n howto reinschreiben, inklusive aller gcc- und weiss-der-geier-was-versionen, nachdem es schlichtweg funktioniert, einen kernel zu bauen? 

Ich erkläre mich gerne für den Rest bereit, das Howto im wiki fertig zu schreiben,aber irgendwie bekomm ich die kernel auch nich mehr so hin wie ich sie möchte. Nur den 2.6.14.3er  :Sad: 

----------

## -XoF-

Hallo allerseits,

hier meldet sich mal wieder ein Neuling zu Wort.

Bin seit drei Tagen erfreuter Besitzer eines Slugs, von Anfang an war klar, dass da Gentoo drauf muss. Daher erst mal ein Riesenlob & Dank an Chilla und alle anderen, die mir die solide Grundlage geliefert haben, damit das Gentoofying doch relativ rasch von statten ging.

 *chilla wrote:*   

> hmpf..
> 
> Also jungs, (die die ihren kernel schon mit nach dem svn gebaut haben) wie siehts aus? könnte einer von denen ma bitte n howto reinschreiben, inklusive aller gcc- und weiss-der-geier-was-versionen, nachdem es schlichtweg funktioniert, einen kernel zu bauen? 
> 
> Ich erkläre mich gerne für den Rest bereit, das Howto im wiki fertig zu schreiben,aber irgendwie bekomm ich die kernel auch nich mehr so hin wie ich sie möchte. Nur den 2.6.14.3er 

 

Mein System ist zwar noch nicht fertig, den scheinbar schwierigsten Teil hab ich aber scheinbar schon hinter mir gelassen:

Der 2.6.17er Kernel inkl. ixp-Modul ist gebaut, wird gebootet und das ixp-Modul ist geladen.

Der Weg war ein wenig steinig, daher mal kurz ein Gedächtnisprotokoll, vielleicht kanns von euch ja so noch jemand nachvollziehen:

UPDATE:

System bootet in RL 3, Netzwerk geht, beim Booten wird die Systemzeit gesetzt. /dev/rtc ist dann allerdings nicht mehr verfügbar, ich vermute, das erledigt sich dann, wenn ich udev endlich mal kompiliert bekomme. Momentan fehlt ihm die stropts.h, die eigentlich die glibc mitbringt - die ist ja aber durch uclibc ersetzt, die eben kein stropts.h mitbringt....

Anyway, folgende Anleitung nun final überarbeitet:

0.) Crosscompile-Environment aufsetzen

1.) Buildsystem von nslu2-linux.org holen:

```

    # svn co http://svn.nslu2-linux.org/svnroot/kernel $WD

    # cd $WD/trunk

    # mkdir downloads
```

UPDATE:

1.a) Makefile anpassen:

```

# cd $WD/trunk

# wget http://www.devroot.de/projects/nslu2/makefile.patch

# patch -p1 < makefile.patch

```

Damit wird die richtige Endianess und das Buildsystem auf Crosscompile gesetzt.

2.) Intel-Kram beschaffen:

    Bei mir liegt jetzt folgendes rum:

    BSD_ixp400AccessLibrary-2_1.zip

    BSD_ixp400AccessLibrary-2_1_1.zip

    IPL_ixp400NpeLibrary-2_1.zip

    GPL_ixp400LinuxEthernetDriverPatch-1_5.zip

    GPL_ixp400LinuxEthernetDriverPatch-1_5_1.zip

--> http://www.devroot.de/projects/nslu2/intelkram.tbz2

UPDATE: <Punkt 3.) patch-stuff entfernt; das erledigt "make" oder "make menuconfig" beim ersten Lauf automatisch>

4.) Eigene Config bauen, der nslu2-linux.org-Kernel enthält m.E. viel zu viel Schrott.

    Zu viel darf man aber auch net rausschmeissen, sonst kompiliert später der ixp-Treiber nicht...

    Meine .config gibts hier:

http://www.devroot.de/projects/nslu2/kernelconfig-2.6.17

    Zum selber Konfigurieren:

```

# cd $WD/trunk

# make menuconfig  (das ARCH und CHOST Geraffel kann man hier weglassen, weil das Makefile das automatisch macht)

```

    Wenn man meine .config nehmen will, diese am besten auch im menuconfig laden oder halt vor dem Kopieren nach linux-2.6.17 nen make menuconfig machen, damit die Patches alle appliziert werden. Sonst wird beim Make-Lauf die .config wieder überbügelt!

5.) 

```

# cd $WD/trunk

# make
```

    Der Kernel & Module sollten jetzt schon einwandfrei durchkompilieren.

    Die Kompilierung des IXP-Moduls ging bei mir in die Hose, weil der Linker gemeckert hat, dass mit "-mapi=apcs-gnu" eine

    ungültige Option übergeben wurde. Kurze Recherche im Netz ergab, dass diese Option ausschliesslich für die Kompilierung

    des Kernels benutzt werden kann, bei neueren Kernels aber deprecated ist. Keine Ahnung, vielleicht weiss von euch ja

    jemand mehr hierzu?

    Anyway, ich hab dann beschlossen, dem GCC/LD die Option einfach mal wegzunehmen:

```
    # cd $WD/trunk

    # find . -type f -exec grep -l abi=apcs {} \; | while read line

    > do cat $line | sed 's:-mabi=apcs-gnu::g' > $line.bak

    > mv $line $line.orig

    > mv $line.bak $line

    > echo "Processed $line"

    > done

```

    Ein erneuter make sollte jetzt durchlaufen. Wenn nicht, hats bei mir zwischenzeitlich geholfen, den bereits gebauten

    Kram wegzuwerfen:

```

    # cd $WD/trunk

    # rm -rf ixp* lib vmlinuz*

```

6.) Kernel übertragen:

```
    # cd $WD/trunk

    # upslug2 --kernel=vmlinuz-nslu2-2.6.17
```

7.) Ohne serielle Konsole geht jetzt nix mehr, weil das Netzwerkinterface noch ein wenig Sonderbehandlung bedarf:

    Der Treiber benötigt eine Firmware, ohne die gibts beim Laden des ixp400_eth ein "Operation not permitted".

    Daher erstmal die Firmware für den IXP auf den Slug kopieren (In Ermangelung eines funktionierenden Netzwerks heisst das halt

    Platte umhängen): $WD/trunk/ixp400_xscale_sw/lib/linuxbe/IxNpeMicrocode.dat

    Slug wieder booten, dann muss ein Devicenode für den IXP erstellt werden:

```

    slug:# depmod -a

    slug:# modprobe ixp400 

    slug:# mknod /dev/ixNpe c 241 0
```

    Firmware laden:

```

    slug:# cat /lib/firmware/IxNpeMicrocode.dat > /dev/ixNpe
```

    Modul laden:

```

    slug:# modprobe ixp400_eth

```

    Diesen ganzen Schmonz sollte dann wohl zukünftig das Hotplug-Framework übernehmen, ich meld mich wieder, wenn ich was hab.

    Wer keine serielle Console sein eigen nennt, kann natürlich versuchen, die ganzen Commands einfach in ein Startup-Script

    zu packen. Wär vielleicht prinzipiell ne Alternative zu dem Hotplug-Geraffel.

    Ich hab z.B. als vorl. Workaround die /etc/init.d/bootmisc dementsprechend modifiziert.

Kurz ein paar Eckdaten zu meinem Buildsystem:

- Gentoo 2006.0

# gcc --version

# gcc (GCC) 3.4.4 (Gentoo 3.4.4-r1, ssp-3.4.4-1.0, pie-8.7. :Cool: 

- crossdev 0.9.15-r1

HTH,

-XoF-

PS:

Kernel & Kram gibts hier:

http://www.devroot.de/projects/nslu2/

----------

## -XoF-

BTW,

das Netzwerkinterface heisst bei mir eth0, nicht ixp0.

Interessanterweise gibts auch noch ein eth1. Weiss da jemand was drüber?

-XoF-

----------

## -XoF-

Hi Mädels,

mal ne ganz andere Frage:

Ich hab ne serielle Konsole via TTL-Pegel an Prolific PL2301. Ausserdem hab ich meine Schnecke ein wenig beschleunigt, sprich de-underclocked.

Irgendwie hab ich das Gefühl, dass meine Konsole immer dann nur noch wirren Zeichensalat auskotzt, wenn die CPU ein wenig stärker gefordert ist; beim Kompilieren z.B.

Hat von euch schon mal jemand ähnliches bemerkt?

-XoF-

----------

## -XoF-

 *nic0000 wrote:*   

> 
> 
>  *Pfeiffer wrote:*   Zur Uhr: ich hab unter Device-Drivers --> RTC --> den x1205-Treiber in meinen Kernel einkompiliert. Allerdings wird auf der NSLU nie ein /dev/rtc erstellt. es wird ja auch ein /dev/rtcX erstellt. Ich habe es mit einem Symlink vergeblich versucht 
> 
> 

 

Hmm, bei mir gibts zwar ein /dev/rtc, aber das zeigt ins Nirvana... :Sad: 

Ob der Kernel /dev/rtc oder /dev/rtc0 verwendet, kann man übrigens einstellen:

CONFIG_RTC_HCTOSYS_DEVICE="rtc"

Ebenso scheint mir dir in der cmdline übergebene Option mit dem x1205.hctosys=1 überflüssig (Kernel meckert auch, dass er das nicht kennt).

Das gewünschte Verhalten wird m.E. so erreicht:

CONFIG_RTC_HCTOSYS=y

Nichtsdestotrotz, selbst wenn ich rtc-x1205 als modul baue und dann modprobe bekomme ich rein gar nix im dmesg und das rtctest snippet aus $KSRC/Documentation/rtc.txt meldet auch, dass das device nicht vorhanden ist (obwohl /dev/rtc mit 10:135 existiert)....

UPDATE:

ARGGGGHHHH!!!!!

Fehler gefunden:

Bei meinen unzähligen Buildversuchen gestern wurden wohl irgendwann mal die Kernelsourcen neu entpackt, aber nicht pepatcht.... :Sad: 

Hab eben alle patches aus $WD/trunk/patches/2.6.17/series appliziert, und siehe da:

Schon gibts auf automagische Weise ein /dev/rtc0.

Dann eben noch CONFIG_RTC_HCTOSYS_DEVICE auf "rtc0" gesetzt, und schon hat mein slug endlich die richtige Zeit....

----------

## -XoF-

sodele, jetzt ist auch udev kompiliert.

Das mit dem stropts.h-issue scheint ein bug in der letzten stable version zu sein. 

Ein

emerge =udev-098

lief einwandfrei durch.

Wie erwartet wird jetzt auch ein korrektes /dev/rtc0 angelegt. Einfach noch nach /dev/rtc verlinkt und fertig.

UPDATE:

Das mit dem manuellen Verlinken überlebt halt den Reboot nicht, ein tarball von /dev erzeugen zu lassen bringt auch nix.

Daher hab ich ne kleine udev-rule erstellt:

```
dragon ~ # echo "KERNEL==\"rtc0\", SYMLINK=\"rtc\"" > /etc/udev/rules.d/10-rtc.rules

```

----------

## nic0000

OT

Oha, du räumst ja das Feld von hinten gehörig auf. Was fehlt denn überhaupt noch? Du scheinst ja alle Hürden genommen zu haben.

----------

## -XoF-

Hi allerseits,

so, meine Schnecke läuft jetzt soweit.

Ich hab mal das RootFS gedumpt und auf meinen Webserver gestellt:

http://www.devroot.de/projects/nslu2/slug_rootfs-2.6.17.dump.tbz2

Bitte auch das Readme beachten:

http://www.devroot.de/projects/nslu2/readme.rootfs

Zum Entpacken:

```
tar xjf slug_rootfs-2.6.17.dump.tbz2

cd $DEST

cat $WD/slug_rootfs-2.6.17.dump | restore -rf -
```

Portage hab ich aus Platzgründen gekickt.

Viel Spass.

-XoF-

----------

## nic0000

Super! Ich freue mich schon richtig auf Feierabend  :Very Happy: 

Dann habe ich vielleicht endlich mal die Schnecke mit einem "aktuellen" System am laufen.

----------

## chilla

danke danke danke!

Ich werd mich ab morgen ma wieder daran setzen ein vollständiges tutorial für das teil zu schreiben, bzw. meinen wiki-artikel auf vordermann zu bringen. 

Das mit dem 2.6.17er war schonma n großes stück arbeit, werds heut nacht ma durchtesten. Danke dir schonma für deine arbeit!

----------

## -XoF-

hmpff,

eine "Kleinigkeit" passt wohl doch noch nicht so ganz. Einige ebuilds lassen sich nicht kompilieren (z.B. uclibc, gcc, nfs-utils):

 *Quote:*   

> gcc  -L../../support/lib -o rpcgen rpc_clntout.o rpc_cout.o rpc_hout.o rpc_main.o rpc_parse.o rpc_scan.o rpc_svcout.o rpc_tblout.o rpc_util.o rpc_sample.o
> 
> /usr/lib/gcc/armeb-softfloat-linux-uclibc/3.4.4/../../../../armeb-softfloat-linux-uclibc/bin/ld: rpc_clntout.o: Relocations in generic ELF (EM: 3)
> 
> rpc_clntout.o: could not read symbols: File in wrong format
> ...

 

Scheint mir ein tieferes Problem mit der Toolchain (libtool?) zu sein....

Das ganze kommt direkt nach dem configure.

Hat da jemand ne Idee dazu?

UPDATE:

Interessanterweise bekomme ich diesen Fehler nicht, wenn ich die Sourcen manuell auspacke, mit dem gleichen configure-command konfiguriere wie das ebuild und dann nen make anwerfe...

-XoF-

----------

## chilla

@ xof:

Wie siehts mit deinen Ungebungsvariablen bei der Kernelkompilierung aus? Du machst ja nen crosscompile. Kannst du mir ma eben den header deiner Makefile geben, bzw. mir sagen, ob du manuell noch irgendwelche sachen setzt? 

Beispielsweise wenn man nach dem ersten Make n make menuconfig machen möchte, muss man das ja soweit ich weiss mit den gleichen flags machen, sollte da 

"make ARCH=arm CROSS_COMPILE=armeb-softfloat-linux-uclibc- menuconfig"

richtig sein - gesetz dem fall, dass ich das auch in meiner Makefile drin habe, mit der ich vorher das "normale erste make" aufgerufen habe?

----------

## -XoF-

Ja, da hab ich doch glatt vergessen was zu erwähnen...

Das Makefile muss natürlich wie hier schon mal beschrieben wurde editiert werden:

```

# cd $WD/trunk

# diff Makefile Makefile.orig

22,23c22,23

< #ENDIAN = l

< ENDIAN = b

---

> ENDIAN = l

> #ENDIAN = b

46c46

< CROSS_COMPILE ?= ${DEBIAN_ARCH}-softfloat-linux-uclibc-

---

> CROSS_COMPILE ?= ${DEBIAN_ARCH}-linux-

```

--> http://www.devroot.de/projects/nslu2/makefile.patch

```

# cd $WD/trunk

# patch -p1 < makefile.patch

```

beim 

```
# cd $WD/trunk

# make menuconfig 

```

musst du dann nix mehr übergeben, da:

```
# grep menuconfig Makefile

menuconfig: linux-${REVISION}/.config

        ${MAKE} -C linux-${REVISION} ARCH=arm CROSS_COMPILE=${CROSS_COMPILE} menuconfig

#
```

HTH,

-XoF-

----------

## -XoF-

So, hab jetzt https://forums.gentoo.org/viewtopic-p-3551345.html#3551345

nochmal überarbeitet und die Anleitung an nem frischen svn-checkout ausprobiert -> kernel kompiliert.

Sollte jetzt also so passen.

bye,

-XoF-

----------

## -XoF-

So, hab jetzt nochmal dieses "wrong format" Problem ein wenig analysiert.

Es sieht tatsächlich so aus, als ob ebuild manchmal fälschlicherweise Object-Files im 386er-Format baut. Für mich ist das ein Bug im jeweiligen Ebuild-File.

Hab das ganze mal am Beispiel der uclibc 0.9.28 angeschaut, da erzeugt ebuild beim "make defconfig" tatsächlich 386er-Objects (z.B. extra/config/conf.o), obwohl eigentlich alle relevanten Variablen korrekt gesetzt sind.

Wenn man das ebuild derart modifiziert, dass der "make defconfig" nicht läuft und das script stattdessen auf Benutzerinput wartet und dann in /var/tmp/portage/uclibc-0.9.28/work/uClibc-0.9.28 "make defconfig" manuell aufruft und anschließend das ebuild weiterlaufen lässt, dann fluppts.....

Wen's interessiert:

das Package gibts hier:

http://www.devroot.de/projects/nslu2/packages

Greetz,

-XoF-

----------

## Pfeiffer

Hier hat sich ja richtig was getan. Sehr schön!

Hab jetzt auch nochmal was an meiner NSLU rumgespielt und bin dank -XoF- jetzt auch soweit, dass das ixp400_eth-Modul geladen wird.

Allerdings hab ich immer noch das Problem mit meiner Uhr. 

Beim booten bekomme ich jetzt zwar ein /dev/rtc, er meldet auch, dass er die Systemzeit gesetzt hat (das Datum ist zwar im August, aber das ist ja vorerst nicht so wichtig), allerdings bleibt der Bootvorgang dann beim clock-Initskript hängen. 

Falls jemand einen Vorschlag für mich hat, wär das quasi phänomenal. Ist nämlich - soweit ich das im Moment beurteilen kann - das einzige noch bestehende Problem...

----------

## -XoF-

Heyho,

wg. clock-initscript:

Das Problem hatte ich auch. Liegt daran, dass in dem initscript "hwclock" ausgeführt wird. Dummerweise ist bei dir das korrekte rtc-device nicht (mehr) vorhanden.

Ich leg meine Hand dafür ins Feuer, dass wenn du in das initscript ganz oben ein "exit 0" einträgst (so dass du mal weiterbooten kannst), nach dem Login ein hwclock nicht funktioniert -> device not found.

Lag bei mir daran, dass das Device /dev/rtc0 angelegt wird, hwclock will aber ein /dev/rtc. Daher die weiter oben beschriebene udev-Regel.

Udev tut bei dir, oder?

Wenn alle Stricke reissen: Das clock-initscript brauchste eigentlich gar net, weil die Zeit ja schon vom Kernel aus der RTC gelesen und gesetzt wurde. Dummerweise geht ein "rc-update delete clock" nicht, weil clock ein system service ist. Daher der "exit 0"-Hack

HTH,

-XoF-

----------

## Pfeiffer

Hallo Leute,

hatte gerade mal wieder etwas Zeit und hab mal die Ratschläge von -XoF- aus dem Beitrag hier drüber ausprobiert.

Die NSLU ist jetzt soweit, dass sie schon mal ohne Fehler durchbootet. Per ssh verbinden funzt auch.

Soweit so gut. Fragen und ein Anmerkungen sind aber immer noch da.

Zu den Fragen:

1. Ist es normal, dass der Bootvorgang stehenbleibt, wenn das letzte Initsrkipt aus Runlevel 3 geladen wurde. Ich bekomme nämlich über die serielle Konsole nie die Möglichkeit mich einzuloggen.

2. Bei jedem neuen booten steht die RTC auf "2006-08-21 23:23:30 (1156202610)". Normal?

Anmerkungen:

1. Aus irgendeinem Grund wird bei mir kein eth0, sondern nur eth1 und eth2 erstellt; eigentlich nicht weiter schlimm - wenn man es denn erstmal rausgefunden hat.

2. Bei mir bleiben /dev/rtc und /dev/rtc0 auch nach dem booten noch erhalten. hwclock funktioniert aber leider trotzdem nicht, sondern hängt sich ohne Fehlermeldungen irgendwie auf.

----------

## -XoF-

Hello,

 *Pfeiffer wrote:*   

> 
> 
> Zu den Fragen:
> 
> 1. Ist es normal, dass der Bootvorgang stehenbleibt, wenn das letzte Initsrkipt aus Runlevel 3 geladen wurde. Ich bekomme nämlich über die serielle Konsole nie die Möglichkeit mich einzuloggen.
> ...

 

Hmm, du startest aber schon einen getty auf /dev/ttyS0, oder?

Die /etc/inittab sollte einen Eintrag wie diesen hier enthalten:

```
 

s0:12345:respawn:/sbin/agetty 115200 ttyS0 vt100

```

 *Quote:*   

> 
> 
> 2. Bei jedem neuen booten steht die RTC auf "2006-08-21 23:23:30 (1156202610)". Normal?
> 
> 

 

Nö. Hängt schätzungsweise damit zusammen, dass hwclock nicht funzt. Somit kannste auch nicht die Systemzeit in die RTC schreiben. Andererseits sollte die RTC dann trotzdem weiterlaufen, nur halt mit der falschen Zeit. Dass immer die gleiche Zeit drinnesteht ist schon irgendwie weird...  

 *Quote:*   

> 
> 
> 2. Bei mir bleiben /dev/rtc und /dev/rtc0 auch nach dem booten noch erhalten. hwclock funktioniert aber leider trotzdem nicht, sondern hängt sich ohne Fehlermeldungen irgendwie auf.

 

Hmm, welche Major/Minor numbers haben denn rtc0 und rtc?

bye,

-XoF-

----------

## Pfeiffer

Moin!

 *Quote:*   

> Die /etc/inittab sollte einen Eintrag wie diesen hier enthalten:
> 
> ```
> s0:12345:respawn:/sbin/agetty 115200 ttyS0 vt100
> ```
> ...

 

Problem behoben. Hatte die Geschwindigkeit noch auf 9600 stehen. Peinlich, peinlich...

 *Quote:*   

> Hmm, welche Major/Minor numbers haben denn rtc0 und rtc? 

 

Für rtc0 siehts so aus:

```
crw-rw---- 1 root root 254,  0 Aug 21 23:23 rtc0
```

rtc wird durch Deine udev-Regel erstellt, ist also nur ein Link auf rtc0.

----------

## -XoF-

 *Pfeiffer wrote:*   

> Moin!
> 
> Für rtc0 siehts so aus:
> 
> ```
> ...

 

Merkwürdig, das passt soweit eigentlich. Hab das nochmal mit meinem Slug quergecheckt.

Was sagt denn 

```
hwclock --show
```

Gibt das vielleicht ein paar Infos mehr zurück?

Greetz,

-XoF-

----------

## Pfeiffer

Hier der "Output" von hwclock --show:

```
~ # time hwclock --show

Timed out waiting for time change.

real    53m20.096s

user    0m0.590s

sys     53m19.500s
```

Leider reagieren alle hwclock-Kommandos so...

----------

## -XoF-

Hmm, riecht irgendwie nach nem HW-Defekt...

1.) hwclock sagt, es bekommt über eine knappe Stunde hinweg keine Zeitänderung mit

2.) Die RTC steht beim booten immer auf gleichem Wert

Sieht doch irgendwie stark danach aus, als ob die RTC steht.

In Unwissenheit darüber, welche Auswirkungen das haben könnte, stell ich jatzt einfach mal die Frage, ob du schon mal die Batterie gezogen hast? Wär vielleicht ne Möglichkeit, der RTC nen Schubs zu geben...??

Good Luck,

-XoF-

----------

## Pfeiffer

Hab gestern Abend mal die Batterie gezogen und beim Bootvorgang danach hatte meine Uhr tatsächlich zum ersten mal eine andere Uhrzeit!

Auch "hwclock --show" liefert jetzt vernünftige Ergebnisse.

Vielen Dank für den Tip!

----------

## nic0000

Oh, man ich bin soo eine Lusche...

Ich habe jetzt endlich mal Zeit gefunden mir das alles reinzuziehen und kann nur sagen, alles Inklusive Batterie ziehen hat bei mir gewirkt. Also vielen Dank an -XoF-, der hat den vollen Durchblick. Von wegen "noob", die Schnecke läuft jetzt wie ein Rennpferd. Ich update das System jetzt ein wenig und werde es gleich danach dump zum Downloaden anbieten.

@-XoF-

Kannst du auch einen Dump von der Kernelbauumgebung zu Verfügung stellen? Ich brauche ein System mit RAID1 im Kernel und so anderen Kleinigkeiten als Modul. Ansonsten kann ich nur den Hut vor dir ziehen.

----------

## nic0000

 *nic0000 wrote:*   

> Ich update das System jetzt ein wenig und werde es gleich danach dump zum Downloaden anbieten.

 Dauer noch ein Moment, mir ist die Festplatte an der Schnecke abgeraucht. (Ich sollte keine Kabel liegenlassen wenn ich Besuch habe)

----------

## chilla

Uffz.. ihr freaks  :Wink: 

NAchdem ihr so viel gemacht habt, wollte ich mich jetzt auch mal wieder hinsetzen und was dazu beitragen, dass das Gerät benutzbarer wird.  

Ich versuche nun gerade ein glibc system für die Slug zu bauen und scheitere schon am kompilieren:

Ich habe eine laufende gentoo-slug.  Weil ich nich aussversehen mein System verpfuschen wollte, habe ich ein armeb-softfloat-uclibc-stage1 archiv  nach /root/newsys entpackt.. und dazu noch n portage-snapshot, proc gemountet, gechrootet, env-update usw usw usw.

mein gewähltes Profil:

```
homesluggy scripts # ls -l /etc/make.profile 

lrwxrwxrwx  1 root root 40 Oct 22 16:35 /etc/make.profile -> /usr/portage/profiles/default-linux/arm/
```

meine make.conf:

```

CFLAGS="-march=armv5t -Os"

CHOST="armeb-unknown-linux-gnu"

CXXFLAGS="-march=armv5t -Os"

USE="-* arm pam"

```

So nun bin ich in meiner neuen Build-umgebung und will eigentlich einen bootstrap ausführen. (wiederum in ein neues Root-ferzeichnis, dafür setze ich einfach ROOT=/root/build vornedran:

sieht folgendermaßen aus:

```

homesluggy scripts # ROOT=/root/build/ ./bootstrap.sh -p

Gentoo Linux; http://www.gentoo.org/

Copyright 1999-2006 Gentoo Foundation; Distributed under the GPLv2

-------------------------------------------------------------------------------

  [[ (0/3) Locating packages ]]

 * Using baselayout : virtual/baselayout

 * Using portage    : >=sys-apps/portage-2.0.51.22

 * Using os-headers : virtual/os-headers

 * Using binutils   : sys-devel/binutils

 * Using gcc        : sys-devel/gcc

 * Using libc       : virtual/libc

 * Using texinfo    : sys-apps/texinfo

 * Using zlib       : sys-libs/zlib

 * Using ncurses    : sys-libs/ncurses

-------------------------------------------------------------------------------

  [[ (1/3) Configuring environment ]]

 * GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo"

 * PORTDIR="/usr/portage"

 * DISTDIR="/usr/portage/distfiles"

 * PKGDIR="/usr/portage/packages"

 * PORTAGE_TMPDIR="/var/tmp"

 * CFLAGS="-march=armv5t -Os"

 * CHOST="armeb-unknown-linux-gnu"

 * CXXFLAGS="-march=armv5t -Os"

 * MAKEOPTS="-j4"

 * ACCEPT_KEYWORDS="arm"

 * FEATURES="autoconfig distlocks metadata-transfer sandbox sfperms strict"

-------------------------------------------------------------------------------

  [[ (2/3) Updating portage ]]

These are the packages that would be merged, in order:

Calculating dependencies... done!

[ebuild  N    ] sys-apps/sandbox-1.2.17 to /root/build/ 

[ebuild  N    ] app-misc/pax-utils-0.1.13 to /root/build/ USE="-caps" 

[ebuild  N    ] sys-libs/zlib-1.2.3 to /root/build/ USE="build" 

[ebuild  N    ] dev-lang/python-2.4.3-r4 to /root/build/ USE="bootstrap build -berkdb -doc -gdbm -ipv6 -ncurses -nocxx -readline -ssl -tk -ucs2" 

[ebuild  N    ] dev-python/python-fchksum-1.7.1 to /root/build/ 

[ebuild  N    ] dev-python/pycrypto-2.0.1-r5 to /root/build/ USE="-bindist -gmp -test" 

[ebuild  N    ] sys-apps/portage-2.1.1-r1 to /root/build/ USE="build -doc (-selinux)" LINGUAS="-pl" 

-------------------------------------------------------------------------------

  [[ (3/3) Emerging packages ]]

These are the packages that would be merged, in order:

Calculating dependencies... done!

[ebuild     U ] sys-apps/findutils-4.3.0 [4.1.20-r1] USE="-build*" 

[ebuild     U ] sys-devel/binutils-config-1.9-r2 [1.8-r4] 

[ebuild  N    ] sys-devel/gnuconfig-20060702  

[ebuild     U ] sys-devel/gcc-config-1.3.13-r4 [1.3.11-r4] 

[ebuild  N    ] virtual/libiconv-0  

[ebuild  N    ] sys-libs/timezone-data-2006g  

[ebuild  N    ] sys-libs/glibc-2.3.6-r4  USE="-build -erandom -glibc-compat20 -glibc-omitfp (-hardened) (-multilib) -nls -nptl -nptlonly -profile (-selinux)" 

[ebuild  N    ] sys-kernel/linux-headers-2.6.11-r2 to /root/build/ USE="-gcc64" 

[ebuild  N    ] sys-libs/ncurses-5.5-r3 to /root/build/ USE="bootstrap -build -debug -doc -gpm -minimal -nocxx -trace -unicode" 

[ebuild  N    ] sys-apps/texinfo-4.8-r2 to /root/build/ USE="-build -nls -static" 

[ebuild  N    ] sys-apps/findutils-4.3.0 to /root/build/ USE="-build -nls (-selinux) -static" 

[ebuild  N    ] sys-devel/binutils-config-1.9-r2 to /root/build/ 

[ebuild  N    ] sys-devel/binutils-2.16.1-r3 to /root/build/ USE="-multislot -multitarget -nls -test -vanilla" 

[ebuild  N    ] sys-libs/zlib-1.2.3 to /root/build/ USE="-build" 

[ebuild  N    ] sys-devel/gcc-config-1.3.13-r4 to /root/build/ 

[ebuild  N    ] virtual/libiconv-0 to /root/build/ 

[ebuild  N    ] sys-libs/timezone-data-2006g to /root/build/ 

[ebuild  N    ] sys-libs/glibc-2.3.6-r4 to /root/build/ USE="-build -erandom -glibc-compat20 -glibc-omitfp (-hardened) (-multilib) -nls -nptl -nptlonly -profile (-selinux)" 

[ebuild  N    ] sys-devel/gcc-3.4.6-r1 to /root/build/ USE="bootstrap (-altivec) -boundschecking -build -doc -fortran -gcj -gtk (-hardened) -ip28 -ip32r10k (-multilib) -multislot (-n32) (-n64) -nls -nocxx -nopie -nossp -objc -test -vanilla" 

[ebuild  N    ] sys-apps/sysvinit-2.86-r5 to /root/build/ USE="-ibm (-selinux) -static" 

[ebuild  N    ] sys-apps/baselayout-1.12.5-r2 to /root/build/ USE="bootstrap -build -static -unicode" 

```

Das führe ich denn auch mal aus.. aber leider bricht er bei "Emerging (4 of 7) dev-lang/python-2.4.3-r4 to /root/build/" mit folgender Fehlermeldung ab:

```

checking EXTRAPLATDIR... 

checking for --without-gcc... no

checking for --with-cxx=<compiler>... no

checking for c++... g++

checking for C++ compiler default output file name... configure: error: C++ compiler cannot create executables

See `config.log' for more details.

!!! Please attach the following file when filing a report to bugs.gentoo.org:

!!! /var/tmp/portage/python-2.4.3-r4/work/Python-2.4.3/config.log

!!! ERROR: dev-lang/python-2.4.3-r4 failed.

Call stack:

  ebuild.sh, line 1546:   Called dyn_compile

  ebuild.sh, line 937:   Called src_compile

  python-2.4.3-r4.ebuild, line 176:   Called econf '--with-fpectl' '--enable-shared' '--disable-ipv6' '--infodir=${prefix}/share/info' '--mandir=${prefix}/share/man' '--with-threads' '--with-libc=' '--enable-unicode=ucs4'

  ebuild.sh, line 540:   Called die

!!! econf failed

!!! If you need support, post the topmost build error, and the call stack if relevant

```

hat jemand ne idee, woran das liegen könnte?

schönen gruß

----------

## nic0000

 *chilla wrote:*   

> Uffz.. ihr freaks 

 Selber!  :Very Happy: 

 *chilla wrote:*   

> Ich versuche nun gerade ein glibc system für die Slug zu bauen und scheitere schon am kompilieren:

 Ich kann dir da nicht helfen, habe aber eine Frage. Ich dachte immer es macht keinen Sinn machen bei 32MB und ohne einen Co-Prozessor die fette glibc einzusetzen, deshalb wird doch immer die uclibc empfohlen. Habe ich das jetzt falsch verstanden? Soviel ich es weiß funktionieren schon ziemlich viele Programme mit der uclibc, auch wenn es Probleme mit ebuilds gibt. Z.B. will mc (midnight commander) immer die glibc haben, per Hand compilliert gehts auch mit der uclibc, wie lolly bei seinen rootfs.tgz auch gezeigt hat.

Ansonsten klappt bei mir das update auf die gcc-3.4.6-r1 nicht. Es bricht immer wieder an verschiedenen Stellen und beschwert sich über "emake failed with bootstrap-lean"

gn8

----------

## -XoF-

Hey Ho,

oops, hier ging ja mal wieder richtig was. Hab wohl aus Versehen die Notification abgeschaltet...  :Sad: 

 *nic0000 wrote:*   

> Oh, man ich bin soo eine Lusche...
> 
> Ich habe jetzt endlich mal Zeit gefunden mir das alles reinzuziehen und kann nur sagen, alles Inklusive Batterie ziehen hat bei mir gewirkt. Also vielen Dank an -XoF-, der hat den vollen Durchblick. 

 

jetzt wollen wir aber mal die Kirche im Dorf lassen.... <rotwerd> Trotzdem danke für die Blumen!

 *Quote:*   

> @-XoF-
> 
> Kannst du auch einen Dump von der Kernelbauumgebung zu Verfügung stellen? 
> 
> 

 

Hm, eigentlich gibts das schon. Das ist der SVN-Snapshot (http://www.devroot.de/projects/nslu2/svn.nslu2-linux.org.snapshot-20060905.tbz2).

Oder hättst du's gerne gleich mit fertigen Objects?

Ich hatte kürzlich mal so die fixe Idee, sozusagen ne komplette kleine Distri zusammenzustellen. Ich stell mir das so vor, dass z.B. via IPKG der nötige Teilbaum von /usr/portage installiert wird und anschließend ein Binärpaket gezogen & installiert wird. Oben drauf dann noch ein modular aufgebauter, CLI-basierter Konfigurator und das Ding ist ziemlich idiotensicher.

Hatt von Euch vielleicht noch jemand ein paar Ideen dazu?

Ansonsten kann ich nur berichten, dass bei mir die SLUGgomanie ausgebrochen ist. Das Ding ist einfach fett....

Neulich nen zweiten gekauft, der kam übrigens ab Werk auf 266MHz getaktet! Mittlerweile dient das Schneckchen als serial Console-Server für nen Rechner im Hetzner-RZ...  :Smile: 

----------

## chilla

@XoF:

Wenn dich das teil so gepackt hat, und du lust hast, noch andere sachen damitzu machen, kann ich dir eine kleine i2c relais-platine schicken, die wir entwickelt haben. 

Da ist ein i2c-chip drauf, der an den kleinen xt-mit den 2 freien pins angeschlossen ist. Mit einem einfachen echo "1" >  /sys/bus/i2c/device/...blabla schaltest du dann beispielsweise das licht an. Alternativ kannst du auch stomstände ablesen. Wenn strom auf dem Relais ist, steht dann in der read-datei eine 1. Beispeilsweise kannst du damit eine Morseklingel bauen: Für den Fall, dass du deinen Hausschlüssel vergessen hast, morst du dann "hallo, ich bin xof und ich will in meine wohnung rein", ein kleines C-.programm liest das aus und stellt fest, dass du richtig "geklingelt" hast und gibt strom auf das Relais, welches den Türmagneten aktiviert und somit die Tür entriegelt. 

Wir verwenden diese Platine dafür, dass Türenund Drehkreuze entriegelt werden. Ein RFID-Reader an der Slug liest die angehaltenen Tags aus, überprüft in der Datenbank ob die Leute berechtigt sind und maht die Türen auf. Ist sehr praktisch  :Smile: 

Platine kannst du für nen Appel und nen Ei haben. Alternativ kann ich dir auch die Pläne geben. Damit kann man sehr viel schöne Sachen machen  :Smile:  Nen ttl2rs232-wandler is natürlich auch gleich drauf. 

Schönen Gruß

----------

## -XoF-

@chilla:

woahwoahwoahwoah!

her damit! auf jeden fall! Wie gesagt, mein 2. Slug steht demnächst als console-server im Hetzner-RZ. Da hat ein kumpel von mir ein ganzes Rack als Co-Location gemietet, ich helf ihm grad mit Infrastrukturaufbau.

Und weils halt momentan noch eher low-cost-mäßig abgeht, ham wir uns die Kohle für nen richtigen Console-Server gespart und nen Slug genommen. Wenn ich mit dem Ding jetzt auch noch z.B. die Server strommäßig ein- und ausschalten kann damit - superb! 

Was soll die Platine kosten?

----------

## chilla

keine ahnung... selber gelötet is das schon n bisschen zeitaufwand. aber wenn wir die in ein werk geben und 100 davon bestellen, kosten die vielleicht 2-5  pro stück..

----------

## nic0000

 *nic0000 wrote:*   

> Ich update das System jetzt ein wenig und werde es gleich danach dump zum Downloaden anbieten.

 Ich bin so weit. Nicht perfekt aber vielleicht doch hilfreich.

http://embedded.gentoo.hoppix.org/nslu2/

Eine genaue Beschreibung was ich da gemacht habe ist unter http://embedded.gentoo.hoppix.org/nslu2/readme einsehbar.

 *-XoF- wrote:*   

> Ich hatte kürzlich mal so die fixe Idee, sozusagen ne komplette kleine Distri zusammenzustellen. Ich stell mir das so vor, dass z.B. via IPKG der nötige Teilbaum von /usr/portage installiert wird und anschließend ein Binärpaket gezogen & installiert wird. Oben drauf dann noch ein modular aufgebauter, CLI-basierter Konfigurator und das Ding ist ziemlich idiotensicher. 
> 
> Hatt von Euch vielleicht noch jemand ein paar Ideen dazu?

 Klar Ideen habe ich eine Menge, aber das klingt schon verdammt gut was du da sagst  :Very Happy: 

Also ich bastle ja selbst ein wenig eine eigene Gentoo-Distri zusammen. Allerdings geht es bei mir hauptsächlich darum Desktop-Systeme fernwartungsfreundlich zu machen und dabei so nah an Gentoo wie möglich zu bleiben. 

Unter http://www.hoppix.org/online.html kann der Onlinestatus eingesehen werden.

Ich habe zB. die overlays auf meinen Server in den /usr/portage Ordner gepackt. Dadurch muss ich auf den Clients keine Overlays mehr pflegen sondern kann diese einfach durch die PORTDIR_OVERLAY Var in der make.conf ein bzw. ausschalten.

Sieht so aus:

```
########## hoppix.org overlays

OVERLAYS="/usr/portage/overlays/"

OVERLAY_00="/usr/local/portage/overlays"

OVERLAY_01="${OVERLAYS}hoppix-org"

OVERLAY_02="${OVERLAYS}hoppix-beta"

OVERLAY_03="${OVERLAYS}hoppix-dev"

OVERLAY_04="${OVERLAYS}hoppix-dev"

OVERLAY_05="${OVERLAYS}hoppix-test"

#OVERLAY_06="${OVERLAYS}hoppix-embedded"

#OVERLAY_07="${OVERLAYS}"

PORTDIR_OVERLAY="${OVERLAY_00} ${OVERLAY_01} ${OVERLAY_02} ${OVERLAY_03} ${OVERLAY_04} ${OVERLAY_05} ${OVERLAY_06} ${OVERLAY_07}"
```

Zur Zeit bastle ich daran mir anzeigen zu lassen welche Systeme von der Nom abweichen und solche Kleinigkeiten mehr. 

Naja, vielleicht kann ich dir ja doch helfen auch wenn ich z.Z. mir nichteinmal die Umsetzung von deinen Anregungen vorstellen kann :-/

----------

## nic0000

 *nic0000 wrote:*   

>  *nic0000 wrote:*   Ich update das System jetzt ein wenig und werde es gleich danach dump zum Downloaden anbieten. Ich bin so weit. Nicht perfekt aber vielleicht doch hilfreich.
> 
> http://embedded.gentoo.hoppix.org/nslu2/
> 
> Eine genaue Beschreibung was ich da gemacht habe ist unter http://embedded.gentoo.hoppix.org/nslu2/readme einsehbar.
> ...

 

EDIT: Link angepasst

----------

## derm1ke

Servus,

in letzter Zeit hat sich ja viel getan ( in anderen Distris ). Wie sieht es zur Zeit gentoo-seitig mit Support für die Slug aus?

War ja mal im Gespräch, die Kernel-Änderungen etc von embedded-gentoo einfliessen zu lassen und einen Automatismus zu bauen.

Bin ehrlich gesagt momentan noch unschlüssig, ob ich mit gentoo auf der Slug bleibe, oder mir notgedrungen doch debian anschau.

Dort gibts wenigstens ne saubere little-endian glibc Installation.

Aber ich hab ehrlich gesagt wenig Lust, mit nem falsch gestrickten gentoo-Kernel ( was ich tun müsste.... ) meine Slug zu zerschiessen.

Und die vorhandenen Anleitungen sind ja mittlerweile auch schon ein wenig überaltert.

Würde mich selber gerne mehr reinhängen, muss aber ganz ehrlich sagen, daß ich mit Laptop & Desktop & Server unter gentoo und m740av & tg100 & simpad & slug als embedded-devices doch eher auf der Consumer-Seite stehen möchte ( vor allem weil der WAF immer geringer wird... ).

Klar würd ich meine slug gerne unter gentoo als bacula/torrent/rsync/upnp/iscsi/watt-auch-immer-Server aufsetzen und zudem noch via nullmodemkabel nen Notfallweg zum 'großen' Server haben und vieles vieles mehr, aber was nicht ist, ist halt nicht....

Würde mich halt nur freuen, gentoo endlich auf dem blöden Ding zu haben, so daß ich damit wie mit ner normalen gentoo-Installation umgehen kann, was für mich persönlich bei einer uclibc und big-endian-Installation nicht drin ist...

----------

## nic0000

 *derm1ke wrote:*   

> Würde mich halt nur freuen, gentoo endlich auf dem blöden Ding zu haben, so daß ich damit wie mit ner normalen gentoo-Installation umgehen kann, was für mich persönlich bei einer uclibc und big-endian-Installation nicht drin ist...

 

Ich kenne mich (immer noch) nicht so richtig mit den Sachen aus. Also unter http://embedded.gentoo.hoppix.org/nslu2/ findest du einen Kernel und ein Rootfs welche soweit schon miteinander zusammenarbeiten. Wie weit das jetzt big-endian ist weiß ich nicht aber es läuft schon mal mit ulibc.

----------

## derm1ke

 *nic0000 wrote:*   

>  *derm1ke wrote:*   Würde mich halt nur freuen, gentoo endlich auf dem blöden Ding zu haben, so daß ich damit wie mit ner normalen gentoo-Installation umgehen kann, was für mich persönlich bei einer uclibc und big-endian-Installation nicht drin ist... 
> 
> Ich kenne mich (immer noch) nicht so richtig mit den Sachen aus. Also unter http://embedded.gentoo.hoppix.org/nslu2/ findest du einen Kernel und ein Rootfs welche soweit schon miteinander zusammenarbeiten. Wie weit das jetzt big-endian ist weiß ich nicht aber es läuft schon mal mit ulibc.

 

Genau das ist ja mein Problem. Ich möchte nicht einfach so nen Kernel + rootfs von irgendwo runterladen, sondern selber entscheiden, was reinkommt, und was nicht ( ok, soviel passt nicht in 1M... ). Genauso die uclibc. Da weiss ich ja, daß das funktioniert. Aber ich will halt nen glibc-System. Und daß das geht, haben andere distributionen schon gezeigt.

Vielleicht sollte ich einfach noch ein wenig Geduld haben ( muss ich auch, weil ich gerade daheim alles neu verkabel und bei der Gelegenheit auch den Server neu aufsetze from Scratch ).

Ärgert mich halt nur einfach, hier ne Slug mit akt.USB-Hub, mehreren ESB-Platten/Druckern zu haben und sie nicht wirklich an der slug zu nutzen, weil ich mich so auf gentoo versteift hab.

Aber wie gesagt, die moderne Märklin-Bahn ist halt zeitaufwändig ( und wieder eine Weiche mehr..... )

----------

## nic0000

 *derm1ke wrote:*   

> Ärgert mich halt nur einfach, hier ne Slug mit akt.USB-Hub, mehreren ESB-Platten/Druckern zu haben und sie nicht wirklich an der slug zu nutzen, weil ich mich so auf gentoo versteift hab.

 Dann benutze doch eine andere Distribution. Warum hängst du jetzt so an Gentoo wenn du es "nur" nutzen willst. Debian bzw. der OpenSlug Ableger scheinen mir besser geeignet für dich.

Um auf deine Frage zurück zu kommen warum die Gentoo-Fraktion e nicht hin bekommt auf deine Bedürfnisse einzugehen:

Es gibt einfach zu wenige NSLU2 Gentoo Benutzer und die meisten scheinen andere Probleme/Wünsche zu haben.

Ich z.B. würde mir auch wünschen das andere für mich die Arbeit machen, aber hier ist einfach zu wenig los. Ich habe sogar einigen Leuten die NSLU2 geliehen damit sie sich das mal angucken und die haben alle nur mit OpenSlug gearbeitet und sich toll gefühlt. Glaubst du die hat Gentoo drauf zu ziehen interessiert?

Wenn du eine (oder mehrere) Distribution(en) empfehlen kannst, dann nur Raus damit. Ich würde auch gerne mein Leben vereinfachen.

Ich brauche:

RIAD 1 fest im Kernel und die Fähigkeit auch davon zu booten.

MD als Modul um LVM2 benutzen zu können.

Nice2have:

Wlan über USB.

Ein Terminal-Server um clients diskless zu booten.

Eine Juke Box um via USB-Soundcard Musik abzuspielen (am besten mit LCD und IR Unterstützung)

Am besten eine Distribution die alles kann und welche ich simpel zusammenklicken kann.

Natürlich Kostenlos.

----------

## derm1ke

 *Quote:*   

> Warum hängst du jetzt so an Gentoo wenn du es "nur" nutzen willst.

 

Das mit dem 'nur' nutzen stimmt ja so auch nicht so ganz.

Ich habe mich für gentoo entschieden, eben weil ich die freie Wahl habe, was z.B. in den kernel wandert, ob ich nen modularen Kernel oder nen monolithischen haben möchte und vor allem, welche libs etc. vom system angezogen werden.

 *Quote:*   

> Um auf deine Frage zurück zu kommen warum die Gentoo-Fraktion e nicht hin bekommt auf deine Bedürfnisse einzugehen: 

 

Ich habe an keiner Stelle irgendwem vorgeworfen, nicht auf meine Bedürfnisse einzugehen, es sollte auch in keinster Weise ein Vorwurf an die Gentoo-Entwickler sein, wenn ich genügend Zeit und Ahnung hätte, würde ich selber mithelfen.

Hab ich aber nicht, von daher wollte ich mich mal nach dem aktuellen Stand erkundigen, weil ich schon vorher gesehen hatte, daß ein fertiger Kernel samt rootfs zur Verfügung steht.

Aber damit bin ich wie bei anderen Distributionen davon abhängig, daß jemand anderes die Arbeit macht, und vor allem kann ich dann nicht mehr beeinflussen, was in mein System reinkommt.

 *Quote:*   

> Wenn du eine (oder mehrere) Distribution(en) empfehlen kannst, dann nur Raus damit. Ich würde auch gerne mein Leben vereinfachen. 

 

SlugOSL/E, denn wenn ich dies hier richtig verstehe: http://www.cyrius.com/debian/nslu2/upgrade.html kann man danach so ziemlich alles in den Kernel werfen, weil der eben jetzt von Platte kommt.

----------

## -XoF-

Heyho,

nach langem hab ich mal wieder etwas Zeit gehabt, mich meinem Slug zu widmen. Somit ist jetzt auch das seit langem überfällige Thema "Backup" vom Tisch... :Smile: 

Falls es für den ein oder anderen hier interessant sein sollte:

Ich hab ein kleines/winziges Scriptchen gebastelt, welches nach anstöpseln einer zweiten disk automatisch einen rsync von der ersten Platte auf die Zweite anwirft.

Die Backup-Platte hängt bei mir jetzt an ner Zeitschaltuhr, die die Disk einfach alle vier Tage für einen bestimmten Zeitraum einschaltet.

Wens interessiert:

http://www.devroot.de/projects/nslu2/tools/backup/sbu_install.sh

Das Ding ist mehr oder weniger quick and dirty, dafür gibts schon nen Installer, weil einige meiner mittlerweile auch be-sluggten Bekannten mit Linux nix anfangen können... :Wink: 

BTW, hat von euch jemand "mailx" gegen uclibc gelinkt am Start? Mir scheint, die uclibc bringt ein Headerfile nicht mit, welches mailx benötigt... (wordexp.h)  :Sad: 

Regards,

-XoF-

----------

## -XoF-

BTW,

@chilla:

Das o.g. Backup-Script wär auch ein schöner Anwendungsfall für deine USB-Powerswitch-Geschichte:

Per cronjob Strom auf die Backupplatte geben, nach Beendigung des Backups Strom wieder aus. Wär scho fein.

Was soll das Teil denn fix und fertig löhnen?

-XoF-

----------

## chilla

die kleine platine? 

Die Schaltpläne usw. kannste für umme haben und es dir selbst zusammenlöten. Fertige Platinen dieser Art haben wir leider gerade keine hier rumliegen, aber die Bauteile dafür kommen gerade mal auf 4-5, das löten dauert eben je nach geübtheit.

----------

## -XoF-

Also unbestückte PCBs hast Du da auch nicht für? 

SMD-Bauteile? Dafür würde mir leider Equipment fehlen...

Kannst du mir vielleicht einfach mal den Schaltplan zumailen? Das wär echt supi... :Smile: 

--> xof at devroot dot de

Grüße,

-XoF-

----------

## chilla

Du hast Post.

----------

## mijenix

Hi

Gibts hier noch jemand, der sein nslu2 mit einem neuen 2.6.19er Kernel ausgestattet hat?

Wenn ja, kann mir jemand sagen, welche patches ich für den Kernel brauche?

Und wie ich diesen am besten patche. Oder gibts vielleicht ein neues install how-to?

Die URL von dieser Anleitung funktionieren leider nicht mehr.

Gruss

Mathias

----------

## -XoF-

Hi Mathias,

die aktuellsten URL sollten eigentlich noch funktionieren.

Anleitungen:

http://gentoo-wiki.com/Gentoo_on_NSLU2#Compiling_a_kernel

http://www.devroot.de/projects/nslu2/kernel_build/nslu2-gentoo-kernel-howto.txt

Die aktuellste Kernelversion inkl. Patches im nslu2-linux.org-svn scheint 2.6.20-rc1 zu sein.

Den Firmwarekram für den IXP findest du auf meiner Website:

http://www.devroot.de/projects/nslu2/

HTH,

-XoF-

----------

## mijenix

Hi

Danke für deine Antworten. 

Ich bin da erst seit heute dran, Gentoo auf meinem NSLU2 zum laufen zu bekommen, da ich Debian einfach nicht zum laufen bringe.

Und da ich eigentlich auf allen meinen PC's Gentoo verwende, dachte ich, wieso nicht auch auf dem NSLU2.

Leider habe ich mit embedded Linux und svn noch nie was gemacht. 

Auch verstehe ich nicht, was ich auf der SVN seite von nslu2-linux.org-svn für einen Kernel brauche, oder ob da schon fertig gebackene Kernel finde?

Auch habe ich ein Problem, dass ich nicht chrooten kann, damit ich Gentoo fertig installen kann. 

Der letzte Schritt, den ich machen konnte ist den Portage snapshot entpacken.

Leider erscheint beim chrooten folgende Meldung (DebianSlug-3.10-beta):

 *Quote:*   

> 
> 
> chroot /mnt/gentoo/ /bin/bash
> 
> chroot: cannot execute /bin/bash: Exec format error 
> ...

 

Bist du auch im IRC unterwegs, sonst könnten wir dort mal bisschen Diskutieren   :Wink: 

Gruss

Mathias

----------

## -XoF-

Hi,

1.) IRC ist mir ein Gräuel... :Wink:  - da wirste mich also nicht antreffen

2.) auf svn.nslu2-linux.org findest du die passenden _sourcen_ incl. patches für den Slug. Fertig gebackenes findest du da nicht.

3.) du brauchst nicht wirklich Ahnung von embedded systems oder von SVN um den HowTo's folgen zu können - das ist wirklich alles ziemlich einfach gehalten. Zieh dir einfach mal das HowTo im gentoo-wiki ganz rein - für die Grundinstallation ist die deutsche Version ebenso gut, lediglich den kernel-part hat chilla noch nicht überarbeitet und ich hab mein kernel-howto bisher nur in die englische Version integriert.

4.) das mit dem exec format error liegt schätzungsweise daran, dass du entweder ein Tarball für die falsche Architektur oder mit falscher endianess genommen hast.

5.) Ein wirklich guter Ausgangspunkt für eine saubere Gentoo-uclibc-Installation ist das rootfs das du auf meiner Site findest - damit sparste dir viel Arbeit! Das ganze ist letzlich auch nur ein etwas besserer stage3...

6.) Nachdem du erst heute mit dem shizzle angefangen hast, haste vermutlich diesen Thread hier noch gar nicht komplett gelesen - solltest du unbedingt nachholen, weil das hier quasi ein lebendes HowTo ist. Da kommt ständig neues dazu, altes wird über bord geworfen uswusf....

Really HTH,

-XoF-

----------

## mijenix

Hi

Leider habe ich in diesem Beitrag nichts gefunden. Welches stage3 ist zu benutzen?

Ich habe meines von http://mirror.switch.ch/ftp/mirror/gentoo/experimental/arm/embedded/stages/stage3-armeb-uclibc-softfloat-2005.1.tar.bz2

Ist das nicht das richtige?

Gruss

----------

## oxffffff

 *-XoF- wrote:*   

> BTW, hat von euch jemand "mailx" gegen uclibc gelinkt am Start? Mir scheint, die uclibc bringt ein Headerfile nicht mit, welches mailx benötigt... (wordexp.h) 
> 
> -XoF-

 

Falls die Frage noch aktuell sein sollte oder mal wieder auftaucht: die uclibc muss mit USE-Flag "wordexp" emerget werden.

zur Info: funzt hier mit sys-libs/uclibc-0.9.28 und mail-client/mailx-8.1.2.20040524-r1

----------

## chilla

pling plong  :Smile: 

Sachtmal, habt ihr euch schonmal nach nem vergleichbaren Nachfolger umgeschaut? Ich weiss ja, dass es viele kleine geile embedded-systeme gibt, doch die meisten sind auf Grund ihres Preieses nicht wirklich für den Heimgebrauch zu verwenden. 

ich suche eigentlich sowas wie die slug mit nem Intel XScale 600 mhz ARM Proz drin, (inklusive fpu...) und so 128 - 512 mb ram. Das ganze passivgekühlt.  Fujitsu Siemens verbaut eigentlich genau das in dem loox 720, doch der ist aufgrund des Displays, der Baugröße und des Akkus leider viel zu teuer als dass man ihn einfach mal so zerschlachten könnte  :Sad: 

Naja.. vielleicht hol ich mir ja wirklich mal ne Soekris oder gumstix...

----------

## -XoF-

Moinsen,

ist von euch jemand aufm 23C3? Vielleicht kann man sich ja mal im Hackcenter zum gemeinsamen basteln treffen...?

-XoF-

----------

## chilla

Vorgenommen hatte ich es mir ja eigentlich schon, aber ich muss ma schauen, ob ich das Geld noch irgendwie auftreiben kannn  :Smile: 

----------

## mijenix

Hi

Danke an alle nochmals, die so eine gutes HOWTO erstellt haben!

Ich bin dem (http://gentoo-wiki.com/Gentoo_on_NSLU2) HOWTO gefolgt.

Ich konnte eigentlich alles so machen, wie es da seht und bin nun soweit, den selber gebauten Kernel 2.6.19 von meiner crossdev-Umgebung auf das aktualisierte (emerge -avuDN world) gentoo system auf meiner HD am nslu2 zu übertragen. 

Nur finde ich leider keine Infos, wie man das Livesystem so umbiegt, dass der Kernel direkt von der angestöpselten HD bootet. 

Leider finde ich bei den anderen HOWTO's keine Hilfe, da diese von einer DebianSlug Umgebung ausgehen.

Kann mir das jemand erklären oder gibts da ein separates howto?

Danke.

Gruss

Mathias

----------

## -XoF-

Und, wie schauts aus? Jemand aufm 23C3?

----------

## mijenix

Hi

Wäre gerne gekommen, nur leider zu weit weg. Naja, vielleicht im neuen Jahr mal  :Wink: 

Kann mir nun jemand weiterhelfen, bzgl. dem weiteren Vorgehen mit gentoo und nslu2?

Gruss

Mathias

----------

## -XoF-

Hallo Mathias,

wie gesagt, die Anleitung _funktioniert_!

Allerdings steht dort nirgends, dass der Kernel auf die Festplatte kopiert werden muss - zu Recht, da der Kernel auf den Slug muss (also ins FlashROM)!

Punkt 8.) unter "Compiling a Kernel" sagt dir wies geht. (Das Zauberwort heißt "upslug").

Das Root-FS von der HDD wird automatisch angezogen, wenn in der Kernelconfig die Korrekte Kernel-CMD-Line gesetzt ist (dies ist der Fall, wenn du die beschriebene Kernel-Config verwendet hast).

So please, RTFM!

Sorry for the hard words, but this is really annoying....   :Crying or Very sad: 

Regards,

-XoF-

----------

## mijenix

Hi

Sorry, du hast recht, das steht alles. Ich habe es falsch geschrieben. Ich wusste das der Kernel mit uplsug ins Flash muss.

Aber was nirgends steht und ich auch nicht wusste, war das mit der CMD Line. Um das gings mir eigentlich.

Aber ich habe die config von dir benuzt, also sollte das eigentlich funktionieren.

Merci für deine Hilfe.

Gruss

----------

## mijenix

Hi

Gebe folgendes ein, um die ipx4xx driver auf meiner Workstation cross zu compilen (gegen 2.6.19 kernel). 

Führe folgenden Befehl aus:

 *Quote:*   

> CHOST=armeb-softfloat-linux-uclibc emerge ixp4xx

 

Und bekomme folgende error Meldung:

 *Quote:*   

> 
> 
> /usr/src/linux/include/asm/cacheflush.h:106:2: #error Unknown cache maintainence model
> 
> In file included from /usr/src/linux/include/asm/pgalloc.h:17,
> ...

 

merci & Gruss

----------

## nowrap

hallo!

dies ist eventuell für alle interessant, die probleme haben die uclibc auf der desktop maschine zu emergen.

es gibt wohl mehrere stolpersteine:

1. asm/page.h nicht gefunden

linux-headers kleiner gleich 2.6.20 nutzen, darüber fehlt diese datei

2. endianess fehlerhaft

```
cp /var/tmp/cross/armeb-softfloat-linux-uclibc/portage/cross-armeb-softfloat-linux-uclibc/uc

libc-0.9.28.3/work/uClibc-0.9.28.3/include/endian.h /usr/lib/gcc/armeb-softfloat-linux-uclibc/3.4.6/include/
```

```
cp /var/tmp/cross/armeb-softfloat-linux-uclibc/portage/cross-armeb-softfloat-linux-uclibc/uc

libc-0.9.28.3/work/uClibc-0.9.28.3/include/bits/endian.h /usr/lib/gcc/armeb-softfloat-linux-uclibc/3.4.6/include/bits/
```

3. uses VFP instructions, whereas libuClibc-0.9.28.so does not 

gcc-3.4.6 verwenden. 4.x nutzt eabi für arm, was wohl probleme bereitet, aber patchbar wäre:

http://svn.gumstix.com/gumstix-buildroot/trunk/toolchain/uClibc/

man muss mit gcc-config auf 3.4.6 schalten, sonst läuft der 4.x gcc

4. [wctables.h] Segmentation fault 

folgende USE flags verwenden -iconv -nls

nach vielen kompilierversuchen und googlesuchen habe ich noch fertige pakete entdeckt:

http://tinderbox.dev.gentoo.org/cross-x86/arm-softfloat-linux-uclibc/All/

allerdings ist mein crossdev nun durchgelaufen. mal sehen, ob distcc nun funktionieren wird.

ich habe folgenden aufruf genutzt:

```
UCLIBC_CPU="ARM_XSCALE" ENDIAN="big" USE="--without-float -*" crossdev -v --binutils 2.17 --gcc 3.4.6-r2 --kernel 2.6.20 --libc 0.9.28.3 --ex-gdb --target armeb-softfloat-linux-uclibc

```

evt. geht es auch ohne --without-float

grüsse

.nowrap

----------

## chilla

Ja, hier ists ja ziemlich ruhig geworden. Ich hab die nslu2 mittlerweile auch aufgegeben. reis/leistungs-verhältnis ist mir einfach zu schlecht. 

Jedoch beabsichtige ich, dasganze mal auf die lafonera-box zu übertragen. Andere kleine distributionen (openwrt, etc.) haben es da ja auch schon vorgemacht - jedoch auch nur halbherzig wie bei der nslu2. Als gentoo-user halte ich die sachen für nicht zu gebrauchen. 

Mit nem kleinen Mod bekommt man an die fonera-box eine sd-karte - und somit auch platz für ein gescheites embedded-gentoo. Die Hardware ist "sparsam" ausgelegt. Für kleine Sachen, wie beispielsweise timeserver, oder relaissteuerung (i2c an der fonera ist möglich) ist sie jedoch durchaus zu gebrauchen. 

Hat jemand lust, sich an der Entwicklung zu beteiligen? 

Gruß aus Braunschweig.

----------

## MiC

Hallo

ich wollte jetzt auch mal versuchen ob ich gentoo auf meiner slug zum laufen bekomme. kann mir einer sagen wo ich patches für den 2.6.22er kernel finde? vielen dank schonmal.

MiC

----------

## BlueShark

Hallo,

ich mache mich nun auch an den Verusch Gentoo auf einer LUG zu installieren. Allerdings scheitere ich schon beim chrooten:

```
# chroot /mnt/gentoo/ /bin/bash

chroot: cannot execute /bin/bash: Exec format error

```

Leider ist auch gerade das Gentoo-Wiki down.

Hat jemand einen Tip?

EDIT

X-Post: https://forums.gentoo.org/viewtopic-p-4490390.html

----------

## chilla

Hast du die richtige Architektur und endianess beim kompilieren ausgewählt?

----------

## BlueShark

Habe nun herausgefunden, dass es an den endianess liegt. Die Firmware ist MSB und die Gentoo-Architektur ist LSB. Ich habe verschiedene Dinge ausprobiert, aber bisher keine Firmware gefunden, die LSB kompiliert ist. Kannst du mir bitte mal die Links geben, wo ich die "richtigen" Dateien finde. Auch durch verschärftes suchen habe ich die richtigen Links wohl nicht gefunden.

----------

## BlueShark

Nach längerem suchen habe ich nun etwas triviales herausgefunden.

Auf der Seite http://www.slug-firmware.net gibt ee verschiedene Firmwares. So auch SlugOS/LE 3.10 Beta (NSLU2) und SlugOS/BE 3.10 Beta (NSLU2). Hier steht das LE für Little Endian und das BE für Big Endian. Ferner gibt es stage3-armeb-uclibc-softfloat-2005.1.tar.bz2 und stage3-arm-uclibc-softfloat-2005.1.tar.bz2 wobei das eb big endian bezeichnet.

Eigentlich ziemlich eindeutig, aber irgendwie stand ich da wie der Ochse vorm Berg. Da ich aber wohl nicht der einzige war, der diesen Fehler gemacht hatte, sollte man das vielleicht noch etwas deutlicher ins HowTo aufnehmen.

----------

## Alatariel

Danke für den Tip mit GCC 3.4.6

Den Fehler mit der page.h kann man recht leicht beheben, indem man das Paket aus /usr/portage/distfiles entpackt, die Zeile in der page.h included wird in der ioperm.c auskommentiert und alles neu verpackt.

Danach nur noch mit ebuild /path/to.ebuild digest neue Checksummen generieren und es funktioniert auch.

----------

## chilla

nslu2 ist doch schon out  :Wink:  Nun wird an der Horstbox von dlink gefrickelt  :Smile: [/url]

----------

## tazinblack

 *chilla wrote:*   

> Nun können wir ganz einfach unsere Crosscompile-umgebung erstellen:
> 
> ```
> [16:15:30]|[chilla@chucky]|~$ sudo crossdev armeb-softfloat-linux-uclibc 
> ```
> ...

 

Leider fliegt das bei mit voll auf die Nase :

```

...

>>> Unpacking uClibc-0.9.28.3-patches-1.8.tar.bz2 to /var/tmp/cross/armeb-softfloat-linux-uclibc/portage/cross-armeb-softfloat-linux-uclibc/uclibc-0.9.28.3-r7/work/uClibc-0.9.28.3

 * Applying various patches (bugfixes/updates) ...

 *   10_all_uClibc-svn-r11188-posix_memalign.patch ...

  [ ok ]

 *   20_all_uClibc-0.9.28.3-ai-netdb.patch ...

  [ ok ]

 *   30_all_uClibc-svn-r20834-sys_queue.patch ...

  [ ok ]

 *   40_all_uClibc-svn-r16020-readdir_r.patch ...

  [ ok ]

 *   50_all_uClibc-realpath.patch ...

  [ ok ]

 *   60_all_uClibc-splice-tee.patch ...                                        

  [ ok ]

 *   62_all_uClibc-arm-ioperm.patch ...

  [ ok ]

 *   63_all_uClibc-arm-ioperm-outl.patch ...

  [ ok ]

 * Done with patching

 * Applying various patches (bugfixes/updates) ...

 *   10_all_uClibc-0.9.27-susv3-2.patch ...

  [ ok ]

 *   15_all_uClibc-0.9.27-susv3-ldouble-3.patch ...

  [ ok ]

 * Done with patching

conf.c: In function 'strip':

conf.c:46: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness

conf.c: In function 'conf_askvalue':

conf.c:94: warning: pointer targets in passing argument 1 of 'fgets' differ in signedness

conf.c: In function 'conf_string':

conf.c:187: warning: pointer targets in passing argument 1 of 'strlen' differ in signednessconf.c:188: warning: pointer targets in assignment differ in signedness        

conf.c: In function 'conf_sym':

conf.c:236: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness

conf.c:236: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness

conf.c:236: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness

conf.c:236: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness

conf.c:236: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness

conf.c:236: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness

conf.c:248: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness

conf.c:248: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness

conf.c:248: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness

conf.c:248: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signednessconf.c:248: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness

conf.c:248: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness

conf.c: In function 'conf_choice':

conf.c:350: warning: pointer targets in passing argument 1 of 'fgets' differ in signedness

conf.c:360: warning: pointer targets in passing argument 1 of 'atoi' differ in signedness

conf.c:384: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness

In file included from zconf.tab.c:2125:

confdata.c: In function 'conf_expand_value':

confdata.c:35: warning: pointer targets in passing argument 1 of '__builtin_strchr' differ in signedness

confdata.c:35: warning: pointer targets in assignment differ in signedness

confdata.c:36: warning: pointer targets in passing argument 2 of '__builtin_strncat' differ in signedness

confdata.c:47: warning: pointer targets in passing argument 2 of 'strcat' differ in signedness

confdata.c: In function 'conf_get_default_confname':

confdata.c:58: warning: pointer targets in passing argument 1 of 'conf_expand_va

confdata.c:58: warning: pointer targets in passing argument 1 of 'conf_expand_value' differ in signedness                                                      

confdata.c: In function 'conf_read':

confdata.c:84: warning: pointer targets in passing argument 1 of 'conf_expand_value' differ in signedness

make[1]: armeb-softfloat-linux-uclibc-gcc: Command not found

make[1]: armeb-softfloat-linux-uclibc-gcc: Command not found

make[2]: armeb-softfloat-linux-uclibc-gcc: Command not found

make[2]: armeb-softfloat-linux-uclibc-gcc: Command not found

make[2]: armeb-softfloat-linux-uclibc-gcc: Command not found

make[2]: armeb-softfloat-linux-uclibc-gcc: Command not found

make[2]: armeb-softfloat-linux-uclibc-gcc: Command not found

make[2]: armeb-softfloat-linux-uclibc-gcc: Command not found

make[1]: armeb-softfloat-linux-uclibc-gcc: Command not found

make[1]: armeb-softfloat-linux-uclibc-gcc: Command not found

make[1]: armeb-softfloat-linux-uclibc-gcc: Command not found

make[1]: armeb-softfloat-linux-uclibc-gcc: Command not found

make[1]: armeb-softfloat-linux-uclibc-gcc: Command not found

make[1]: armeb-softfloat-linux-uclibc-gcc: Command not found

make[1]: armeb-softfloat-linux-uclibc-gcc: Command not found

make[1]: armeb-softfloat-linux-uclibc-gcc: Command not found

make[1]: armeb-softfloat-linux-uclibc-gcc: Command not found

make[1]: armeb-softfloat-linux-uclibc-gcc: Command not found

make[1]: armeb-softfloat-linux-uclibc-gcc: Command not found                   

make[1]: armeb-softfloat-linux-uclibc-gcc: Command not found

make[1]: armeb-softfloat-linux-uclibc-gcc: Command not found

make[1]: armeb-softfloat-linux-uclibc-gcc: Command not found

>>> Source unpacked.

>>> Compiling source in /var/tmp/cross/armeb-softfloat-linux-uclibc/portage/cross-armeb-softfloat-linux-uclibc/uclibc-0.9.28.3-r7/work/uClibc-0.9.28.3 ...

make: armeb-softfloat-linux-uclibc-gcc: Kommando nicht gefunden

make: armeb-softfloat-linux-uclibc-gcc: Kommando nicht gefunden

rm -f -r include/bits

install -d include/bits

...

```

Irgendwie findet er den  armeb-softfloat-linux-uclibc-gcc nicht??!

Hat da jemand ne Idee?

----------

## Tigerchen

jo besorg dir irgendwoher ( #gentoo-embedded half mir) nen cross-armeb-softfloat-linux-uclibc-gcc und emerge den mit emerge /path/to/package.tbz2 und besorg dir auch die crossdev-wrappers, dann gets

----------

