Verbesserungen am Image-Build-Prozess

[Barf]

Hallo Image-Bastlers und die, die es gerne werden möchten:

nachdem ich so viel Zeit mit dem Lernen des Imagebuildens verplempert hat, möchte ich gerne mit einige Verbesserungen an den, erlich gesagt, beschissene, cdk image build Process beitragen. Dazu habe ich ein Patch-Kit als

http://www.bengt-martensson.de/dbox2/imagekit.tar.gz

abgelegt. Auspacken in $CVSDIR. Dies wird einige Files übeschriben, aber die sind sowieso in CVS. Danach kannst du mit, z.B.

./configure --prefix=/dbox2 --with-cvsdir=/tuxbox/head \
--enable-maintainer-mode --with-targetruleset=flash \
--with-flashchips=2x --with-imagetype=mixed

konfigurieren für ein mixed image für ein dBox mit 2 Flashchips, oder

./configure --prefix=/dbox2 --with-cvsdir=/tuxbox/head \
--enable-maintainer-mode --with-targetruleset=flash \
--with-flashchips=1x --with-imagetype=jffs2only


für ein jffs2only image für ein dBox mit 1 Flashchip. Danach, bei Bedarf
ein/zwei personalisierungsskripte anpassen, und, z.B.,

make flash-neutrino-all
make image

und dein Image ist fertig. Ausführige Doku im Paket (English only).

Ich wurde mich freuen, falls die Developers das Ding im CDK integrieren wurde.

Fragen, Bemerkungen in diesem Forum.

Und dann haben wir ein neues Warmduschersynonym: Fertigimageflasher!

Keep hacking,

Barf

[Unchained]

Hm. Danke, werde es bei Gelegenheit mal testen....

[Sepp776]

Mal ne ganz doofe Frage: Muss man eigentlich den ganzen Krempel neu machen, wenn man schon ne laufende Yadd hat? Da müsste man doch den größten Teil von übernehmen können oder?

Auf meiner alten Gurke kriegt man echt nen Bart wenn man alles kompiliert

Ciao,
Sepp.

[kerlimann]

Mal ne ganz doofe Frage: Muss man eigentlich den ganzen Krempel neu machen, wenn man schon ne laufende Yadd hat? Da müsste man doch den größten Teil von übernehmen können oder?

was genau meinst du jetzt?

also einzelne module compilen mit "make .driver", etc.. (natuerlich ".driver" vorher in deinem cdk loeschen).

oder meinst du, eine yadd als flash laufen zu lassen? dafuer ist eigentlich "make rebuild-flash" gedacht.

[Sepp776]

@kerlimann: ich meinte letzteres. make rebuild-flash? Nie gehört Probiere ich die Tage mal aus...

CU,
Sepp.

[kerlimann]

@kerlimann: ich meinte letzteres. make rebuild-flash? Nie gehört Probiere ich die Tage mal aus...

hab ich ehrlich gesagt nie probiert, ohne targetruleset=flash im ./configure <g>. oder hast du den parameter eh angegeben? dann zuckt das auf jeden fall.

[kerlimann]

hi Barf,

nachdem ich so viel Zeit mit dem Lernen des Imagebuildens verplempert hat, möchte ich gerne mit einige Verbesserungen an den, erlich gesagt, beschissene, cdk image build Process beitragen.

leider hat die ganze geschichte eine recht kurze lebensdauer - soviel zum thema "zeit verplempern"

ich habe in das archiv gerade mal reingesehen, und stelle fest, das du komplette dateien schlichtweg ersetzt, zum beispiel direkt im ersten subdir /boot die "dbox2.h". sowas geht natuerlich nur solange gut, sofern sich im CVS nichts grundlegendes an dieser datei aendert. ansonsten ist dein patchkit naemlich nicht mehr aktuell. das kann wochen dauern, kann aber auch schon morgen sein - who knows.

ich wuerde vorschlagen das du dies alles mit diffs erledigst, sofern es ja ein patchkit ist. dann sieht man bei der ausfuehrung dessen umgehend, sofern etwas rejected wird, und kann manuell hand anlegen.

