mkimage und ppcboot fehlt...

[Markus_Heiden]

Moin,

ich verzweifel noch. Nachdem ich u-boot erstmal mit touch .u-boot übersprungen habe fehlte als nächstes das mkimage.exe in /dbox2/cdk/bin:

mkdir -p pcmcia; \
find kernel -path '*/pcmcia/*' -name '*.o' | xargs -i -r ln -sf ../{} pcmcia
make[1]: Leaving directory `/home/Markus/tuxbox-cvs/cdk/linux-2.4.20'
/dbox2/cdk/bin/mkimage \
-n 'dbox2' -A ppc -O linux -T kernel -C gzip \
-a 00000000 -e 00000000 \
-d linux-2.4.20/arch/ppc/boot/images/vmlinux.gz \
/dbox2/tftpboot/kernel-cdk;
/bin/bash: line 1: /dbox2/cdk/bin/mkimage: No such file or directory
make: *** [.linuxkernel] Error 127

Das habe ich aus einem alten Compilat rüberkopiert. Als dann make all durchgelaufen war, fehlte ppcboot in tftproot. Ein altes ppcboot half hier erstmal weiter. Dann gab es Fehler der Art:

init started: BusyBox v0.61.pre (2003.02.15-11:38+0000) multi-camodprobe: Can't locate module tuxbox
/proc/bus/tuxbox: No such file or directory
Detected STB:
Vendor: Unknown
Model: Unknown
ln: /dev/dvb/adapter0/demux1: No such file or directory
ln: /dev/dvb/adapter0/dvr1: No such file or directory
Please press Enter to activate this console. /proc/bus/tuxbox: No such file or directory
/proc/bus/tuxbox: No such file or directory
LCD (/dev/dbox/lcd0): No such file or directory
/dev/input/event0: No such file or directory

beim Booten (doppelte Zeilen gelöscht). Hier half in rcS das "modprobe tuxbox" in "insmod tuxbox" zu ändern. Ich kenne mich mit Kernel-Modulen zwar nicht aus, aber es würde vielleicht nicht schaden, das auch ins CVS zu übernehmen?

Zu guter Letzt funktioniert jetzt die Kanalsuche (Kabel) nicht mehr, die behauptet nach 1s 0 Transponder gefunden zu haben...

Da wird wohl erstmal eine services.xml helfen...

[obi]

ppcboot wurde von den entwicklern umbenannt und heisst jetzt u-boot (universal bootloader), da er auch andere platformen als ppc unterstuetzt.

[Markus_Heiden]

Danke für die Info. Hilft mir aber nicht wirklich weiter, da u-boot mit dem DBox Bootmanager nicht will (siehe Boot Forum). Habe jetzt erstmal das cdk/Makefile.am (zurück-)gepatcht um wieder ppcboot zu haben -> läuft.

[woglinde]

Hi,

mkimage wird von ppcboot bzw. u-boot in u-boot/tools oder ppcboot/tools gebaut und dann nach
$(hostprefix) kopiert.

Gruss woglinde

[obi]

bootmanager nutzer sollten auch das zum bootmanager gehoerende ppcboot benutzen (da war doch eins, oder?)

mangels source code kann niemand den bootmanager anpassen. u-boot, so wie es konfiguriert ist, laesst sich besser in vorhandene netz-infrastruktur einfuegen, wo bereits ein dhcp server besteht, der aber nicht dem nfs server u.a. entspricht. im ppcboot war das nicht trennbar, was aber nem windoof user eh egal sein kann.

[Homar]

@obi:

das geht so nicht, wenn mann eine andere PPCBoot nimmt, dann meckert das Kernel: "wrong magic"

Ich habe es jedenfalls noch nicht zum booten überreden können.

Klappt das booten mit dem u-boot denn bei dir ??

[obi]

dann musst du eben das passende mkimage benutzen.
ich hab meine boxen im februar erst einmal gebootet, also kann ich dazu nix sagen.

[Homar]

...unter dem tools von u-boot wird der mkimage selber fehlerfrei kompiliert und erzeugt.


Vielleicht sollte ich es mit der alten mkimage.exe versuchen

P.S.: Man lernt nie aus, irgendwie

[Markus_Heiden]

Hi,

wenn man ppcboot weiterbenutzen soll, wäre es prima, wenn im CVS im cdk/Makefile.am der Teil zum Bauen des .ppcboot wieder reinkommt. Dann kann man selbst wählen, was man benutzen will. Mit älteren ppcboot hat man nämlich das Problem, daß diese nicht zum Kernel passen.

Wer es selbst ausprobieren will, kann sich aus dem CVS den letzten Stand des cdk/Makefile.am vor u-boot angucken und im aktuellen cdk/Makefile.am ergänzen. Die Sourcen zu ppcboot sind ja zum Glück noch drin.

Zu meiner ursprünglichen Frage:
Für mich hat sich das geklärt. Da ppcboot nicht mehr gebaut wurde und u-boot nicht kompilierte und ich es aus Unwissen übersprungen habe fehlte natürlich mkimage.

[Homar]

@Markus:

einchecken sollte man es nicht machen, ändere bitte dein Makefile.am so:

Code: Alles auswählen

boot: .u-boot .linuxkernel .driver

.u-boot: .bootstrap $(bootdir)/u-boot/Makefile
	$(MAKE) -C $(bootdir)/u-boot dbox2_config
	$(MAKE) -C $(bootdir)/u-boot CROSS_COMPILE=$(target)-
	$(INSTALL) -m644 $(bootdir)/u-boot/u-boot $(bootprefix)
	$(INSTALL) $(buildprefix)/Patches/cygwin/mkimage.exe $(hostprefix)/bin
if MAINTAINER_MODE
else
	$(MAKE) -C $(bootdir)/u-boot distclean
endif

[Homar]

Nachtrag: klappt irgendwie nicht so ganz...

Obi kannste bitte mal weiterhelfen ???

[obi]

ich versteh grade nicht genau, was das ziel bzw. das problem ist.
ot: funktioniert eigentlich der dhcpd unter cygwin?

[Homar]

Hi obi,

Das booten mit dem u-boot klappt irgendwie nicht und mit ppcboot schein auch der wurm zu stecken.

Erst nachdem ich mkimage.exe aus dem Patches/cygwin geht es. Aber das soll ja kein Zustand bleiben...

+++++

Cygwin benutzt das Netzwerk von Windows. Einen dhcpd besitzt es gar net, ich glauben.

Im DBM sollte doch eigentlich ein tftp-server eingebaut sein. Das reagiert nicht auf die Anfragen. Es scheint, als ob da ein Bug drin steckt.
...fazit: zur Zeit ist sense

[obi]

also in der dhcpd.conf kann man folgenden eintrag machen:

Code: Alles auswählen

        if exists vendor-class-identifier {
                filename "/dbox2/tftpboot/kernel-cdk";
                option root-path "/dbox2/cdkroot";
        } else {
                filename "/dbox2/tftpboot/u-boot";
        }

der bmon sendet keinen vendor class identifier mit. u-boot macht einen neuen dhcp request und bekommt darueber seinen kernel und nfs root pfad mitgeteilt. der windoof bootmanager rafft das nicht. vielleicht kann ja mal jemand, der interesse hat, deshalb field anmailen.

- obi

[dr.sung]

@obi: genau so siehts aus.

Dazu kommt aber noch ein bug im mkimage vom u-boot unter cygwin (falsche byteorder). Deshalb immer "Bad Magic Number"...

siehe auch:
http://tuxbox.berlios.de/forum/viewtopic.php?t=18656

PS: Ist das eigentlich ein 'CDK' oder 'Boot & Kernel' Thema?

Dr.Sung

[obi]

in dem anderen thread schreibst du, dass bad magic number kommt, weil statt kernel der u-boot ein 2. mal geladen wird. da macht der fehler auch sinn. was stimmt denn mit der byte order nicht? die ist auf cygwin ja auch nicht anders als auf x86 linux.

[dr.sung]

in dem anderen thread schreibst du, dass bad magic number kommt, weil statt kernel der u-boot ein 2. mal geladen wird. da macht der fehler auch sinn.

Richtig. Das war der erste Fehler, den ich hatte. War einfach zu erkennen.

was stimmt denn mit der byte order nicht? die ist auf cygwin ja auch nicht anders als auf x86 linux.

Als ich dann mein u-boot geändert habe und endlich den vorher von mkimage (u-boot) erstellten kernel geladen habe, bekamm ich immer nur 'Bad Magic Number' beim Starten vom Kernel.

Der Fehler war schnell gefunden. u-boot erwartet eine Magic Number von $27 05 19 56 (ulong) in genau dieser Reihenfolge. Mein mkimage schreibt allerdings $56 19 05 27 in den Header. Genauso werden die anderen Werte im Header vertauscht.

Nachdem ich in der mkimage.c die #ifdefs von __WIN32__ auf __i386__ geändert hatte, funktionierte es. Der gcc von cygwin definiert nämlich eben nicht das __WIN32__ Makro.

Gruß
Dr.Sung

[obi]

was definiert er denn?
__CYGWIN__ oder sowas?

schau mal, ob #ifdef __CYGWIN32__ und/oder #ifdef __CYGWIN__ funktionieren.

[dr.sung]

@obi

Er definiert beides, __CYGWIN__ und __CYGWIN32__. Und es funktioniert sogar damit.

Wenn überhaupt wäre es sinnvoller __CYGWIN__ zu nehmen, denn mit einem 32-bit Compiler hat das Byteordering ja nix zu tun.

Ich frage mich eher, ob es richtig ist, das von cygwin abhängig zu machen, oder ist es nicht richtig(er) die Architektur der Zielmachine zu berücksichtigen. Insofern wäre __i386__ wohl die bessere Entscheidung. Aber wenn linux das eh mit ner anderen include richtig macht, dann erübrigt sich das wohl.

Es könnte allerdings dann wieder Probleme geben, wenn tätsächlich mit einer Win32 Umgebung (zb Visual Studio) das mkimage übersetzt werden soll... aber macht das überhaupt einer?

Naja, da es ja ein Universal-Bootloader sein soll, wie wär's wenn man __CYGWIN__ und __WIN32__ abprüft?

[obi]

Er definiert beides, __CYGWIN__ und __CYGWIN32__. Und es funktioniert sogar damit.

ok, kannst du mir ein patch schicken, in dem alle notwendigen __WIN32__ durch __CYGWIN32__ ersetzt sind?

cvs diff -up u-boot > u-boot.diff

Wenn überhaupt wäre es sinnvoller __CYGWIN__ zu nehmen, denn mit einem 32-bit Compiler hat das Byteordering ja nix zu tun.

nein, es geht darum, nen ersatz fuer __WIN32__ zu finden, der funktioniert. da ist die 32 schon ok.

Ich frage mich eher, ob es richtig ist, das von cygwin abhängig zu machen, oder ist es nicht richtig(er) die Architektur der Zielmachine zu berücksichtigen.

manche dinge sind unter windows halt anders als unter unix. auch mit cygwin.

Insofern wäre __i386__ wohl die bessere Entscheidung.

linux kommt auch ohne den in __WIN32__ geschachtelten code aus...

[dr.sung]

@obi

u-boot.diff ist unterwegs...

Wie sieht damit aus, dass die Env-Var $(bootpath) auch in den u-boot aufgenommen wird?

[obi]

so, ist im cvs, danke.

boot-path? er bootet ja korrekt, wenn der dhcp server funktioniert. die alten settings wieder hardcoden werde ich nicht. ich bin froh, dass der dhcp server jetzt auf einem anderen rechner laufen kann als der nfs server...

[dr.sung]

ja, kann ich gut verstehen. Aber vielleicht hilft es den Bootmanager-Usern ein wenig...

Gibt es schon eine Antwort von Field zu diesem Thema?

[esetorp]

Hay

ist das neue U-boot vielleicht die Problemlösung für :
http://tuxbox.berlios.de/forum/viewtopi ... aea8cf0e45

noch mal ganz kurz:
Ich möchte mit einem Linux-Server (suse7.3) zwei dboxen mit unterschiedlichen Yadd's unabhängig von einander betreiben.
Bei existierenden (alten) Yadd's.

Wenn ja wie?

Sorry wenn ich nerve ..

Ese

[dr.sung]

Ich glaube schon. Wenn Du den dhcpd richtig konfigurierst dürfte es kein Problem sein.