View previous topic :: View next topic |
Author |
Message |
Amarok n00b

Joined: 11 Nov 2003 Posts: 70
|
Posted: Thu Aug 10, 2006 5:52 am Post subject: |
|
|
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 |
|
Back to top |
|
 |
Vollkorn n00b

Joined: 02 Oct 2004 Posts: 41
|
Posted: Thu Aug 10, 2006 7:59 pm Post subject: |
|
|
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 |
|
Back to top |
|
 |
Amarok n00b

Joined: 11 Nov 2003 Posts: 70
|
Posted: Fri Aug 11, 2006 2:17 am Post subject: |
|
|
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 |
|
Back to top |
|
 |
Vollkorn n00b

Joined: 02 Oct 2004 Posts: 41
|
Posted: Fri Aug 11, 2006 6:00 am Post subject: |
|
|
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 |
|
Back to top |
|
 |
Amarok n00b

Joined: 11 Nov 2003 Posts: 70
|
Posted: Fri Aug 11, 2006 6:26 am Post subject: |
|
|
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 |
|
Back to top |
|
 |
chilla Apprentice

Joined: 12 Dec 2004 Posts: 203 Location: Heidelberg, Germy
|
Posted: Fri Aug 11, 2006 9:24 am Post subject: |
|
|
was zum teufel ist eine "openslug-gentoo" variante?
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 |
|
Back to top |
|
 |
Amarok n00b

Joined: 11 Nov 2003 Posts: 70
|
Posted: Fri Aug 11, 2006 9:47 am Post subject: |
|
|
@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 |
|
Back to top |
|
 |
Pfeiffer n00b


Joined: 18 Aug 2006 Posts: 23 Location: Ripsdorf
|
Posted: Fri Aug 18, 2006 10:02 pm Post subject: |
|
|
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 |
|
Back to top |
|
 |
nic0000 l33t


Joined: 25 Sep 2005 Posts: 658
|
Posted: Fri Sep 01, 2006 10:50 pm Post subject: |
|
|
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
Leider habe ich schon wieder fast alles zu diesem Thema vergessen, aber ich bin mit dir  _________________ grüße
nico |
|
Back to top |
|
 |
chilla Apprentice

Joined: 12 Dec 2004 Posts: 203 Location: Heidelberg, Germy
|
Posted: Sat Sep 02, 2006 9:44 am Post subject: |
|
|
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  _________________ "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 |
|
Back to top |
|
 |
-XoF- n00b


Joined: 31 Aug 2006 Posts: 26 Location: Benz-Town
|
Posted: Sun Sep 03, 2006 11:48 am Post subject: |
|
|
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: Code: |
# svn co http://svn.nslu2-linux.org/svnroot/kernel $WD
# cd $WD/trunk
# mkdir downloads |
UPDATE:
1.a) Makefile anpassen:
Code: |
# 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:
Code: |
# 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.) Code: |
# 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:
Code: | # 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:
Code: |
# cd $WD/trunk
# rm -rf ixp* lib vmlinuz*
|
6.) Kernel übertragen:
Code: | # 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:
Code: |
slug:# depmod -a
slug:# modprobe ixp400
slug:# mknod /dev/ixNpe c 241 0 |
Firmware laden:
Code: |
slug:# cat /lib/firmware/IxNpeMicrocode.dat > /dev/ixNpe |
Modul laden:
Code: |
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.
- crossdev 0.9.15-r1
HTH,
-XoF-
PS:
Kernel & Kram gibts hier:
http://www.devroot.de/projects/nslu2/ _________________ The best way to accelerate windows is at 9.81 m/s²
Last edited by -XoF- on Tue Sep 05, 2006 2:33 pm; edited 9 times in total |
|
Back to top |
|
 |
-XoF- n00b


Joined: 31 Aug 2006 Posts: 26 Location: Benz-Town
|
Posted: Sun Sep 03, 2006 2:10 pm Post subject: |
|
|
BTW,
das Netzwerkinterface heisst bei mir eth0, nicht ixp0.
Interessanterweise gibts auch noch ein eth1. Weiss da jemand was drüber?
-XoF- _________________ The best way to accelerate windows is at 9.81 m/s² |
|
Back to top |
|
 |