ansonsten sicher eine nette idee - find ich gut!

[Barf]

@kerlimann:

ileider hat die ganze geschichte eine recht kurze lebensdauer

Mir ist (natürlich) die Probleme mit "branched development" bekannt. (Glaubtest du was anderes?) Mein Ziel ist aber nicht einem Patch mit "Lebensdauer" zu unterhalten, sondern ich will das Ding in CVS eingecheckt und committed sehen. (Sollte von dem erste Posting klar sein.) Leider gibt es im Projekt keine offizielle Anlaufstelle für Patches. (Ich halte eigentlich nicht viel von dem "Projektorganisation".) Weil ich nicht schreibrecht in
CVS habe (und dies ist auch nicht mein Ziel) habe ich die Verbesserung in diesem Forum veröffentligt.

Ehrlich gesagt, ich kann mich kaum ein Grund vorstellen, die Änderungen nicht zu übernehmen.

Zweitens, soo schlimm ist es nicht: Die update-funktionalität in CVS hat gute "merge"-fähigkeiten. In diesem Sinn ist die Ersatzfiles genau so robust wie dein vorgeschlagenes "Patch-kit".

Es wäre besser, die Devs "unter Druck zu setzen" um die Verbesserung zu committen, als mich zu bitten das Ganze unzuverpacken -- noch mehr Zeit verplempern.

Barf

[Barf]

Muss man eigentlich den ganzen Krempel neu machen, wenn man schon ne laufende Yadd hat?

Schwierige Frage. Das Problem ist das der configure/make-Vorgang nicht ausgelegt ist um sowohl images als yadds zu bauen, sonden nur eines davon. So wird ein image-build sowohl
$PREFIX/cdkroot aus auch $PREFIX/tftpboot/u-boot und $PREFIX/tftpboot/kernel-cdk mit nicht-yadd-fähige Dateien überschrieben!! Das Quellbaum wird anderes konfiguriert bei yadd und flash. Am mindestens trifft dies für den kernel, busybox und u-boot zu. Ferner sind die Optimierungsoptionen bei dem Kompiler anderes.

Probiere folgendes:

1. Sichere cdkroot (aber nicht entfernen), und sichere u-boot, kernel-cdk (entfernen ist ok).
2. Putzen. Am mindestens

cd $BUILDDIR/cdk
rm -rf linux linux-2.4.22 .linuxdir .linuxkernel .busybox .u-boot
(cd ../boot/u-boot; make clean)

3. autogen.sh
4. Geeignete ./configure-Kommando
5. Z.B. make flash-neutrino-all
6. make image
7. Nach Erfolg kanns du die originale cdkroot, u-boot und kernel-cdk wiederherstellen, um den yadd wieder zu reparieren.

Falls dies nicht funktioniert, putze "etwas gründlicher" in Schritt 2. make distclean ist das ultimative...

und vergiss was kerlimann über make rebuild-flash sagte... das ist was völlig anderes.

Ideal sollte das configure/Make-Zeuge "etwas" umzuschreiben werden

Barf

[kerlimann]

>Mir ist (natürlich) die Probleme mit "branched development" bekannt.
naja, das "natuerlich" kann man sicherlich nicht hellsehen.

>(Glaubtest du was anderes?)
s.o. dein nick war mir bisher nicht gelaeufig, inwiefern sollte ich was anderes annehmen?

>Mein Ziel ist aber nicht einem Patch mit "Lebensdauer" zu unterhalten,
>sondern ich will das Ding in CVS eingecheckt und committed sehen. (Sollte
> von dem erste Posting klar sein.)
das war sicherlich von deinem posting ersichtlich, jedoch hast du IMHO den falchen weg eingeschlagen.

>Leider gibt es im Projekt keine offizielle Anlaufstelle für Patches.
nicht?
also gerade hier, wo du postest, findest du sticky:
http://tuxbox.berlios.de/forum/viewtopic.php?t=25054

