[SPARK] Buildsystem-CS mit YAFFS2
-
- Einsteiger
- Beiträge: 217
- Registriert: Donnerstag 14. Juni 2012, 09:39
[SPARK] Buildsystem-CS mit YAFFS2
Ich habe mir mal die Freiheit genommen, vor ein paar Tagen die relevanten Repositories von Seife zu clonen und einige Änderungen und Ergänzungen einzubauen. Das meiste dürfte dem einen oder anderen vertraut erscheinen:
- Per Default wird ein YAFFS2-Image gebaut.
- Die 3D-Modi Side-by-Side/Top-Bottom/Tiled werden unterstützt
- Eine Handvoll Einstellmöglichkeiten für's OSD sind hinzugekommen
- Logos mit E2-Picon-Namen werden akzeptiert
- Infoviewer zeigt die korrekten Button-Bezeichnungen an
- Lautstärkeanhebung/-absenkung ist pro Audiokanal einstellbar
- GraphLCD (das Billig-LCD, das es bei Pearl gab) wird unterstützt
- HDMI-CEC ist ebenfalls integriert
- LED-Feedback beim Betätigen der Fernbedienung
- FreeSat und VIASat EPG werden unterstützt (auch MHWEPG, per Batchjob)
- AdZap (Werbezapper) ist mit drin
- OSD-Anzeige für PSI-Settings (Farbton, Kontrast, ...)
Plus diverse weitere Änderungen/Erweiterungen/Fehlerbehebungen/Kleinigkeiten, die nicht so offensichtlich sind (stm24_0210, anderes Input-Handling, yWeb, ...).
Das eine oder andere mag mainstream-geeignet sein. Einiges davon ist naturgemäß arg SPARK-spezifisch (z.B. das 3D-Handling) oder mangels anderer Testmöglichkeit eben nur auf SPARK getestet.
GIT-Links siehe "Personal Clones" bei Gitorious.
- Per Default wird ein YAFFS2-Image gebaut.
- Die 3D-Modi Side-by-Side/Top-Bottom/Tiled werden unterstützt
- Eine Handvoll Einstellmöglichkeiten für's OSD sind hinzugekommen
- Logos mit E2-Picon-Namen werden akzeptiert
- Infoviewer zeigt die korrekten Button-Bezeichnungen an
- Lautstärkeanhebung/-absenkung ist pro Audiokanal einstellbar
- GraphLCD (das Billig-LCD, das es bei Pearl gab) wird unterstützt
- HDMI-CEC ist ebenfalls integriert
- LED-Feedback beim Betätigen der Fernbedienung
- FreeSat und VIASat EPG werden unterstützt (auch MHWEPG, per Batchjob)
- AdZap (Werbezapper) ist mit drin
- OSD-Anzeige für PSI-Settings (Farbton, Kontrast, ...)
Plus diverse weitere Änderungen/Erweiterungen/Fehlerbehebungen/Kleinigkeiten, die nicht so offensichtlich sind (stm24_0210, anderes Input-Handling, yWeb, ...).
Das eine oder andere mag mainstream-geeignet sein. Einiges davon ist naturgemäß arg SPARK-spezifisch (z.B. das 3D-Handling) oder mangels anderer Testmöglichkeit eben nur auf SPARK getestet.
GIT-Links siehe "Personal Clones" bei Gitorious.
-
- Einsteiger
- Beiträge: 352
- Registriert: Freitag 20. August 2004, 23:33
Re: [SPARK] Buildsystem-CS mit YAFFS2
Hallo martii!
das gibt generell mal ein für deinen Einsatz!
Ich werde demnächst versuchen, mir daraus ein "Image" für Testzwecke zu bauen, auch wenn ich es nur auf USB testen werde (was bei pinkys evolux immer Patcherei bedeutet hat).
ist die alsa Geschichte für Spark kompat. Lautstärke auch drin?
btw: Im evolux - das ja auch aus seifes git gecloned wurde - hat das Menü-fading ja nie funktioniert; ist das in deinem jetzigen Clone auch so? Kann man das ev. fixen oder ist das ein Sideeffect der "Erweiterungen"?
nochmals vielen Dank!
P.S.: schon mal einen Richtwert für die Bootzeit (Knopfdruck bis erstes Bild)?
P.P.S.: es hat ja immer geheissen, dass BER-Anzeige bei den SH4 nicht möglich ist. Unlängst hatten wir hier ein Gewitter wo das Signal (fast) ganz weg war, da hat plötzlich die BER Anzeige doch Werte zwischen 100 und ca. 80000 angezeigt. Kann es sein, dass bloß das Format / die Skalierung nicht passt?
das gibt generell mal ein für deinen Einsatz!
Ich werde demnächst versuchen, mir daraus ein "Image" für Testzwecke zu bauen, auch wenn ich es nur auf USB testen werde (was bei pinkys evolux immer Patcherei bedeutet hat).
ist die alsa Geschichte für Spark kompat. Lautstärke auch drin?
btw: Im evolux - das ja auch aus seifes git gecloned wurde - hat das Menü-fading ja nie funktioniert; ist das in deinem jetzigen Clone auch so? Kann man das ev. fixen oder ist das ein Sideeffect der "Erweiterungen"?
nochmals vielen Dank!
P.S.: schon mal einen Richtwert für die Bootzeit (Knopfdruck bis erstes Bild)?
P.P.S.: es hat ja immer geheissen, dass BER-Anzeige bei den SH4 nicht möglich ist. Unlängst hatten wir hier ein Gewitter wo das Signal (fast) ganz weg war, da hat plötzlich die BER Anzeige doch Werte zwischen 100 und ca. 80000 angezeigt. Kann es sein, dass bloß das Format / die Skalierung nicht passt?
-
- Einsteiger
- Beiträge: 217
- Registriert: Donnerstag 14. Juni 2012, 09:39
Re: [SPARK] Buildsystem-CS mit YAFFS2
Hi,
Boot von USB sollte gehen. Dass der Boot bei YAFFS2 ohne Änderung der Bootargumente läuft, hat aber leider zur Konsequenz, dass der Kernel kein JFFS2 mehr bootet.schufti hat geschrieben:Ich werde demnächst versuchen, mir daraus ein "Image" für Testzwecke zu bauen, auch wenn ich es nur auf USB testen werde (was bei pinkys evolux immer Patcherei bedeutet hat).
Ja, ist ja "nur" der amixer-Aufruf. Aktuell fehlt, im Vergleich zu meine Anpassungen für Evolux, nur noch WLAN-Support (das ist wg. wpa_supplicant etwas aufwendig).ist die alsa Geschichte für Spark kompat. Lautstärke auch drin?
Echt? An dem Code habe auch bei Evo nichts bewusst geändert. Im aktuellen Clone tut's, eben getestet.btw: Im evolux - das ja auch aus seifes git gecloned wurde - hat das Menü-fading ja nie funktioniert; ist das in deinem jetzigen Clone auch so? Kann man das ev. fixen oder ist das ein Sideeffect der "Erweiterungen"?
39 Sekunden vom Deep Standby bis ARD HD. Kommt mir rein subjektiv zu lange vor, aber evtl. gibt es da ja noch Optimierungspotenzial. Der Kernel ist ziemlich flott da, die Module scheinen dann etwas zu dauern. Mal schauen.P.S.: schon mal einen Richtwert für die Bootzeit (Knopfdruck bis erstes Bild)?
War mir auch aufgefallen (aber ich hatte auch schon mal das Sat-Kabel gezogen, um zu sehen, ob sich da was tut). Die Werte werden vom Tuner gelesen, und die einzige Doku ich ich dazu gefunden habe, sind die Sourcen. Ohne Beschreibung der Register stochert man da im Dunkeln.P.P.S.: es hat ja immer geheissen, dass BER-Anzeige bei den SH4 nicht möglich ist. Unlängst hatten wir hier ein Gewitter wo das Signal (fast) ganz weg war, da hat plötzlich die BER Anzeige doch Werte zwischen 100 und ca. 80000 angezeigt. Kann es sein, dass bloß das Format / die Skalierung nicht passt?
-
- Einsteiger
- Beiträge: 101
- Registriert: Dienstag 6. März 2012, 13:24
Re: [SPARK] Buildsystem-CS mit YAFFS2
Jffs2 kann das auch gebaut werden? weil 4 sek Bootunterschied sind nicht wichtig
-
- Einsteiger
- Beiträge: 217
- Registriert: Donnerstag 14. Juni 2012, 09:39
Re: [SPARK] Buildsystem-CS mit YAFFS2
Dachte ich mir dann gestern auch. Ja, in make/environment.mk ROOTFS_TYPE auf "default" setzen, oder beim make ROOTFS_TYPE=default mit angeben. Getestet hab ich das aber nicht.Tann hat geschrieben:Jffs2 kann das auch gebaut werden? weil 4 sek Bootunterschied sind nicht wichtig
-
- Einsteiger
- Beiträge: 352
- Registriert: Freitag 20. August 2004, 23:33
Re: [SPARK] Buildsystem-CS mit YAFFS2
ich denke, den Hauptanteil an der flotten Bootzeit beim evo war dem Umstand geschuldet, dass viels im rcS asynchron gelaufen ist, was dann auch schon mal unschöne Nebeneffekte hatte...
ich denke, mit entsprechenden Kerneloptionen für yaffs2/jffs2/etc Build ist das kein Problem.
man könnte den Bootparam rootfs ja nicht einfach nur rauslöschen sondern nach Buildtyp setzen. Beim aktuellen Kernelzweig ja sogar sauber per Kernelkonfig... (oder ist das jetzt eh sauberer gelöst)
Bei mir braucht altes evo (Neutrino-HD+E2) mit yaffs2 im flash 26s vom Druck auf Power in deep standby bis erstes Bild in Neutrino-HD 26sek, allerdings mit synchronem mount von nfs (statt automount in Neutrino-HD, da waren es ein paar s weniger).
ich denke, mit entsprechenden Kerneloptionen für yaffs2/jffs2/etc Build ist das kein Problem.
man könnte den Bootparam rootfs ja nicht einfach nur rauslöschen sondern nach Buildtyp setzen. Beim aktuellen Kernelzweig ja sogar sauber per Kernelkonfig... (oder ist das jetzt eh sauberer gelöst)
Bei mir braucht altes evo (Neutrino-HD+E2) mit yaffs2 im flash 26s vom Druck auf Power in deep standby bis erstes Bild in Neutrino-HD 26sek, allerdings mit synchronem mount von nfs (statt automount in Neutrino-HD, da waren es ein paar s weniger).
-
- Einsteiger
- Beiträge: 362
- Registriert: Mittwoch 14. Dezember 2005, 03:25
Re: [SPARK] Buildsystem-CS mit YAFFS2
Der Unterschied in der Bootzeit zwischen Evolux (tdt basis) und Images aus dem seifes Repo liegt es auch noch in den Devices-Nodes und die das laden der Module:
- im seifes /dev ist tmpfs und die Nodes werden bei hoch fahren angelegt im gegensatz zu evolux die sind immer da ausser bei der ersten Boot.
- Depmod sucht erst mach den Modulen im gegensatz insmod lädet das Module wie es im Pfad gegeben ist und erstellt keine Module.conf
- im seifes /dev ist tmpfs und die Nodes werden bei hoch fahren angelegt im gegensatz zu evolux die sind immer da ausser bei der ersten Boot.
- Depmod sucht erst mach den Modulen im gegensatz insmod lädet das Module wie es im Pfad gegeben ist und erstellt keine Module.conf
-
- Einsteiger
- Beiträge: 352
- Registriert: Freitag 20. August 2004, 23:33
Re: [SPARK] Buildsystem-CS mit YAFFS2
gegen ein fixes /dev spricht ja bei einem embedded System wie einer STB ja nicht prinzipiell etwas.
(hab schon Systeme gebaut wo das /dev in tmpfs aus nem .tgz gefüllt wurde)
Und auch nicht wirklich gegen insmod, die mögliche und sinnvolle HW ist ja relativ übersichtlich, wenn man nicht jeden billigst WLAN Stick unterstützen will, aber das ist natürlich Geschmacksache (und unerheblich solange WLAN sowieso aussen vor ist). Wobei ich da ja dann schon die UMTS Lösung bevorzuge; damit wäre das Ding optimal fürs Camping
wobei die Unübersichtlichkeit des evo Startup ist wohl ungeschlagen, da ist das Standardsystem (wie bei seife build) ja mustergültig; wenn auch ev. nen Ticken langsamer...
P.S.: falls es noch so Arme gibt, die wie ich oft durch proxy arbeiten müssen:
wesentlich besser als graphlcd-base-touchcol über git clone in einer bestimmten Version zu holen, wäre es per wget gleich das passende Archiv zu holen: http://projects.vdr-developer.org/git/g ... 02b.tar.gz
P.P.S.: im Makefile von CEC ist ein endif auskommentiert, das aber gebraucht wird. k.A. ob das von upstream kommt...
(hab schon Systeme gebaut wo das /dev in tmpfs aus nem .tgz gefüllt wurde)
Und auch nicht wirklich gegen insmod, die mögliche und sinnvolle HW ist ja relativ übersichtlich, wenn man nicht jeden billigst WLAN Stick unterstützen will, aber das ist natürlich Geschmacksache (und unerheblich solange WLAN sowieso aussen vor ist). Wobei ich da ja dann schon die UMTS Lösung bevorzuge; damit wäre das Ding optimal fürs Camping
wobei die Unübersichtlichkeit des evo Startup ist wohl ungeschlagen, da ist das Standardsystem (wie bei seife build) ja mustergültig; wenn auch ev. nen Ticken langsamer...
P.S.: falls es noch so Arme gibt, die wie ich oft durch proxy arbeiten müssen:
wesentlich besser als graphlcd-base-touchcol über git clone in einer bestimmten Version zu holen, wäre es per wget gleich das passende Archiv zu holen: http://projects.vdr-developer.org/git/g ... 02b.tar.gz
P.P.S.: im Makefile von CEC ist ein endif auskommentiert, das aber gebraucht wird. k.A. ob das von upstream kommt...
-
- Einsteiger
- Beiträge: 362
- Registriert: Mittwoch 14. Dezember 2005, 03:25
Re: [SPARK] Buildsystem-CS mit YAFFS2
nein dagegen spricht ja nichts, sind nur schneller als das anderegegen ein fixes /dev spricht ja bei einem embedded System wie einer STB ja nicht prinzipiell etwas.
(hab schon Systeme gebaut wo das /dev in tmpfs aus nem .tgz gefüllt wurde)
Und auch nicht wirklich gegen insmod
-
- Einsteiger
- Beiträge: 217
- Registriert: Donnerstag 14. Juni 2012, 09:39
Re: [SPARK] Buildsystem-CS mit YAFFS2
Beides angepasst, danke!schufti hat geschrieben: wesentlich besser als graphlcd-base-touchcol über git clone in einer bestimmten Version zu holen, wäre es per wget gleich das passende Archiv zu holen: http://projects.vdr-developer.org/git/g ... 02b.tar.gz
P.P.S.: im Makefile von CEC ist ein endif auskommentiert, das aber gebraucht wird. k.A. ob das von upstream kommt...
-
- Einsteiger
- Beiträge: 217
- Registriert: Donnerstag 14. Juni 2012, 09:39
Re: [SPARK] Buildsystem-CS mit YAFFS2
Ich habe da mal ein bisschen experimentiert. Beim Boot ist nach grob 10 Sekunden der Kernel da, das Laden der Module dauert dann bis zu 20 Sekunden. Insmod statt modprobe hilft da leider auch nicht, das sind auch nur Sekundenbruchteile, die da potenziell gespart werden.mohousch hat geschrieben:nein dagegen spricht ja nichts, sind nur schneller als das anderegegen ein fixes /dev spricht ja bei einem embedded System wie einer STB ja nicht prinzipiell etwas.
(hab schon Systeme gebaut wo das /dev in tmpfs aus nem .tgz gefüllt wurde)
Und auch nicht wirklich gegen insmod
Ein vorgefertigtes /dev/ im Image wäre jedenfalls unschön. Man könnte das bestenfalls beim ersten Boot auf der Kiste selbst erzeugen. Beim Bauen ist das ungeschickt, da man dann als root auf dem Host die Devices erzeugen muss. Das passt so schon, wie Seife das handhabt.
Falls jemand eine funktionierende Idee zur Parallelisierung des Ladens der Kernel-Module hat, greife ich die freilich auch gerne auf.
-
- Developer
- Beiträge: 4189
- Registriert: Sonntag 2. November 2003, 12:36
Re: [SPARK] Buildsystem-CS mit YAFFS2
Das modulladen wird nicht schneller beim parallelisieren, weil der kernel immer nur ein Modul gleichzeitig einfügen kann.
Man müsste die Treiber fixen, dass sie schneller initialisieren bzw. asynchron im hintergrund (nach dem init_module() wieder beendet ist) die Hardware suchen und finden. Aber die bugs die man sich damit potenziell reinzieht will man eigentlich nicht haben. Einige Treiber machen das übrigens schon -- typischerweise welche die im mainline kernel sind, uinput z.B. IIRC -- deswegen muss man dann auch warten, bis das device da ist.
Und als ich das dynamische dev vs. statisches dev letztes mal benchmarked habe, hat es weniger als 1 Sekunde ausgemacht. Evtl. könnte man "richtiges" udev statt mdev nehmen, weil das eher weniger overhead hat, aber das ist halt auch wieder komplizierter und das dann für ein oder 2 Sekunden bootzeit? Das war's mir nicht wert.
Interessant ist das asynchrone laden der Firmware in die beiden ST40, wieviel macht das aus?
Man müsste die Treiber fixen, dass sie schneller initialisieren bzw. asynchron im hintergrund (nach dem init_module() wieder beendet ist) die Hardware suchen und finden. Aber die bugs die man sich damit potenziell reinzieht will man eigentlich nicht haben. Einige Treiber machen das übrigens schon -- typischerweise welche die im mainline kernel sind, uinput z.B. IIRC -- deswegen muss man dann auch warten, bis das device da ist.
Und als ich das dynamische dev vs. statisches dev letztes mal benchmarked habe, hat es weniger als 1 Sekunde ausgemacht. Evtl. könnte man "richtiges" udev statt mdev nehmen, weil das eher weniger overhead hat, aber das ist halt auch wieder komplizierter und das dann für ein oder 2 Sekunden bootzeit? Das war's mir nicht wert.
Interessant ist das asynchrone laden der Firmware in die beiden ST40, wieviel macht das aus?
-
- Einsteiger
- Beiträge: 217
- Registriert: Donnerstag 14. Juni 2012, 09:39
Re: [SPARK] Buildsystem-CS mit YAFFS2
Leider auch nur ca. 2 Sekunden, also kaum der Rede wert.seife hat geschrieben:Interessant ist das asynchrone laden der Firmware in die beiden ST40, wieviel macht das aus?
-
- Developer
- Beiträge: 4189
- Registriert: Sonntag 2. November 2003, 12:36
Re: [SPARK] Buildsystem-CS mit YAFFS2
Das hatte ich befürchtet. Das problem ist, dass das alles sachen sind, die zentrale infrastruktur im chip (firmware laden) oder kernel (module einfügen) benötigen und deswegen schlecht parallelisierbar sind. Man müsste wirklich die Treiber auf delays untersuchen und unnötige rausmachen. Aber ohne genaue Hardwaredoku ist das halt sehr aufwändig. Und auch mit ist es viel Arbeit. Die dort investierte Zeit werden wir mit schneller booten niemals einsparen
-
- Einsteiger
- Beiträge: 352
- Registriert: Freitag 20. August 2004, 23:33
Re: [SPARK] Buildsystem-CS mit YAFFS2
aber ev. kann man die video/audio fw parallel zu den Modulen laden, das sollte sich nicht ins Gehege kommen. Und wenn parallel dazu das netzwerk gestartet werden kann, ist auch wieder was gespart.
habe aber jetzt nicht geschaut, wie weit das ev. schon geschieht ...
habe aber jetzt nicht geschaut, wie weit das ev. schon geschieht ...
-
- Developer
- Beiträge: 4189
- Registriert: Sonntag 2. November 2003, 12:36
Re: [SPARK] Buildsystem-CS mit YAFFS2
Du kommst immer an einen Punkt, wo die haupt-cpu nichts anderes gleichzeitig machen kann, und das de-facto sowieso serialisiert ist. Ich vermute, sowas wie "firmware in den ST40 schieben" gehört in diese Abteilung. "Modul einfügen" genauso. Während "init_module()" läuft, läuft im Kernel nicht viel anderes. Zumindest nicht, wenn du nur eine CPU hast...
-
- Einsteiger
- Beiträge: 352
- Registriert: Freitag 20. August 2004, 23:33
Re: [SPARK] Buildsystem-CS mit YAFFS2
hmmm, ich hatte gehofft, dass die Warteschleifen in der Modulinitialisierung etwas "kooperativer" sind und dem fw-Loader etwas Luft lassen würden ... bei 20Sek für eine Handvoll Module ....
-
- Developer
- Beiträge: 4189
- Registriert: Sonntag 2. November 2003, 12:36
Re: [SPARK] Buildsystem-CS mit YAFFS2
init_module ist IIRC unter dem BKL, zumindest im relativ antiken 2.6.32er noch -> wärenddessen geht gar nichts.
Und wenn du dir die player2 etc. mal anschaust, dann wundert dich gar nichts mehr, schon gar nicht dass die lange laden...
Und wenn du dir die player2 etc. mal anschaust, dann wundert dich gar nichts mehr, schon gar nicht dass die lange laden...
-
- Einsteiger
- Beiträge: 352
- Registriert: Freitag 20. August 2004, 23:33
Re: [SPARK] Buildsystem-CS mit YAFFS2
habe gerade von nem jffs2 (+sumtool) user gelesen, dass dort von Netzschalter Ein bis Bild auch 39sec vergehen (38sec aus deep standby).
Waren die 39sek am Threadbeginn auf yaffs2 bezogen? Dann wäre es witzlos die Leute mit yaffs2 zu quälen...
P.S.: mit 40sec dauerts vom USB-Stick auch nicht viel länger ...
Waren die 39sek am Threadbeginn auf yaffs2 bezogen? Dann wäre es witzlos die Leute mit yaffs2 zu quälen...
P.S.: mit 40sec dauerts vom USB-Stick auch nicht viel länger ...
Zuletzt geändert von schufti am Dienstag 17. Juli 2012, 22:55, insgesamt 1-mal geändert.
-
- Einsteiger
- Beiträge: 352
- Registriert: Freitag 20. August 2004, 23:33
Re: [SPARK] Buildsystem-CS mit YAFFS2
kann jetzt nicht sagen obs ein generelles oder nur ein martii Problem ist, aber wenn ich auf einen Sender zappe, der nur DD Ton hat, gibts meist nur Stille....
Bei einem mit mehreren Tonspuren (wo nur zuletzt DD verwendet wurde) hilft Tonkanal wechseln DD-stereo-DD und Ton ist wieder da ...
habe DD on HDMI force und DD on SPDIF on
Bei einem mit mehreren Tonspuren (wo nur zuletzt DD verwendet wurde) hilft Tonkanal wechseln DD-stereo-DD und Ton ist wieder da ...
habe DD on HDMI force und DD on SPDIF on
-
- Interessierter
- Beiträge: 67
- Registriert: Dienstag 17. Juli 2012, 23:26
Re: [SPARK] Buildsystem-CS mit YAFFS2
Entspricht das dem Neutrino-HD2 aus dem EVO Triple Image?
Läüft das auf dem Edision Argus Pingulux?
Läüft das auf dem Edision Argus Pingulux?
-
- Einsteiger
- Beiträge: 352
- Registriert: Freitag 20. August 2004, 23:33
Re: [SPARK] Buildsystem-CS mit YAFFS2
nein, das entspricht (basiert auf seifes git + martiis Änderungen für spark) dem Neutrino-HD aus dem triple.
ja, sollte laufen.
@martii:
ich denke, in packages.mk sollte es mtd-utils statt mtd-tools heissen?
irgendwo zickt es noch, da keine jfffs2 Dinge im img landen...
hat es seine Richtigkeit damit, dass die dropbear und xfs Sachen unter /opt/pkg... landen?
ansonsten: super Arbeit!
ja, sollte laufen.
@martii:
ich denke, in packages.mk sollte es mtd-utils statt mtd-tools heissen?
irgendwo zickt es noch, da keine jfffs2 Dinge im img landen...
hat es seine Richtigkeit damit, dass die dropbear und xfs Sachen unter /opt/pkg... landen?
ansonsten: super Arbeit!
-
- Developer
- Beiträge: 4189
- Registriert: Sonntag 2. November 2003, 12:36
Re: [SPARK] Buildsystem-CS mit YAFFS2
Das /opt/pkg ist historisch so, weil es auch mal auf Boxen laufen sollte, die nicht soviel Flash haben (nur 32MB z.B.)
Deswegen habe ich damals die optionalen Pakete (oder besonders grosse...) nach /opt/pkg installiert, dorthin hätte man z.B. einen USB-Stick mounten können.
Ist mit heutigen Boxen eher nicht mehr notwendig.
Deswegen habe ich damals die optionalen Pakete (oder besonders grosse...) nach /opt/pkg installiert, dorthin hätte man z.B. einen USB-Stick mounten können.
Ist mit heutigen Boxen eher nicht mehr notwendig.
-
- Einsteiger
- Beiträge: 352
- Registriert: Freitag 20. August 2004, 23:33
Re: [SPARK] Buildsystem-CS mit YAFFS2
im Prinzip wird ja auch der Pfad darauf erweitert, aber für libs sehe ich mit leerer ldso.conf schwarz
und andere Pakete (alsa, e2fs-tools) landen ja auch an "üblicher" Stelle
und andere Pakete (alsa, e2fs-tools) landen ja auch an "üblicher" Stelle
-
- Developer
- Beiträge: 4189
- Registriert: Sonntag 2. November 2003, 12:36
Re: [SPARK] Buildsystem-CS mit YAFFS2
die ld.so.conf wird ja bei mir auch erweitert. Wenn nicht ist das ein bug im jeweiligen postinst skript.