Flashtargets in Makefile umgeschrieben

Beitrag von **Barf** » Mittwoch 20. Juli 2005, 22:34

Ich habe ein neues Versuch gemacht, das Imagebuilden im CDK aufzuräumen, Dazu habe ich die Flashtargets fast völlig umstrukturiert. Die "public" Targets heissen jetzt flash-$gui-$filesys-$chips, wobei $gui ist neutrino oder enigma, $filesys ist jffs2fs, cramfs oder squashfs, $chips ist 1x oder 2x. Ausserdem kann man "all" angeben statt $gui, $filesys oder $chips. Funktionell neu ist das automatische builden von jffs2fs-only images. Filenamen habe ich versucht, konsequent zu gestalten, siehe die Kommentare im Makefile(.am). Dokumentation (erste Version) hier.

Ich möche das ganze in CVS einchecken falls keine (hinreichend wichtige

) Protesten auftreten.

Ich bitte deswegen um Testen, insbesonderes vom Imagebastlern wie das YADI-Team. Zum Testen braucht mann die diff vom .../cdk/Makefile.am,
configure.ac, sowie die Files linux-drivers-mtd-maps-dbox2-flash-jffs2fs.c.diff
und linux-drivers-mtd-maps-dbox2-flash-squashfs.c.diff, die beide im .../cdk/Patches gehen, und u-boot.jffs2.dbox2.h in Directory ---/boot/u-boot-config. Sowie (eventuell) die oben genannte Dokumentationsfile in .../cdk/doc. Dazu ein Direktory .../cdk/defaultlogos mit inhalt logo-fb und logo-lcd.

(Hoffe war das alles).

Insgesamt ist es eine Menge mehr oder wenig große Änderungen. Es wird sicherlich alte Imagebau-skripte kaputtmachen, aber, von der andere Seite, sollte sie auch hoffentlich überflüssig machen. Bitte teile alle Probleme mit.

Noch eine freundliche Bitte: Bitte diese Thread nur zu Diskussion dieser Verbesserungen benutzen. Anfängenfragen irgendwo anderes.

Beitrag von **dietmarw** » Donnerstag 21. Juli 2005, 10:41

edit:
...patches nochmal an die richtige stelle kopiert..

nun läuft es erstmal an..

edit2:
ungetestete ergebnisse von "make flash-all-jffs2fs-all"
hier http://tuxbox.trale.de/

Beitrag von **Coronas** » Donnerstag 21. Juli 2005, 17:54

Hi,

Gute Idee, Barf! Bis jetzt nur ein Fehler, bei: make flash-enigma-squashfs-all bricht das compilen bei folgender Stelle ab:

Code: Alles auswählen

echo "version=0200`date +%Y%m%d%H%M`" > /home/tux/tuxbox-cvs.barf/root/cdkflash/root/.version
echo "comment=Created by `id -un`" >> /home/tux/tuxbox-cvs.barf/root/cdkflash/root/.version
/usr/bin/install -c /home/tux/tuxbox-cvs.barf/root/cdkroot/bin/busybox /home/tux/tuxbox-cvs.barf/root/cdkflash/root/bin
for i in `find /home/tux/tuxbox-cvs.barf/root/cdkroot/bin/ -lname "*busybox"` ;do cp -rc $i /home/tux/tuxbox-cvs.barf/root/cdkflash/root/bin/ ; done
cp: invalid option -- c
,,cp --help" gibt weitere Informationen.

für was steht denn das "c"? Im Original Makefile.am sah die Zeile so aus:

Code: Alles auswählen

	for i in `find $(targetprefix)/bin/ -lname "*busybox"` ; do cp -ap $$i $(flashprefix)/root/bin/ ; done

Das -p sollte in der Tat überflüssig sein, da in -a die entsprechende Option enthalten ist.

Code: Alles auswählen

coronas@asus ~]$ cp --help
Aufruf: cp [OPTION]... QUELLE ZIEL
 oder:  cp [OPTION]... QUELLE... VERZEICHNIS
 oder:  cp [OPTION]... --target-directory=VERZEICHNIS QUELLE...
Kopieren von QUELLE nach ZIEL, oder mehrere QUELLE(n) in VERZEICHNIS

Erforderliche Argumente für lange Optionen sind auch für kurze erforderlich.
  -a, --archive               genau wie -dpR

cu