>(Ich halte eigentlich nicht viel von dem "Projektorganisation".)
nunja, wildes commiten ist ja auch nicht der hit, oder?

>Weil ich nicht schreibrecht in
>CVS habe (und dies ist auch nicht mein Ziel) habe ich die Verbesserung in
>diesem Forum veröffentligt.
es sind aber keine "verbesserungen" in dem sinne. dein ziel sollte ein diff sein, speziell in punkto "Makefile.am". nur so kann dieses einfliessen.

>Ehrlich gesagt, ich kann mich kaum ein Grund vorstellen, die Änderungen
>nicht zu übernehmen.
also ich schon. weil - es sind keine diffs. man muesste sich deinen kompletten source durchsehen, wer hat da schon zeit fuer?

>Zweitens, soo schlimm ist es nicht: Die update-funktionalität in CVS hat
>gute "merge"-fähigkeiten.
selbstverstaendlich. nur ist da alle paar wochen ende mit. ich rede aus erfahrung.

>In diesem Sinn ist die Ersatzfiles genau so
>robust wie dein vorgeschlagenes "Patch-kit".
aber sicherlich nicht erwuenscht.

>Es wäre besser, die Devs "unter Druck zu setzen" um die Verbesserung zu
> committen, als mich zu bitten das Ganze unzuverpacken -- noch mehr
>Zeit verplempern.

hae? sag mal, kann das sein, das du unheimlich von dir selbst eingenommen bist?

ps: dich bittet doch eh keiner. du bietest etwas an, thats all.

[thegoodguy]

@kerlimann: Ball flach halten - ich finde es immer erfreulich, wenn jemand was beitraegt. diff kann ja man auch selbst aufrufen, also dies sollte nicht das Hindernis sein.
@Barf: bzgl.:

Code: Alles auswählen

AC_ARG_WITH(flashchips,
        [  --with-flashchips=TYPE  one or two flashchips in dbox? [[1x,2x]]],
        [flashchips="$with_flashchips"],[flashchips="NONE"])

Waere es nicht evtl. besser am Ende stets fuer beide Varianten ein Image zu generieren?

[alsuffndruff]

Halo zusammen,
ich habe mich bis zum Erscheinen dieser "Patches" nicht an das erstellen von imgaes gewagt mangels Zeit. Yadds sind kein Problem.
Um das imagekit auszuprobieren habe ich mir deshalb die aktuellen Sourcen aus dem cvs geholt (15.11) und fuer eine yadd durchcompiliert, kein Problem.
Nach einem "make distclean" und auspacken des imagekit habe ich dann versucht ein "mixed" image fuer eine Sagem 1X Box zu erzeugen. Da kam es dann zu der Fehlermeldung (bitte nicht durch das yadd im Pfadnamen taeuschen lassen):
.
.
.
find /export/home/ldbox2/yadd/compiled/cdkflash/root/lib -maxdepth 1 -type f -o -type l | xargs rm -f
cp -pa /export/home/ldbox2/yadd/compiled/cdkroot/lib/libnss_dns-?.*.so /export/home/ldbox2/yadd/compiled/cdkflash/root/lib
cp -pa /export/home/ldbox2/yadd/compiled/cdkroot/lib/libnss_files-?.*.so /export/home/ldbox2/yadd/compiled/cdkflash/root/lib
/usr/bin/mklibs --target powerpc-tuxbox-linux-gnu --ldlib ld.so.1 --libc-extras-dir /export/home/ldbox2/yadd/compiled/cdkroot/lib/libc_pic \
-d /export/home/ldbox2/yadd/compiled/cdkflash/root/lib \
-D -L /export/home/ldbox2/yadd/compiled/cdkroot/lib \
--root /export/home/ldbox2/yadd/compiled/cdkflash/root \
`find /export/home/ldbox2/yadd/compiled/cdkflash/root/bin/ -path "*bin/?*"` \
`find /export/home/ldbox2/yadd/compiled/cdkflash/root/lib/ -name "libnss_*"` \
`find /export/home/ldbox2/yadd/compiled/cdkflash/root/lib/tuxbox/ -name "*.so" -type f` \
`find /export/home/ldbox2/yadd/compiled/cdkflash/root/sbin/ -path "*sbin/?*"`
I: library reduction pass 1
799 symbols, 762 unresolved
Traceback (most recent call last):
File "/usr/bin/mklibs", line 469, in ?
raise "No library provides non-weak " + symbol
No library provides non-weak FBSetColorEx
make: *** [/export/home/ldbox2/yadd/compiled/cdkflash/.lib] Error 1