-XoF- n00b


Joined: 31 Aug 2006 Posts: 26 Location: Benz-Town
|
Posted: Sun Sep 03, 2006 4:02 pm Post subject: |
|
|
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- _________________ The best way to accelerate windows is at 9.81 m/s² |
|
Back to top |
|
 |
-XoF- n00b


Joined: 31 Aug 2006 Posts: 26 Location: Benz-Town
|
Posted: Sun Sep 03, 2006 7:01 pm Post subject: |
|
|
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...
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² |
|
Back to top |
|
 |
-XoF- n00b


Joined: 31 Aug 2006 Posts: 26 Location: Benz-Town
|
Posted: Sun Sep 03, 2006 8:57 pm Post subject: 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:
Code: | 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² |
|
Back to top |
|
 |
nic0000 l33t


Joined: 25 Sep 2005 Posts: 658
|
Posted: Sun Sep 03, 2006 11:37 pm Post subject: 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. _________________ grüße
nico |
|
Back to top |
|
 |
-XoF- n00b


Joined: 31 Aug 2006 Posts: 26 Location: Benz-Town
|
|
Back to top |
|
 |
nic0000 l33t


Joined: 25 Sep 2005 Posts: 658
|
Posted: Mon Sep 04, 2006 2:11 pm Post subject: Re: RootFS |
|
|
Super! Ich freue mich schon richtig auf Feierabend
Dann habe ich vielleicht endlich mal die Schnecke mit einem "aktuellen" System am laufen. _________________ grüße
nico |
|
Back to top |
|
 |
chilla Apprentice

Joined: 12 Dec 2004 Posts: 203 Location: Heidelberg, Germy
|
Posted: Mon Sep 04, 2006 6:20 pm Post subject: |
|
|
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! _________________ "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 |
|
Back to top |
|
 |
-XoF- n00b


Joined: 31 Aug 2006 Posts: 26 Location: Benz-Town
|
Posted: Mon Sep 04, 2006 8:08 pm Post subject: |
|
|
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- _________________ The best way to accelerate windows is at 9.81 m/s² |
|
Back to top |
|
 |
chilla Apprentice

Joined: 12 Dec 2004 Posts: 203 Location: Heidelberg, Germy
|
Posted: Tue Sep 05, 2006 11:26 am Post subject: |
|
|
@ 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? _________________ "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 |
|
Back to top |
|
 |
-XoF- n00b


Joined: 31 Aug 2006 Posts: 26 Location: Benz-Town
|
Posted: Tue Sep 05, 2006 2:03 pm Post subject: |
|
|
Ja, da hab ich doch glatt vergessen was zu erwähnen...
Das Makefile muss natürlich wie hier schon mal beschrieben wurde editiert werden:
Code: |
# 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: |
# cd $WD/trunk
# patch -p1 < makefile.patch
|
beim
Code: | # cd $WD/trunk
# make menuconfig
| musst du dann nix mehr übergeben, da:
Code: | # 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² |
|
Back to top |
|
 |
-XoF- n00b


Joined: 31 Aug 2006 Posts: 26 Location: Benz-Town
|
Posted: Tue Sep 05, 2006 3:33 pm Post subject: |
|
|
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- _________________ The best way to accelerate windows is at 9.81 m/s² |
|
Back to top |
|
 |
-XoF- n00b


Joined: 31 Aug 2006 Posts: 26 Location: Benz-Town
|
Posted: Wed Sep 06, 2006 10:52 pm Post subject: |
|
|
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- _________________ The best way to accelerate windows is at 9.81 m/s² |
|
Back to top |
|
 |
Pfeiffer n00b


Joined: 18 Aug 2006 Posts: 23 Location: Ripsdorf
|
Posted: Fri Sep 22, 2006 9:37 am Post subject: |
|
|
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... _________________ Gruß
Pfeiffer |
|
Back to top |
|
 |
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|