Beitrag von **Barf** » Donnerstag 21. Juli 2005, 18:55

Danke für das Testen.

Ich habe ganz definitiv cp -rd gemeint wo es cp -rc steht. Mein cp hat ein -c option, und hat deswegen nicht gemeckert

Deswegen extra Danke.

Es ist meine Meinung, dass man in Makefiles cp ohne -p Option benutzen soll. Wir schaffen ja was neues, was deswegen creation-time JETZT haben soll, wir machen ja nichte ein Backup-Kopie von irgendetwas Altes (wobei mann die creation-time nicht umsetzen will). Deswegen habe ich grundsätzlich alle -p-Optionen zu cp entfernt. Ist jemand andere Meinung?

Noch eine Sache motiviert aus

edit2:
ungetestete ergebnisse von "make flash-all-jffs2fs-all"
hier http://tuxbox.trale.de/

Das checkImage-Program wird angestossen für jede erzeugte Image. Falls das Program (was ich selbst nicht ganz verstehe

) sagt dass die Image schlecht ist wird sie in *.bad umbenannt. Meine tests zeigt das flashen von cramfs und squashfs die als bad gekennzeichent auch zu "No system" führen. Dagegen schein ein jffs2fs-image zu laufen, auch wenn checkImage gemotzt hat!

Beitrag von **dietmarw** » Donnerstag 21. Juli 2005, 20:47

was viel lustiger is..

von den im zweiten test erzeugten jffs2 images ist statt 3 nur eins "angeblich" def.
sie beruhen aber def. auf dem SELBEN source
irgendwas ist da mit dem testen noch nicht wirklich sauber..?
(oder ist da beim "füllen" irgendwo ein zufallsprinzip drin? eigentlich ja nicht)

ungetestete ergebnisse von "make flash-all-all-all"
hier http://tuxbox.trale.de/

Dagegen schein ein jffs2fs-image zu laufen, auch wenn checkImage gemotzt hat!

das kann ich nur bestätigen..
teste meine zwar nicht ständig, aber mir ist noch kein nicht startendes untergekommen..
wenn, dann waren es cvs probleme..

Beitrag von **dietmarw** » Samstag 23. Juli 2005, 12:10

also der build prozess scheint ja zu laufen..

ob auch die images richtig laufen hab ich bisher nicht getestet..

Beitrag von **Coronas** » Samstag 23. Juli 2005, 14:06

Hi,

ich habe einige enigma-Images (squashfs und jffs2fs für 2x) gebaut, welche problemlos laufen.
cu

Beitrag von **Barf** » Sonntag 24. Juli 2005, 12:26

Danke Coronas und dietmarw für eure Feedback.

Ich habe die Dinge committed. (Werden deswegen von meiner Website entfernt.) Dazu die Verbessserungen von Coronas und dietmarw. Nur bei cramfs und squashfs (also nicht jffs2fs-images) wird der Imagen in .bad umbenannt. Grundsätzlich ist es eine Sache des Benutzers, die Ergebnisse von checkImage zu bewerten.

Mal sehen, falls jemand in die Luft geht ...

Beitrag von **JtG-Riker** » Sonntag 24. Juli 2005, 14:29

Also ich finde das Teileweise als mega Rückschritt, zumindestz das man nicht mehr nur einzelne Teile bauen kann, ich habe bis jetzt immer make rebuild-flash benutzt für meine Snapshots und eben make flash-neutrino-all & enigma-all mit einigen anpassungen fürs JTG-Image.

Jetzt wird da jedesmal u-boot gebaut und sonstwas, da ist auch noch ein Bug weil anscheind mkflfs nicht ausführ bar ist...

Hab den Kram erstma wieder zurückgebaut in meinem CVS bis ich Zeit hab alles anzupassen...

ALso rebuild-flash ist meiner Meinung nach einer der wichtigsten Flash-Punkte gewesen für updates...

Riker

Beitrag von **Barf** » Sonntag 24. Juli 2005, 16:39

Ich habe am 20. Juli die Änderungen zum Testen freigegeben. Ziel war, eventuelle Inkompatibilitäten mit z.B. Imagebauern auszuloten. In diese Zeit hat sich JtG-Riker nicht gemeldet. Es ist nicht wahrschenlich, dass eine längere Testperiode etwas daran geändert hätte.