Hat jemand aehnliche Versuche schon gemacht und dafuer eine Loesung? Kann es daran liegen, dass die Dateien des imagekit wichtige Neuerungen schon ueberschrieben haben (allerdings scheinen die neuesten Makefile.am und configure.ac schon 4 Wochen alt zu sein)? Ich kann das checken, wuesste aber gerne, ob da jemand schon rumprobiert hat und mein Problem vielleicht schon geloest hat.
Oder bin ich bisher der einzige, der damit Versuche macht (weil hier im Thread irgendwie nix passiert)? Kann ich mir eigentlich icht vorstellen.

Meldet euch
Gruss
Kai


@barf: So wie ich das verstehe, sind die Shellescripte vor allen Dningen dazu da, um eigene Einstellunegn direkt zu uebernehmen. Das bedeutet dann wohl, dass es fuer einen ersten Versuch (ohne eigene Einstellungen) langen muesste, mittels der shellscripte die ucodes an die richtige Stelle zu kopieren? Oder MUSS man andere Dinge darin noch machen, die ich hier nicht erkenne?

[Barf]

@thegoodguy,

Danke für deine konstruktive Bemerkungen. Ich glaube es wäre noch besser, die Konfigurationsoption zu eliminieren, und anstett unterschideliche make-targets einzuführen, z.B. image-1x und image-2x. Ferner sollte mann vielleicht die konfigurationsoptionen --with-targetset=[standard, flash] und --with-imagetype=[mixed,jffs2only] zu, z.B.,--with-target=[yadd,mixed-flash, jffs2onl-flash] mergen?

Barf

[Barf]

ich habe mich bis zum Erscheinen dieser "Patches" nicht an das erstellen von imgaes gewagt mangels Zeit. Yadds sind kein Problem.

freut mich

Nach einem "make distclean" und auspacken des imagekit habe ich dann versucht ein "mixed" image fuer eine Sagem 1X Box zu erzeugen.

Nur ein Tipp: Es ist tatsächlich leichter, erfolgreich jffs2only images zu erstellen; es kann einfach mehr Sachen schiefgehen bei mixed images. (Aber nicht relevant für dein Problem.)

/usr/bin/mklibs --target powerpc-tuxbox-linux-gnu --ldlib ld.so.1 --libc-extras-dir /export/home/ldbox2/yadd/compiled/cdkroot/lib/libc_pic \
-d /export/home/ldbox2/yadd/compiled/cdkflash/root/lib \
-D -L /export/home/ldbox2/yadd/compiled/cdkroot/lib \
--root /export/home/ldbox2/yadd/compiled/cdkflash/root \
`find /export/home/ldbox2/yadd/compiled/cdkflash/root/bin/ -path "*bin/?*"` \
`find /export/home/ldbox2/yadd/compiled/cdkflash/root/lib/ -name "libnss_*"` \
`find /export/home/ldbox2/yadd/compiled/cdkflash/root/lib/tuxbox/ -name "*.so" -type f` \
`find /export/home/ldbox2/yadd/compiled/cdkflash/root/sbin/ -path "*sbin/?*"`
I: library reduction pass 1
799 symbols, 762 unresolved
Traceback (most recent call last):
File "/usr/bin/mklibs", line 469, in ?
raise "No library provides non-weak " + symbol
No library provides non-weak FBSetColorEx
make: *** [/export/home/ldbox2/yadd/compiled/cdkflash/.lib] Error 1

