Flashtargets in Makefile umgeschrieben

[wolgade]

@ Barf: Du bist ja schneller als die Feuerwehr. Wenn Du soweit bist, teste ich noch einmal.

[Houdini]

"*** Warning - bad CRC, using default environment" kannte ich bis jetzt noch nicht.

Das Environment von uboot enthält üblicherweise die Konfiguration.
Diese ist je nach Vorgaben in einem Flashsektor oder in einem Seeprom oder embedded im uboot selber oder gibt es gar nicht.
Diese Konfig wird beim Starten ins RAM kopiert bzw besteht aus den Defaultwerten aus dem Code
Das Environment wird mit CRC überwacht, dieser check wird beim Starten ausgeführt und schlägt fehl,
weil es (imho) bei der Dbox keine veränderbare Konfig vom uboot und somit nichts zu CRCen gibt.

Kann sein dass da jetzt beim neuen Uboot 'ne warning kommt.
Houdini

[wolgade]

Danke für deine Erklärung. Wieder was gelernt.

Das interessante ist aber, daß die Fehlermeldung nur beim jffs2-Imge kommt. Beide Images sind in einem Rutsch gebaut worden, so daß beide wohl auch die gleiche U-Boot Version verwenden.

[Barf]

Zu dem nicht bootende cramfs-images: ich habe endlich es gefunden: seit 10. Januar ist die Kernelversion 2.4.32 in CVS. Die zugehörige Konfigurationsdatei cdk/Patches/linux-2.4.32-dbox2.config-flash definiert nicht der Konfigurationsparameter CONFIG_CRAMFS. Dadurch wird der Kernel nicht in lage sein, ein cramfs-filesystem zu mounten. Dieser Fehler betrifft auch dietmarw-images, und, sofern ich verstehe, auch HEAD-images. Ich habe sicherheitshalber ein newmake-Version eingecheckt mit CONFIG_CRAMFS=y.

"*** Warning - bad CRC, using default environment"

Sofern ich verstehe ist die "environment" einfach boot.conf. Ist natürlich ein Fehler, scheint nicht wirklich etwas (für mich am mindestens) auszumachen. Mann sollte es trotzdem beheben.

Die Frage ist ob man die Tags für nicht benötigte Files entfernt.
Z.B gehört nach deiner aktuellen Liste rules-make nicht zu newmake - hat aber einen tag .
Wenn nur die notwendigen Files getaggt sind würde das checkout besser klappen
(s.o. mein Beispiel) und Unstimmigkeiten leichter auffallen.

Ich stimme jedes Wort zu. Ich habe die überflüssige Tags entfernt. (CVS ist nicht immer so transparent...)

Ferner habe ich die newmake.files aktualisiert.

[wolgade]

seit 10. Januar ist die Kernelversion 2.4.32 in CVS. Die zugehörige Konfigurationsdatei cdk/Patches/linux-2.4.32-dbox2.config-flash definiert nicht der Konfigurationsparameter CONFIG_CRAMFS. Dadurch wird der Kernel nicht in lage sein, ein cramfs-filesystem zu mounten.

Na, da wird sich die Jtg-Truppe aber freuen. Verwendet die nicht cramfs? Vielleicht stellen die ja jetzt auf "newmake" um.

[Bimmel]

Na, da wird sich die Jtg-Truppe aber freuen. Verwendet die nicht cramfs? Vielleicht stellen die ja jetzt auf "newmake" um.

Nein die verwenden SquashFs und man richtet sich auf die Truppe nich anders , wie Barf.

[wolgade]

Nein die verwenden SquashFs

Dann war nicht auf dem neuesten Stand.

und man richtet sich auf die Truppe nich anders , wie Barf.

Hä?

[wolgade]

@Barf: Sieht jetzt gut aus. Das cramfs-Image2x hat angeblich bad magics. Ich habe es trotzdem geflasht und es funktioniert. Squashfs- (diesmal ohne bad magics) und jffs2-Images gehen auch. Bootlogs habe ich jeweils gemacht und durchgesehen. Da steht aber nichts interessantes drin.

Prima Sache.

[Barf]

Ich habe ein kleines Artikelchen über Customization von newmake-Targets geschrieben; war ich euch eine längere Zeit schuldig. Kommit irgendwo rein. Hier:

CUSTOMIZATION