Eine Makefile baut Produkte (Targets) von Prerequisites. Falls am mindestens ein Prerequisite neuer als ein Produkt ist, wird das Produkt neu gebaut, sonst nicht. Deswegen hat Targets wie rebuild-flash nicht in einem richtig entworfene Makefile nichts zu suchen, weil Make sowieso weiss (idealerweise) was rebuild-ed werden soll. Leider ist die Makefile(.am) des Tuxboxprojekts (insbesonderes bevor meine Änderungen) nicht wirklich Makefile-ish.

Ich habe versucht, die Targets so zu gestalten. Deswegen soll auch rebuild-flash nicht notwendig sein, sondern nur make flash-$gui-$fs-$chips. Dadurch werden alle notwendige (und idealerweise nur die) Komponente neugebaut. Falls mann die Makefile nicht vertraut, kann make flash-clean oder make-developerclean benutzt werden

Jetzt wird da jedesmal u-boot gebaut

es ist genau umgekehrt. Jetzt wird nicht u-boots gebaut, falls ein passende und aktuelle $filesys.flfs*x schon existieret.

und sonstwas, da ist auch noch ein Bug weil anscheind mkflfs nicht ausführ bar ist...

klingt mehr als schlechte Laune als ein Bugbericht. Ich kann kein Bug aus diese Beschreibung extrahieren.

Konstruktive Vorschläge, sowohl in technische Fragen als auch bzgl. "Changemanagement" sind willkommen.

Beitrag von **JtG-Riker** » Sonntag 24. Juli 2005, 17:04

Und wie kann man denn in den neuen flashrules nur z.b. den cramfs Bereich neu bauen als aktuellen Snapshot als update ? Das die Funktion nicht mehr geht find ich den Rückschritt, villeicht kannst du mich des besseren belehren.

Also wenn das nicht mehr geht find ich es nicht gut, ich hab auch die Tage keine Zeit gehabt den Kram zu testen, man hätte solch große änderungen event in einen eigenen Branch legen sollen.

Wie gesagt hab ich den Kram bei mir reverted, weil ich keine alternative zu make flash-neutrino-all und flash-enigma-all und rebuild-flash gefunden habe.

Beitrag von **AudioSlyer** » Sonntag 24. Juli 2005, 18:07

make rebuild-flash vermisse ich aber auch

habe es auch wieder downgegraded

Beitrag von **Barf** » Sonntag 24. Juli 2005, 18:14

JtG-Riker hat geschrieben:Und wie kann man denn in den neuen flashrules nur z.b. den cramfs Bereich neu bauen als aktuellen Snapshot als update ? Das die Funktion nicht mehr geht find ich den Rückschritt, villeicht kannst du mich des besseren belehren.

Das gesuchte Flashtarget heisst (z.B.) $(flashprefix)/root-neutrino.cramfs.

Also wenn das nicht mehr geht find ich es nicht gut, ich hab auch die Tage keine Zeit gehabt den Kram zu testen,

Auch "Möchte deine Änderungen testen. Bitte gib mir eine Woche" hätte es getan.

man hätte solch große änderungen event in einen eigenen Branch legen sollen.

Ist ja ein Vorschlag. Ich glaube kaum, dass es etwas bewirkt hätte. Erstmals ist "branced development" problematisch als solches, zweitens erlaube ich mich zu bezweifeln, dass dadurch sich mehr qualifizierte Testers gemeldet hätte.

Wie gesagt hab ich den Kram bei mir reverted,

deswegen benutzen wir ja CVS

weil ich keine alternative zu make flash-neutrino-all und flash-enigma-all und rebuild-flash gefunden habe.

Die alternative heissen flash-neutrino-all-all und flash-enigma-all-all. Falls es Bugs gibt, kann deine Hilfe diese zu finden und auszubügeln wertvoll sein.

Beitrag von **Barf** » Sonntag 24. Juli 2005, 19:06

AudioSlyer hat geschrieben:make rebuild-flash vermisse ich aber auch

falls dein/ein Skript "make rebuild-flash" aufruft wirst du es natürlich "vermissen". Du wirst aber die Funktionalität aber nicht vermissen (siehe frühere Beiträge).

Erlich, genau WEIL die Makefiles der Vergangenheit so schlecht war, hat sich alle diese Imagebastel-skripte eintwickelt.

Beitrag von **mogway** » Montag 25. Juli 2005, 00:20