Dein mklibs kotzt. Welche Version verwendest du? Suche das Forum nach mklibs-Probleme. Hat aber nicht mit dem imagekit zu tun. (Es gibt ein Anzahl beiträge, wahrscheinlich teils wiederspruchliche, welche Versionen von mklibs, mkfs.fss2, mkcramfs "mann verwenden soll".)

Kann es daran liegen, dass die Dateien des imagekit wichtige Neuerungen schon ueberschrieben haben

Nein. Du kannst auch nach imagekit ein cvs update machen, falls du meldungen wie

M cdk/Makefile.am
M cdk/configure.ac


bedeutet es, dass Änderugen nicht in Konflikt stehen. Falls diese Datein sich in CVS ändern, werden die Änderungen, soweit sie nicht in Konflikt stehen, gemerged. (Falls die wirklich in Konflikt stehen, dann sagt das Programm so. (Falls dies passiert, bitte in Forum posten!)) Aber letztenlich ist das imagekit nicht als "Der Barf-Patch", sondern für CVS integration gedacht.

So wie ich das verstehe, sind die Shellescripte vor allen Dningen dazu da, um eigene Einstellunegn direkt zu uebernehmen. Das bedeutet dann wohl, dass es fuer einen ersten Versuch (ohne eigene Einstellungen) langen muesste, mittels der shellscripte die ucodes an die richtige Stelle zu kopieren? Oder MUSS man andere Dinge darin noch machen, die ich hier nicht erkenne?

Die my-* skripte sind da, um

1. Bugs in CVS-Kode auszubügeln. So ist z.B. /etc/init.d/start_neutrino nicht ausführbar, und /etc/init.d/rcS absolut ungeeignet für ein Kernel mit read-only root-filesystem (wie ein mixed-image). (Eine mehr geeignete rcS (von AlexW inspieriert) ist Bestandteil meines Kits.)

2. Persönliche Einstellungen übernehmen, z.B. die *.conf-Dateine

3. Personliche Preferenzen, z.B. Mount-punkte anlegen.

Es war nicht mein Ziel, "fertige" my-* skripte zu schreiben. Has du Verbesserungen oder Verbesserungsvorschlage: posten!

Barf

[alsuffndruff]

Hallo Barf
erstmal danke fuer die schnelle Antwort.

Dein mklibs kotzt. Welche Version verwendest du? Suche das Forum nach mklibs-Probleme.

Ich compiliere unter debian Linux, unstable. Meine tools haben die Version
mklibs: 0.1.12, deinstalliere ich jetzt ud nehme mklibs.py.....
mkfs.fss2 1.19
mkcramfs hmm, unter debian heisst das paket cramfsprogs, version 1.1-4
Danke fuer den Hinweis, ich checke das mit den Versionen.

Nein. Du kannst auch nach imagekit ein cvs update machen, falls du meldungen wie
M cdk/Makefile.am
M cdk/configure.ac

Schon klar, nur wenn sich zwischen deiner Version und der von mir aktuell ausgecheckten etwas veraendert hat, dann ueberschreibe ich ja die aktuelle Version. In diese Richtung ging meine Frage. Alles klar, sollte kein Problem sein.

Die my-* skripte sind da, um
1. Bugs in CVS-Kode auszubügeln. .../etc/init.d/start_neutrino nicht ausführbar, und /etc/init.d/rcS absolut ungeeignet...

Bedeutet das, du behandelst Bugs im cvs unterschiedlich, d.h. im einen Fall ersetzt du Dateien durch die im imagekit, im anderen Fall kopierst du Sie erst während der Imageerstellung drüber? Waere es da nicht einfacher, deine Dateien gleich in die richtigen Verzeichnisse (also cdk/root/etc/init.d) zu legen und so die Skripte einfacher zu halten? Ausserdem haette man dann nicht zwei verschiedene start_neutrino bzw. rcS files. Setzt natuerlich voraus, dass deine Aenderungen von den Entwicklern abgenommen werden, aber das gilt fuer die anderen FIles auch.
Oder verstehe ich vieleicht etwas falsch und man muss diese Dateien aus anderen Gründen später kopieren, dann betrachte diese Bemerkung als gegenstandslos