The built images and yadds can be customized without changing the
Makefiles. For this, many of the major targets calls a customization
script, if present and executable. The name of the customization script is taken as
the non-directory part of the rule, with "-local.sh" appended. The script is
supposed to reside in the cdk directory, and is given two
arguments: For image targets these are $(flashprefix) and $(buildprefix)
(expanded); for yadd-targets these are $(targetprefix) and
$(buildprefix) (expanded).

Example:

In an image, it is desired to:

1. Use own ucodes,
2. Use own boot logos,
3. Use own /etc/hosts
4. Use own neutrino.conf, bouquets.xml, services.xml
5. Include the lirc component, together with own lirc configuration files.

For this: 1. and 2. are better with the --with-ucodesdir and
--with-logosdir options to configure. 3. and 5. are extensions that
should be to $(flashprefix)/root, while 4., being a Neutrino-fix,
should be to $(flashprefix)/root-neutrino-jffs2,
$(flashprefix)/root-neutrino-cramfs, and/or
$(flashprefix)/root-neutrino-squashfs. To achieve 3. and 5. we write
the script root-local.sh, say:

Code: Alles auswählen

#!/bin/sh

flashprefix=$1
buildprefix=$2
newroot=$flashprefix/root
myfiles=/home/somewhere/dbox/myfiles

cp -f  $myfiles/etc/hosts			$newroot/etc
make $flashprefix/root/sbin/lircd
cp -fr $myfiles/var/tuxbox/config/lirc          $newroot/var/tuxbox/config

The script for 4., say root-neutrino-jffs2-local.sh, is entirely similar:

Code: Alles auswählen

#!/bin/sh

flashprefix=$1
buildprefix=$2
newroot=$flashprefix/root-neutrino-jffs2
myfiles=/home/somewhere/dbox/myfiles

cp $myfiles/var/tuxbox/config/neutrino.conf	 $newroot/var/tuxbox/config
cp $myfiles/var/tuxbox/config/zapit/bouquets.xml $newroot/var/tuxbox/config/zapit
cp $myfiles/var/tuxbox/config/zapit/services.xml $newroot/var/tuxbox/config/zapit

NOTE: These scripts are intended to serve as examples, and can probably not
be used without modification.

[dietmarw]

@barf

möglich wären also:

root-local.sh
root-cramfs-local.sh
root-enigma-cramfs-local.sh
root-enigma-cramfs-p-local.sh
root-enigma-jffs2-local.sh
root-enigma-jffs2-p-local.sh
root-enigma-squashfs-local.sh
root-enigma-squashfs-p-local.sh
root-jffs2-local.sh
root-neutrino-cramfs-local.sh
root-neutrino-cramfs-p-local.sh
root-neutrino-jffs2-local.sh
root-neutrino-jffs2-p-local.sh
root-neutrino-squashfs-local.sh
root-neutrino-squashfs-p-local.sh
root-squashfs-local.sh
var-enigma-local.sh
var-neutrino-local.sh

wobei für mich immer noch unklar ist wo der unterschied der -p teile ist??

[yjogol]

Hi zusammen,

ich hab bisher noch nicht den Unterschied zwischen den foldenden Verzeichnissen verstanden:
root
root-jffs2
root-neutrino-jffs2
root-neutrino-jffs2-p

Ich erstelle jffs2. klar.
ich habe eine root-neutrino-jffs2-local.sh welche die var-Files nach
root-neutrino-jffs2/var und root-neutrino-jffs2/etc kopiert. Klappt soweit auch.

Wann brauche ich die anderen Verzeichnisse? Oder werden die für Zwischenschritte verwendet? Und was macht root-neutrino-jffs2-p? Prepare ok, aber was ist damit gemeint?

Gruß
yjogol

[dietmarw]

hier ist barf ein wenig darauf eingegangen..

http://forum.tuxbox-cvs.sourceforge.net ... hp?t=40037

[yjogol]

jau, das hatte ich gelesen.
Aber vielleicht sitze ich ja auf meinem Hirn ...
Ich schau mir grad die Makefiles an ....

Hilfe immernoch erwünscht

[dietmarw]

...ich hab bisher noch nicht den Unterschied zwischen den foldenden Verzeichnissen verstanden:
root
root-jffs2
root-neutrino-jffs2
root-neutrino-jffs2-p

root wenn du in jedem root was ändern willst für neutrino, enigma, alle filesysteme
root-jffs2 wenn du in jedem jffs2 root was ändern willst, also neutrino und enigma
root-neutrino-jffs2 wenn du im neutrino jffs2 root was ändern willst
root-neutrino-jffs2-p prepare