Barf hat geschrieben:
Also wenn das nicht mehr geht find ich es nicht gut, ich hab auch die Tage keine Zeit gehabt den Kram zu testen,
Auch "Möchte deine Änderungen testen. Bitte gib mir eine Woche" hätte es getan.

Also ich glaube nicht das man verlangen kann, dass sich alle Imagebauer solch weittragenden Änderungen innerhalb einer Woche ansehen. Also ich hatte bis dato keine Zeit dazu. Man hat ja auch nebenbei noch Familie und einen Beruf.

Barf hat geschrieben:
man hätte solch große änderungen event in einen eigenen Branch legen sollen.
Ist ja ein Vorschlag. Ich glaube kaum, dass es etwas bewirkt hätte. Erstmals ist "branced development" problematisch als solches, zweitens erlaube ich mich zu bezweifeln, dass dadurch sich mehr qualifizierte Testers gemeldet hätte.

Also ich finde die Methode schon recht heftig. Nur weil du meinst das so mehr Leute testen, wird grad mal der komplette Build Prozess umgestrickt. Mit dem Ergebniss das bei allen erst mal nichts geht. Ein eigener Branch ist hier wohl mehr als angebracht.

Barf hat geschrieben:
Wie gesagt hab ich den Kram bei mir reverted,
deswegen benutzen wir ja CVS

Ich würde vorschlagen, Du revertest das im CVS und checkst es als Barfs Branch neu ein. Somit haben alle, die möchten, Gelegenheit das ausführlich zu testen und ggf noch Änderungen vorzunehmen. So wie es jetzt ist kann es IMHO nicht bleiben.

Gruß
mogway

Beitrag von **JtG-Riker** » Montag 25. Juli 2005, 00:33

mogway hat geschrieben:
Ich würde vorschlagen, Du revertest das im CVS und checkst es als Barfs Branch neu ein. Somit haben alle, die möchten, Gelegenheit das ausführlich zu testen und ggf noch Änderungen vorzunehmen. So wie es jetzt ist kann es IMHO nicht bleiben.

Gruß
mogway

Full ack, finde auch erstma in nen eigenen branch, das sollte doch kein Problem sein, alexH hat sich ja neulich erst die Mühe gemacht und die ganzen rules umgebaut, allerdings soweit abwärtskompatibel.

Riker

Beitrag von **mb405** » Montag 25. Juli 2005, 10:08

@JtG-Riker & mogway
THX, daß ihr das mal gesagt habt. Das es von Leuten kommt, die sich in der materie besser auskennen als ich. Ich benutze ein script, welches ich jetzt super angepasst habe, und wenn die änderungen drin sind, dann klappt da nichts mehr

Beitrag von **dietmarw** » Montag 25. Juli 2005, 10:16

ich für meinen teil finde die neuen flash-rules sehr gut..

(ob man nun die alten flash-rules einfach so schnell entfernen mußte steht auf nem anderen blatt)

Beitrag von **Coronas** » Montag 25. Juli 2005, 10:33

Mal abgesehen vom timing - Ich finde, dass das neue Makefile eine wesentlich bessere Basis ist als das alte. Auf jeden Fall klappt jetzt schon wesentlich mehr: man gibt einen Befehl ein, und hinten kommt ein Image raus. Ohne zusätzliche Skripte (die allerdings von alleine berücksichtigt werden, wenn vorhanden).
Ist das nicht immer gewollt worden?

Beitrag von **Innuendo** » Montag 25. Juli 2005, 10:40

Tach Ihrs,

Ich habe ein neues Versuch gemacht, das Imagebuilden im CDK aufzuräumen

Modified: . Makefile.am configure.ac
Log:
Changes reverted

ich fand den ansatz prima, auch wenn ich riker & co zustimme, daß nach 4 tagen einen "versuch" einchecken nicht wirklich ein testen ermöglicht.

schade fände ich es, wenn nun barf's versuch ein bissl im keim erstickt wird.

Innu

Beitrag von **JtG-Riker** » Montag 25. Juli 2005, 11:03

Am Ansatz hab ich auch nix auszusetzen, finde es aber nicht gut das alle rules komplett umgebaut/benannt werden, wenigstens die Funktionen der einzelnen Packete sollten bleiben, das ist seit Jahren so und hat doch auch immer funktioniert, alexH hat sich doch Anfang des Jahres erst die Arbeit gemacht und das alles erweitert so das man doch ein ganzes Image bauen kann damit, das könnte man ja noch um die fehlenden Sachen erweitern.