Ansonsten nochmal danke für deine Mühe, sollte ich in naher Zukunft dank deiner Arbeit in die Lage versetzt werden, images zu compilieren, dann waere das gigantisch (mich wundert nach wie vor die geringe Resonanz in diesem Thread, ich dachte das wollen dutzende von Leuten, zumindest wenn man hier die Threads im Board betrachtet.
Gruss

[Barf]

Hallo,

zu den Hilfsprogramme:

Das Zusammensammeln von den Supportprogrammen (mklibs, fakeroot, mkcramfs, mkfs.jffs2) ist noch eine schwarze Kunst, was niemand aufgeräumt hat. Falls ich mich richtig erinnere:

mklibs: nur spezialversion auf Homers site remote-admin.info geht,
mkfs.jffs2: nur neue Versionen (z.B. 1.39) funktionieren, ich habe es in cvs bei infradead.org efunden
mkcramfs: sourceforge? unkritisch?
fakeroot: google, unkritisch?

Natürlich wäre es wünschenswert die schwarte Magie mit Wissenschaft zu ersetzen

Schon klar, nur wenn sich zwischen deiner Version und der von mir aktuell ausgecheckten etwas veraendert hat, dann ueberschreibe ich ja die aktuelle Version.

Ja. Und danach machst du ein cvs update (cvs -z3 up -dP) . Falls die Änderungen nicht in Konflikt steht, wird das cvs-Programm die Änderungen mergen. Genau in die Meldungen lesen!

Bedeutet das, du behandelst Bugs im cvs unterschiedlich, d.h. im einen Fall ersetzt du Dateien durch die im imagekit, im anderen Fall kopierst du Sie erst während der Imageerstellung drüber?

Streng genommen, ja. Mein Ziel mit dem Imagekit war der Prozeß zu verbessern, nicht alle mir bekannte Bugs zu beheben. Wichtiger noch, die my-* skripte brauchen mann sowieso.

mich wundert nach wie vor die geringe Resonanz in diesem Thread, ich dachte das wollen dutzende von Leuten, zumindest wenn man hier die Threads im Board betrachtet.

Tja... Traurig ist es nur mit beleidigenden und verletzenden "Beiträge" ohne jede fachliche Inhalt.

Barf

[thegoodguy]

Ich glaube es wäre noch besser, die Konfigurationsoption zu eliminieren, und anstett unterschideliche make-targets einzuführen, z.B. image-1x und image-2x. Ferner sollte mann vielleicht die konfigurationsoptionen --with-targetset=[standard, flash] und --with-imagetype=[mixed,jffs2only] zu, z.B.,--with-target=[yadd,mixed-flash, jffs2onl-flash] mergen?

Ich waere eher dafuer, das mixed-flash und jffs2only-flash auch als target zu droppen und eher ein durch ein "make .jffsonly" und "make .mixed-flash" am Ende des Compilierprozesses zu ersetzen.
Die Hauptunterschiede beim compilieren sind ja ob Debugoptions usw. rein sollen oder nicht. Anschliessend (also abhaengig vom flash-typ) sind es ja nur "wenige" Files die gepatched werden muessen und evtl. neu compiliert.
Aber da ich mich nicht mit der Materie genauer beschaeftigt habe, sollte das jemand machen, der dies auch nuetzt und sich somit auskennt.

mklibs: nur spezialversion auf Homers site remote-admin.info geht,

Hmm - ich dachte eigentlich, dass http://cvs.tuxbox.org/cgi-bin/viewcvs.c ... /mklibs.py funktioniert

[Barf]

Ich waere eher dafuer, das mixed-flash und jffs2only-flash auch als target zu droppen und eher ein durch ein "make .jffsonly" und "make .mixed-flash" am Ende des Compilierprozesses zu ersetzen.

Gerne. Die Komponente die unterschiedlich sind, sind u-boot und der Kernel. Ausserden ein paar Kleinigkeiten beim Filesystem wie rcS. Eine andere Sache mann ändern soll, ist das ein flash-image-build nicht in das tftp-directory pinkeln soll, dabei ein eventuell vorhandene yadd-kerneln und yadd-u-boote überschreiben.

Hmm - ich dachte eigentlich, dass http://cvs.tuxbox-cvs.sourceforge.net/c ... /mklibs.py funktioniert

Hmm, hmm. Falls das stimmt sollte make dies benutzen, statt, wie jetzt, configure sucht im Pfad und setzt MKLIBS. Besonders wichtig weil massenweise nichtkompatible Versionen existieren (scheint es mir).

[alsuffndruff]

.

Zitat:

Hmm - ich dachte eigentlich, dass http://cvs.tuxbox-cvs.sourceforge.net/c ... /mklibs.py funktioniert


Hmm, hmm. Falls das stimmt sollte make dies benutzen, statt, wie jetzt, configure sucht im Pfad und setzt MKLIBS. Besonders wichtig weil massenweise nichtkompatible Versionen existieren (scheint es mir)

Zuimdets mein compilierproblem lies sich durch Verwendung dieser Version lösen

[Homar]

was hat dein Compilerproblem mit mklibs zu tuen ???

In der Version auf meiner Seite sind nur kleine Änderungen drin, die normalerweise rein gehören sollten.
Die vorhandenen Funktionen sind die selben, zusäztlich wird der root-Pfad richtig gesetzt.

[alsuffndruff]

wieso compilerproblem ?
Mein "compilierproblem" (gebe zu, ein blödes wort) war, dass die von mir verwendete Version von mklibs (die als Paket bei debian dabei war) Fehler wärend der Imageerstellung meldete. Im strengen sinne war das wohl auch keine compilierung, aber egal
Wie auch immer, als ich die Version im cvs verwendete (mklibs.py) hatte ich damit keine Probnleme mehr.

Das war eigentlich alles was ich damit sagen wollte.

Gruss

PS: Liebe Entwickler
wie es aussieht, werden die Aenderungen von barf schon verwendet (http://tuxbox-cvs.sourceforge.net/forum ... hp?t=26556), scheinbar auch mit Erfolg (was mir bisher nicht beschieden war). Seht ihr eine Chance, die Aenderungen in das cvs mit aufzunehmen? Oder sprechen Argumente dagegen?

[haderle]

@Barf

welche änderungen muss ich in deinem script noch vornehmen, damit es auch bei 1x boxen funktioniert?

oder geht das auch ohne probleme?

PS: ich meine wegen uboot und dbox2.h

gruß Haderle

[Barf]

@haderle

Gute Frage. Falls mann nach u-boot und protect sucht bekommt mann ganz schnell den Eindruck dass viele wissen "wie" aber kaum jemand warum.

Ein "wie" findest du hier. Ich habe keine Ahnung falls es stimmt, und kann auch nicht testen...

Es wäre relativ leicht, die Änderungen in der "Imagekit"-Umgebung zu integrieren (ich kannte früher das Problem nicht), so dass automatisch das richtigen u-boot kompiliert wurde.

Keep hacking,

Barf

[haderle]

@barf

kannst du mir bitte behilflich sein, wie ich das als abfrage in dein Imagekit integriere?

original von hrvill

In the file ...../tuxbox-cvs/boot/u-boot/include/configs/dbox.h there is a line

Code: Alles auswählen

"protect off 10040000 107fffff; "

The Sagem-Box can't boot with protect off. Just delete the line and put "rw" as bootarg

Code: Alles auswählen

"fsload; setenv bootargs root=/dev/mtdblock/2 rw console=$(console); "

remake u-boot and mkflfs

Herbert

schonmal danke für deine hilfe... ich habe es schon versucht komme aber nicht wirklich weiter

achso... muss diese änderung auch bei allen anderen 1x Boxen angewandt werden oder nur bei einer Sagem???

[haderle]

hat denn vielleicht jemand anderes eine idee wie ich das einbauen kann?

gruß haderle