macht schon sinn.. änderungen für neutrino sollen ja unter enigma nicht stattfinden usw..

[Barf]

Die enfache Antwort ist: das braucht mann nicht zu wissen um Images zu bauen. Die sind Zwischenschritte. Private Targets eben. Die High-level Targets sind z.B. flash-neutrino-jffs2-all.

Mehr ausführlich: $(flashprefix)/root ist der "Urvater". Hier kommt alles hin, das nicht von Filesystemtype und GUI abhängt. Die "Kinder" des Urfater heissen $(flashprefix)/root-[jffs2,cramfs,squashfs], Dafür wir erstmals $(flashprefix)/root rüberkopiert, ein filesystemabhängiger Kernel wird erzeugt, und die Kernelmodule installiert. Die Kindern davon heissen $(flashprefix)/root-[neutrino,enigma]-[jffs2,cramfs,squashfs]-p. Dazu wird $(flashprefix)/root-[jffs2,cramfs,squashfs] rüberkopiert, und neutrino oder enigma da installiert. Die "library reduction" (mklibs) findet auch hier statt. Danach wird $(flashprefix)/root-[neutrino,enigma]-[jffs2,cramfs,squashfs] aus $(flashprefix)/root-[neutrino,enigma]-[jffs2,cramfs,squashfs]-p erzeugt. Bei read-only roottilesysteme müssen dabei ein var-directory abgesplittet werden, einige Links von /etc/dingsbums nach /var/etc/dingsbums angelegt werden (dies macht in Wesentlich .../cdk/root/Makefile). Danach ist $(flashprefix)/root-[neutrino,enigma]-[jffs2,cramfs,squashfs] fertig zum flashimageerstellung.

Vorteile mit diesem Vorgehungweise: Systematisch, was in alle Images rein soll muss nur einmal in Makefile erwähnt werden. Dadurch am mindestens langfristig ist eine höhere SW-Qualität zu erwarten. Nachteil: größerer Plattenbedarf, muss manuell gelöscht werden.

PS. jetzt 500 Postings...

[yjogol]

@barf

Ok, das hatte ich erhofft / erwartet - und verstanden
Jetzt noch die Frage: Wann wird jeweils umkopiert?
root -> root-jffs2 -> ...
jedes mal bei make flash-neutrino-jffs2-all ?
oder wird da ab root-jffs kopiert?

Gruß
yjogol

[Barf]

Wann wird jeweils umkopiert?

Ich bin nicht sicher ich die Frage ganz verstehe, "sollte" in meine frühere Post stehen. Die Regel für z.B. $(flashprefix)/root-jffs2 ist in Wesentlichen

$(flashprefix)/root-jffs2: $(flashprefix)/root
rm -rf $(flashprefix)/root-jffs2
cp -rd $(flashprefix)/root $(flashprefix)/root-jffs2
# kernel bauen
# driver installieren

und Ähnliches bei die spätere root-verzeichnisse. Beantwortet dies deine Frage?

[yjogol]

Ja,
danke.

Gruß
yjogol

[yjogol]

Prima, alles scheint zu laufen.

Hier meine *local.sh

Code: Alles auswählen

#!/bin/sh
# root-neutrino-jffs2-local-p.sh

flashprefix=$1
buildprefix=$2
myfiles=$HOME/tuxbox/Private/files
cdkroot=$HOME/tuxbox/dbox2/cdkroot
echo "============================================================================================"
echo Hello, this is $0, flashprefix=$1 and buildprefix=$2   PREPARE
echo "============================================================================================"
newvar=$flashprefix/root-neutrino-jffs2-p
set -x