Zumindest sollten die alten :
make flash-neutrino/enigma/lcars-all
make rebuild-flash
usw bleiben.

Riker

Beitrag von **Papst** » Montag 25. Juli 2005, 15:02

Wieso nicht einfach beides. Das Makefile kann doch um die neuen Funktionen erweitert werden ohne das die Alten unbedingt raus müssen.
Ich persönlich finde die neuen rules sehr gut und habe gestern meine Scripts darauf angepasst. Heute morgen... alles wieder reverted...grrrr.

Beitrag von **Papst** » Montag 25. Juli 2005, 18:01

Hab grad noch nen kleinen Fehler in der u-boot.jffs2.dbox2.h gefunden.

#defineCONFIG_BOOTCOMMAND \
"protect off 10040000 107fffff; " \
"fsload; setenv bootargs root=/dev/mtdblock2 rw console=$(console); " \
"bootm"

Das protect off muss bei 10020000 anfangen, da sonst die FLFS Partition nicht mehr aus Neutrino heraus oder per Telnet geflasht werden kann.

Außerdem hab ich mit der uboot aus dem cvs immer eine Bad CRC Meldung.

U-Boot 1.1.2 (Tuxbox) (Jul 25 2005 - 17:48:19)

CPU: PPC823ZTnnB2 at 67.100 MHz: 2 kB I-Cache 1 kB D-Cache
Board: DBOX2, Nokia, BMon V1.2
Watchdog enabled
I2C: ready
DRAM: 32 MB
FLASH: 8 MB
*** Warning - bad CRC, using default environment

FB: ready
LCD: ready
In: serial
Out: serial
Err: serial
Net: SCC ETHERNET
Scanning JFFS2 FS: ....... .

Weiß jemand warum? Das Image läuft ganz normal.

Beitrag von **dietmarw** » Dienstag 26. Juli 2005, 19:26

@yadi+jtg+audioslyer

is da denn nun außer dem "make rebuild-flash" noch irgendetwas gravierendes was euch stört??

oder ist da jetzt nur ein wenig starrsinn wegen dem "schnellschuss" im spiel?

die meisten anderen meinungen waren eigentlich eher positiv..
und für den *allejubeljahremaleinimageersteller* ist das ganze doch ne super sache.

Beitrag von **JtG-Riker** » Dienstag 26. Juli 2005, 21:47

dietmarw hat geschrieben:@yadi+jtg+audioslyer

is da denn nun außer dem "make rebuild-flash" noch irgendetwas gravierendes was euch stört??

oder ist da jetzt nur ein wenig starrsinn wegen dem "schnellschuss" im spiel?

die meisten anderen meinungen waren eigentlich eher positiv..
und für den *allejubeljahremaleinimageersteller* ist das ganze doch ne super sache.

Leider hat sich Barf ja noch nicht zu Wort gemeldet, hoffe nicht das er sauer ist jetzt ?

Also mogway und ich hatten schonmal die Idee das er den kram einfach "unter" die alten rules einchecken ins makefile, da ja alles umgeschrieben wurde könnte man dann beides nehmen, obs geht müsste man nochmal gucken.

Ich möchte auf jedenfall weiter die alten rules nutzen, da es mit den neuen nicht möglich ist einen schnellen snapshot zu machen wie bis jetzt und auch nicht möglich ist "nur mal schnell" einzelne packete zu updaten usw, für komplett-Images sind die neuen rules sicher besser, aber fürs teilupdaten einfach nicht zu gebrauchen. Das gleiche ist bei Yadi, das komplette Script wird aus den Angeln gehoben und funktioniert nicht mehr.

Weiterhin sind die "make flash-part " Dinge seit jahren so im CVS - wieso man die komplett über den Haufen werfen muss verstehe ich immer noch nicht, man muss bedenken das sicherlich 1000sende User dranhängen.

Ich habs fürs Jtg Image einen "make-flash-jtg" hinzugefügt was meine
ganzen JTG-spezifischen Dinge erledigt, so das ich sonst kein riesen Skript mehr habe um einen Snapshot oder ein Image zu machen.

Ich wär auf jedenfall dafür sie in einen eigenenen Branch einzuchecken, dafür ist sowas ja da, dann kann man sich ma in ruhe damit befassen.

Hoffe Barf meldet sich mal zu Wort.