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
embedded-gentoo auf einer Linksys NSLU2
Message
Moin,
sorry Amarok, habe so ein Image leider nicht anzubieten, da keine funktionierende Installation vorliegt. Und außerdem segfaultet mein partimage andauernd.
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
sorry Amarok, habe so ein Image leider nicht anzubieten, da keine funktionierende Installation vorliegt. Und außerdem segfaultet mein partimage andauernd.
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
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
die bösen blicke meiner frau dagegen schmerzen ganz schön (selbst kaffee muss ich mir schon selbst besorgen) *g*
Amarok
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
die bösen blicke meiner frau dagegen schmerzen ganz schön (selbst kaffee muss ich mir schon selbst besorgen) *g*
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
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
was zum teufel ist eine "openslug-gentoo" variante?
Und wieso verdreht sich mein Magen, wenn ich das lese?
Openslug = böse!
Und wieso verdreht sich mein Magen, wenn ich das lese?
Openslug = böse!
"Democracy is two wolves and a sheep voting on what to have for dinner. Liberty is two wolves attempting to have a sheep for dinner and finding a well-informed, well-armed sheep."
TU-BS Wiki
TU-BS Wiki
@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
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
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
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
Seltsam??? Naja, ich habe das irgendwann im Try&Error Verfahren herausgekitzelt. Ich werde mich bei Gelegenheit mal wieder damit beschäftigen.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.
es wird ja auch ein /dev/rtcX erstellt. Ich habe es mit einem Symlink vergeblich versuchtPfeiffer 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.
Leider habe ich schon wieder fast alles zu diesem Thema vergessen, aber ich bin mit dir
grüße
nico
nico
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
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
"Democracy is two wolves and a sheep voting on what to have for dinner. Liberty is two wolves attempting to have a sheep for dinner and finding a well-informed, well-armed sheep."
TU-BS Wiki
TU-BS Wiki
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.
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:
UPDATE:
1.a) Makefile anpassen:
Damit wird die richtige Endianess und das Buildsystem auf Crosscompile gesetzt.
2.) Intel-Kram beschaffen:
Bei mir liegt jetzt folgendes rum:
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/ke ... fig-2.6.17
Zum selber Konfigurieren:
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.)
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:
Ein erneuter make sollte jetzt durchlaufen. Wenn nicht, hats bei mir zwischenzeitlich geholfen, den bereits gebauten
Kram wegzuwerfen:
6.) Kernel übertragen:
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:
Firmware laden:
Modul laden:
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.
- crossdev 0.9.15-r1
HTH,
-XoF-
PS:
Kernel & Kram gibts hier:
http://www.devroot.de/projects/nslu2/
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.
Mein System ist zwar noch nicht fertig, den scheinbar schwierigsten Teil hab ich aber scheinbar schon hinter mir gelassen: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
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:
Code: Select all
# svn co http://svn.nslu2-linux.org/svnroot/kernel $WD
# cd $WD/trunk
# mkdir downloadsUPDATE:
1.a) Makefile anpassen:
Code: Select all
# cd $WD/trunk
# wget http://www.devroot.de/projects/nslu2/makefile.patch
# patch -p1 < makefile.patch
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
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/ke ... fig-2.6.17
Zum selber Konfigurieren:
Code: Select all
# cd $WD/trunk
# make menuconfig (das ARCH und CHOST Geraffel kann man hier weglassen, weil das Makefile das automatisch macht)
5.)
Code: Select all
# cd $WD/trunk
# makeDie 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:
Code: Select all
# 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
Kram wegzuwerfen:
Code: Select all
# cd $WD/trunk
# rm -rf ixp* lib vmlinuz*
Code: Select all
# cd $WD/trunk
# upslug2 --kernel=vmlinuz-nslu2-2.6.17Der 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:
Code: Select all
slug:# depmod -a
slug:# modprobe ixp400
slug:# mknod /dev/ixNpe c 241 0Code: Select all
slug:# cat /lib/firmware/IxNpeMicrocode.dat > /dev/ixNpeCode: Select all
slug:# modprobe ixp400_eth
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.
- crossdev 0.9.15-r1
HTH,
-XoF-
PS:
Kernel & Kram gibts hier:
http://www.devroot.de/projects/nslu2/
Last edited by -XoF- on Tue Sep 05, 2006 2:33 pm, edited 9 times in total.
The best way to accelerate windows is at 9.81 m/s²
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-
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-
The best way to accelerate windows is at 9.81 m/s²
Hmm, bei mir gibts zwar ein /dev/rtc, aber das zeigt ins Nirvana...nic0000 wrote:es wird ja auch ein /dev/rtcX erstellt. Ich habe es mit einem Symlink vergeblich versuchtPfeiffer 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.
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....
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....
The best way to accelerate windows is at 9.81 m/s²
udev kompilieren
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:
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:
Code: Select all
dragon ~ # echo "KERNEL==\"rtc0\", SYMLINK=\"rtc\"" > /etc/udev/rules.d/10-rtc.rules
The best way to accelerate windows is at 9.81 m/s²
Re: udev kompilieren
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.
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.
grüße
nico
nico
RootFS
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/sl ... .dump.tbz2
Bitte auch das Readme beachten:
http://www.devroot.de/projects/nslu2/readme.rootfs
Zum Entpacken:
Portage hab ich aus Platzgründen gekickt.
Viel Spass.
-XoF-
so, meine Schnecke läuft jetzt soweit.
Ich hab mal das RootFS gedumpt und auf meinen Webserver gestellt:
http://www.devroot.de/projects/nslu2/sl ... .dump.tbz2
Bitte auch das Readme beachten:
http://www.devroot.de/projects/nslu2/readme.rootfs
Zum Entpacken:
Code: Select all
tar xjf slug_rootfs-2.6.17.dump.tbz2
cd $DEST
cat $WD/slug_rootfs-2.6.17.dump | restore -rf -Viel Spass.
-XoF-
The best way to accelerate windows is at 9.81 m/s²
Re: RootFS
Super! Ich freue mich schon richtig auf Feierabend 
Dann habe ich vielleicht endlich mal die Schnecke mit einem "aktuellen" System am laufen.
Dann habe ich vielleicht endlich mal die Schnecke mit einem "aktuellen" System am laufen.
grüße
nico
nico
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!
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!
"Democracy is two wolves and a sheep voting on what to have for dinner. Liberty is two wolves attempting to have a sheep for dinner and finding a well-informed, well-armed sheep."
TU-BS Wiki
TU-BS Wiki
hmpff,
eine "Kleinigkeit" passt wohl doch noch nicht so ganz. Einige ebuilds lassen sich nicht kompilieren (z.B. uclibc, gcc, nfs-utils):
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-
eine "Kleinigkeit" passt wohl doch noch nicht so ganz. Einige ebuilds lassen sich nicht kompilieren (z.B. uclibc, gcc, nfs-utils):
Scheint mir ein tieferes Problem mit der Toolchain (libtool?) zu sein....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
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-
The best way to accelerate windows is at 9.81 m/s²
@ 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?
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?
"Democracy is two wolves and a sheep voting on what to have for dinner. Liberty is two wolves attempting to have a sheep for dinner and finding a well-informed, well-armed sheep."
TU-BS Wiki
TU-BS Wiki
Ja, da hab ich doch glatt vergessen was zu erwähnen...
Das Makefile muss natürlich wie hier schon mal beschrieben wurde editiert werden:
--> http://www.devroot.de/projects/nslu2/makefile.patch
beim
musst du dann nix mehr übergeben, da:
HTH,
-XoF-
Das Makefile muss natürlich wie hier schon mal beschrieben wurde editiert werden:
Code: Select all
# 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
Code: Select all
# cd $WD/trunk
# patch -p1 < makefile.patch
Code: Select all
# cd $WD/trunk
# make menuconfig
Code: Select all
# grep menuconfig Makefile
menuconfig: linux-${REVISION}/.config
${MAKE} -C linux-${REVISION} ARCH=arm CROSS_COMPILE=${CROSS_COMPILE} menuconfig
#HTH,
-XoF-
The best way to accelerate windows is at 9.81 m/s²
So, hab jetzt http://forums.gentoo.org/viewtopic-p-35 ... ml#3551345
nochmal überarbeitet und die Anleitung an nem frischen svn-checkout ausprobiert -> kernel kompiliert.
Sollte jetzt also so passen.
bye,
-XoF-
nochmal überarbeitet und die Anleitung an nem frischen svn-checkout ausprobiert -> kernel kompiliert.
Sollte jetzt also so passen.
bye,
-XoF-
The best way to accelerate windows is at 9.81 m/s²
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-
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-
The best way to accelerate windows is at 9.81 m/s²
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...
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...
Gruß
Pfeiffer
Pfeiffer