cp -r $myfiles/var/* $newvar/var
cp -r $myfiles/etc/* $newvar/etc
cp -r $myfiles/lib/* $newvar/lib

# additional tools
cp -r $cdkroot/bin/fbshot $newvar/bin
cp -r $cdkroot/sbin/fcp $newvar/sbin

# delete games
rm $newvar/lib/tuxbox/plugins/lemmings.*
rm $newvar/lib/tuxbox/plugins/master.*
rm $newvar/lib/tuxbox/plugins/mines.*
rm $newvar/lib/tuxbox/plugins/pacman.*
rm $newvar/lib/tuxbox/plugins/snake.*
rm $newvar/lib/tuxbox/plugins/soko.*
rm $newvar/lib/tuxbox/plugins/solitair.*
rm $newvar/lib/tuxbox/plugins/sol.*
rm $newvar/lib/tuxbox/plugins/tank.*
rm $newvar/lib/tuxbox/plugins/tetris.*
rm $newvar/lib/tuxbox/plugins/vierg.*
rm $newvar/lib/tuxbox/plugins/yahtzee.*

Code: Alles auswählen

#!/bin/sh
# root-neutrino-jffs2-local.sh

flashprefix=$1
buildprefix=$2
myfiles=$HOME/tuxbox/Private/files

echo "============================================================================================"
echo Hello, this is $0, flashprefix=$1 and buildprefix=$2
echo "============================================================================================"
newvar=$flashprefix/root-neutrino-jffs2
set -x

# delete old Webs
rm -r $newvar/share/tuxbox/neutrino/httpd-alt2
rm -r $newvar/share/tuxbox/neutrino/httpd

Kann man eigentlich auch alles in root-neutrino-jffs2-local-p.sh tun.
Oder gibt es einen Vorteil wirklich beide Skripte einzusetzen?


Gruß
yjogol

[Barf]

@yjogol: Super! Du hast es gerafft!!

Oder gibt es einen Vorteil wirklich beide Skripte einzusetzen?

sowohl root-* als auch root-*-p? Wohl kaum. Falls mann gleichzeitig Images mit unterschiedliche FS und/oder GUIs bastelt, kann es sicherlich sinnvoll sein, so viel wie möglich in root-local.sh zu verschieben. Sonst ist es sicherlich sinnvoll, ausschliesslich mit z.B. root-neutrino-jffs2-local.sh zu arbeiten.

[gmo18t]

Hi,

nachdem sich nun in den einzelnen Threads zu "newmake" immer
mehr Erläuterungen zu dessen Funktionsweise angesammelt haben
(vor allem zur Sache mit den scripts), hab ich meine build-
Umgebung auch mal angepasst - und tatsächlich, wenn man mal
durchblickt, geht das einfacher/besser als bisher ...

Eventuell mach ich noch ne Kleinigkeit falsch - jedenfalls werden auch
die *-cramfs"-Verzeichnisse erstellt, wenn ich als Target
//"flash-neutrino-squash-all" verwende !
"flash-neutrino-squashfs-all" verwende !

edit: Tippfehler - hatte natürlich squashfs gemeint und auch verwendet !

- GMo -

[dietmarw]

evtl. liegts am fehlenden ...fs? also ...-squashfs-all

..ach nee.. dann würde wohl ...keine regel für... kommen..

[Barf]

Eventuell mach ich noch ne Kleinigkeit falsch - jedenfalls werden auch
die *-cramfs"-Verzeichnisse erstellt, wenn ich als Target
"flash-neutrino-squashfs-all" verwende !

Die Makefile weiss nicht wie sie aus root-*-squashfs-p ein var-Verzeichniss macht; nur aus root-*-cramfs-p weisst sie wie eine var-Verzeichniss erzeugt werden. Deswegen wird zwangsmässig die root-*-cramfs-p erzeugt.

Dies ist kein Bug (die richtige Ergebniss wird ja erzeugt), sondern eine "ineffiziente Implementierung".

[Barf]

Ich habe eine neue Version eingecheckt. Die Makefile.am ist nicht mehr monolitisch, sondern inkludiert die unterschiedliche Komponenten, von Files in Unterverzeichniss make.

Dependencies sind überarbeitet, so jetzt wird "unnötige" Builds minimiert. Noch kann mann wahrscheinlich etwas verbessern.

Diverse kleinere Verbesserungen und Bugfixes.

Es gibt auch ein Target TAGS, das eine Datei mit diesem Namen in cdk-Verzeichniss erzeugt. Dies ist eine TAGS-Datei für Emacs. (Das Programm etags wird vorausgesetzt.) In Emacs kann mann dann mit dem Kommand "find-tag" (zu M-. gebunden) direkt zu dem File, wo das Target definiert ist.

Sicherheitshalber habe ich die alte Version getagged als "newmake-2006-01".

Danke an alle die Feedback geliefert hat, insbesonderes an dietmarw!

[racker]

Vorwort:
Die neuen Regeln sind um längen besser als die Alten und sollten default werden.
Respekt vor der Zeit und Mühe die du da reingesteckt hast!
Deswegen sollte das Folgende nicht negativ sonder als Anregung verstanden werden.

Eine der Intentionen ist ein "one-for-all" sprich Images und Yadds, darauf beziehen sich meine Tests.
Meiner Meinung nach sollte "cdkroot" und das dazugehörige "tftpboot" nicht gestrippt werden.
Falls man doch einmal den Debugger braucht muss man alles wieder neu bauen.
Stattdessen sollten bei aktivierten Flashtargets die Yadds ebenfalls in ein eigenes Verzeichnis
kopiert werden und dan gestrippt.
Ich habe mir mal eigene Targets erstellt, im wesentlichen abgeänderte Regeln von dir und noch nicht fertig:

Code: Alles auswählen

bare-os-bm: $(bootprefix)/u-boot-bm $(bootprefix)/kernel-yadd driver $(targetprefix)/etc/init.d/rcS $(targetprefix)/bin/busybox modutils $(targetprefix)/bin/tuxinfo

yadd-none-bm: bare-os-bm $(targetprefix)/share/tuxbox/cables.xml tuxbox_tools procps $(targetprefix)/sbin/in.ftpd $(targetprefix)/var/tuxbox/ucodes

yadd-all-bm: yadd-none-bm plugins neutrino enigma lcars apps

$(bootprefix)/u-boot-bm\
$(hostprefix)/bin/mkimage-bm: @DEPENDS_uboot@ $(bootdir)/u-boot-config/u-boot.yadd.dbox2.h
	ln -sf ./u-boot.yadd.dbox2.h $(bootdir)/u-boot-config/u-boot.config
	$(MAKE) @DIR_uboot@/u-boot.stripped
	$(INSTALL) -d $(bootprefix)
	$(INSTALL) -m644 @DIR_uboot@/u-boot.stripped $(bootprefix)/u-boot
	if [ -e $(logosdir)/logo-fb ] ; then \
		$(INSTALL) -m644 $(logosdir)/logo-fb $(bootprefix); \
	fi
	if [ -e $(logosdir)/logo-lcd ] ; then \
		$(INSTALL) -m644 $(logosdir)/logo-lcd $(bootprefix); \
	fi
	@CLEANUP_uboot@
	rm $(bootdir)/u-boot-config/u-boot.config
			
$(bootprefix)/kernel-yadd: linuxdir $(hostprefix)/bin/mkimage-bm
	cp Patches/linux-$(KERNELVERSION).config $(KERNEL_DIR)/.config
	m4 Patches/dbox2-flash.c.m4 > linux/drivers/mtd/maps/dbox2-flash.c
	$(MAKE) $(KERNEL_BUILD_FILENAME)
	bla ....
endif

Wie man sieht, muss ich noch für ein paar Freunde Bootmanager-Yadds bauen
Mittlerweile hast du ja etwas ähnliches committet, ist hier nur ein Beispiel.
Warum baust du zuerst u-boot und anschließend im Target kernel-cdk nocheinmal?
Die Logos bei Yadd werden nicht kopiert.

Zum Thema "Single Source". So schön wie es aus Programmsicht ist - ein diff *config.yadd *.config.flash sagt mir
schneller etwas und ist leichter zu pfegen als ein *.m4. Bisher hat jeder die Files geändert die er auch testen kann.
Wenn es dabei zu Inkonsitenzen kommt liegt es wohl eher daran, dass Yadd/Image- Ersteller es nur in eigene Scripts
einfügen und nicht ins CVS. ;-)

Unwichtiges: Eigentlich interessiert nur die Build-Time nicht die Maintenance-Time. Wann etwas zusammenkopiert wird
ist doch egal. ( cp -a vs. cp -rp ) .

Ein weiterer Vorschlag (allgemein), es sollten Tools wie mk*fs im CVS sein. So hat jeder immer die richtige Version.
mkcramfs ist z.B. schon im Kernelsource enthalten.

Ein Wunsch zum Schluss: Wenn die Integration von Kernel 2.6 ins Makefile abgeschlossen ist, könnte man das cdk auch
für ander Zielplattformen bauen lassen z.B. i586? Unabhängig vom Source (z.B. Neutrino anpassen)
Über die Gründe und das Für und Wider kann man ja in einem eigenen Thread diskutieren.

Fazit: Klasse Arbeit und fast anfängersicher

Gruß

PS: Barf du änderst sehr schnell vlt. stimmen einige meiner Aussagen schon nicht mehr.