Neutrino auf der IPBox

[rhabarber1848]

@anubis_neutrino:
Könntest Du bitte noch folgende Frage beantworten?
http://forum.tuxbox-cvs.sourceforge.net ... 53#p367453

[anubis_neutrino]

Sehe ich das richtig, dass $(flashprefix)/db nur ein leeres Verzeichnis ist, was in db.img landet?

ja, ich hab leider auch keine ahnung für was das ist, aber das war im dgstation-sdk auch leer ....

[seife]

da wird bestimmt bei der originalsoft das "/var" hingemountet.

[rhabarber1848]

da wird bestimmt bei der originalsoft das "/var" hingemountet.

Daneben gibt es noch das hier:

Code: Alles auswählen

$(flashprefix)/config.img:
         dd if=/dev/zero of=$@ bs=8K count=`$(IPBOX_FLASH_MAP) blocks config`

Wie gesagt, ich habe keine IPBox-Hardware hier und stelle
deshalb diese dummen Fragen

[Grabber66]

Wenn ich es noch richtig in Erinnerung hab, ist es quasi der var bereich.
Näheres gibt es hier:
http://www.denktenk.com/old/images_explained.htm

Wenn ich ein kernel_root flashe, dann wird bei neutrino der rootbereich neu geshrieben.
Bei _noboot das ganze image ausser dem bootbereich, und ich denke dann mal
bei _db der Var bereich, wobei ich das noch nicht getestet hatte.
_notboot & _kernel_root kann ich so definitv bestätigen.

[gugu]

Hier aus Relook:
df -h
Filesystem Size Used Available Use% Mounted on
/dev/mtdblock/2 3.9M 3.9M 0 100% /
/dev/mtdblock/1 1.9M 452.0k 1.4M 24% /var
cat /proc/mtd
dev: size erasesize name
mtd0: 00040000 00010000 "nor.config_welcome"
mtd1: 001e0000 00010000 "nor.db"
mtd2: 00460000 00010000 "nor.root"
mtd3: 00150000 00010000 "nor.kernel"
mtd4: 00030000 00010000 "nor.boot"
mtd5: 005b0000 00010000 "nor.kernel_root"
mtd6: 00790000 00010000 "nor.kernel_root_db"
mtd7: 007d0000 00010000 "nor.all_noboot"
mtd8: 00800000 00010000 "nor.all"
mtd9: 0189ffff 00001000 "highram"

[Grabber66]

Ich hab nochmal ne Andere Frage. Es wird ja im configure

Code: Alles auswählen

$BOXTYPE
$BOXMODEL

definiert.

im code ist ja dann immer von HAVE_IPBOX die Rede.
Kann ich auch ein HAVE_"$BOXMODEL" einbauen, um einige unterschiede der Boxen ausklammern zu können.

z.B.: IDE hat nur die 250+350 etc.

THX

[gugu]

Relook400 hat auch IDE und configure hat --enable-ide Option.

[Grabber66]

Ich glaube ich habe mich misverständlich ausgedrückt.
Ich wollte eigentlich nur wissen, ob man im Code auch "Boxmodel" definieren kann, damit ich beim compileren, direkt
sagen kann wenn es Boxmodel X ist, dann baue mir bitte das Untermenue - IDE (Diff für ein IDE Menue gab ja zb.) mit.
Quasi
HAVE_350 dann baue mir das IDE menue mit ein.

Ich hoffe jetzt ist es klarer geworden.

[rhabarber1848]

Kann ich auch ein HAVE_"$BOXMODEL" einbauen

Ich glaube nicht, dass das möglich ist.

HAVE_350 dann baue mir das IDE menue mit ein.

Es macht nicht viel Sinn, für die IPBox350 ein IDE-Menü einzubauen,
wenn das Image ohne IDE-Support gebaut wurde. Wenn Du möchtest,
kann ich im CVS dafür sorgen, dass innerhalb von Neutrino ein neues
define HAVE_IDE möglich ist - in Abhängigkeit von cdk/configure --enable-ide -,
dann kannst Du Dein Menü davon abhängig machen. Alleine auf den
Boxtyp zu vertrauen, macht IMHO keinen Sinn.

[dbt]

Das neue überarbeitete IDE_Menü (habe mich aber auf den Namen HDD-Setup festgelegt) ist fast testfertig. Da müsste man mal schauen wie das mit den andern Boxen geht. Welche Module/Treiber werden denn auf den anderen Boxen gebraucht? Da sind auch einige Buildoptionen notwendig. Ich habe momentan etwas Zeit, da mal etwas dran zu bleiben. Das passt aber mehr hier hin.
http://forum.tuxbox-cvs.sourceforge.net ... 51#p366051

[Grabber66]

Wenn es ein HDD_Setup im CVS geben wird, dann macht das schon sinn, es über enable-ide zu erzeugen.

Aber fakt ist:
Es ist also nicht möglich das $Boxmodel für so etwas zu nutzen, das habe ich richtig verstanden, oder?

[dbt]

Wenn es ein HDD_Setup im CVS geben wird, dann macht das schon sinn, es über enable-ide zu erzeugen.

Das sowieso und ich habe das auch so bei mir am laufen. Ausserdem habe ich noch abhängig von--enable-hddsetup bzw. --enable-mmcsetup für die jeweiligen Menüs geplant, um diese damit zu aktivieren, was auch Einfluß auf die Erstellung der rcS hat, weil mit dem HDD-Setup, so wie ich das momentan am Laufen habe, in der rcS keine fs-Module geladen werden müssen, sondern auf eine extra init_ide umgelenkt wird, die das übernimmt. Markerfiles gibts keine mehr. Wie das bei den anderen Boxen läuft, weiß ich nicht, und muss man noch klären. Das ist aber keineswegs in trockenen Tüchern. Das aber wenn es soweit ist. Diskussionen hierzu bitte hier:
http://forum.tuxbox-cvs.sourceforge.net ... 16#p367616

[rhabarber1848]

Hat noch jemand den Sourcecode zu convbmp?

[gugu]

http://rapidshare.de/files/47112915/con ... r.bz2.html

[rhabarber1848]

Zu convbmp:
Ich habe hier eine Version der Datei gefunden, die unter der GPL steht:
http://ecos.sourceware.org/cgi-bin/cvsw ... sroot=ecos

Hier die Lizenzinfo: http://ecos.sourceware.org/anoncvs.html

Könnte bitte jemand testen, ob die o.g. Datei, die in einigen Punkten
von gugus Version abweicht, für das IPBox-Image ausreicht?

[rhabarber1848]

Neuer CVS commit: http://article.gmane.org/gmane.comp.vid ... ox.scm/498

Neue make targets "flash-neutrino-squashfs" und
"flash-enigma-squashfs", analog zu Dreambox-Images.

make target "ipbox_flash_imgs" ist deaktiviert.

Die make targets bauen bereits Images, denen allerdings
/etc und /var/etc fehlen, sie sind deshalb nicht bootfähig.

Da das Copyright einiger hostapps noch nicht geklärt ist,
müssen folgende Dateien aus thor.tar.bz2 vor dem
Kompilieren nach $prefix/cdk/bin kopiert werden:

appendbin
convbmp
mkdnimg
mkwelcomeimg

Zusätzlich muss bootlogo.m1v nach $cvsdir/cdk/config
kopiert werden.

[rhabarber1848]

Falls USB-Images gewünscht sind: Welche Werte
sind bei den verschiedenen Boxmodellen für die
Variablen VENDOR_ID und PRODUCT_ID vorgesehen?
Oder sind die Werte für alle Boxmodelle gleich?

[rhabarber1848]

make thorimage <- baut uboot, kernel, apps
make thorflash <- baut das flashimage

Muss thorimage vor thorflash gebaut werden? Oder anders gefragt,
afaics ist thorimage keine Abhängigkeit des make targets thorflash,
obwohl thorimage vor thorflash abgearbeitet sein muss.

[anubis_neutrino]

Falls USB-Images gewünscht sind: Welche Werte sind bei den verschiedenen Boxmodellen für die
Variablen VENDOR_ID und PRODUCT_ID vorgesehen? Oder sind die Werte für alle Boxmodelle gleich?

für alle Boxen sollte passen:
VENDOR_ID=0x00444753 ( DGS)
PRODUCT_ID=0x6c6f6f6b (look)

Muss thorimage vor thorflash gebaut werden? Oder anders gefragt, afaics ist thorimage keine Abhängigkeit des make targets thorflash, obwohl thorimage vor thorflash abgearbeitet sein muss.

thorimage muss vor thorflash gebaut sein, sollte also eine Abhängigkeit mit rein ...

[Grabber66]

Da das Copyright einiger hostapps noch nicht geklärt ist,
müssen folgende Dateien aus thor.tar.bz2 vor dem
Kompilieren nach $prefix/cdk/bin kopiert werden:

appendbin
convbmp
mkdnimg
mkwelcomeimg

Ist logisch, doch was ist "$prefix/cdk/bin" ?

[rhabarber1848]

Ist logisch, doch was ist "$prefix/cdk/bin" ?

Das Verzeichnis, indem auch der Compiler, binutils, etc. liegen.
$prefix wird mit cdk/configure --prefix festgelegt.

[rhabarber1848]

thorimage muss vor thorflash gebaut sein, sollte also eine Abhängigkeit mit rein ...

Ich plane nicht, diese targets namentlich zu übernehmen, ich wollte
nur wissen, welche targets in Deinem Makefile aufgerufen werden.
Danke für die Bestätigung meiner Vermutung.

Andere Frage: Ich glaube, in thor.tar.bz2 fehlt cdk/root/etc/init.d/
Überhaupt blicke ich durch die Erstellung von /etc/ noch nicht so
ganz durch. Könntest Du mir bitte aus einem laufenden Image
den Inhalt folgender Verzeichnisse posten: /etc /var/etc

Wie wird /var_init im Image benutzt?

[rhabarber1848]

Wozu wird CONFIG_TUN auf der IPBox benötigt?

Folgende Kernel-Konfiguration habe ich aus den mittels

$(MAKE) -C linux-2.6.17 mutant200s_defconfig.
$(MAKE) -C linux-2.6.17 relook200_defconfig.
$(MAKE) -C linux-2.6.17 relook210_defconfig.

erzeugten .config-Dateien übernommen und ins m4-Format gebracht:

#
# SPI support
#
ifdef(`ip400',
`# CONFIG_SPI is not set
# CONFIG_SPI_MASTER is not set',
`CONFIG_SPI=y
# CONFIG_SPI_DEBUG is not set
CONFIG_SPI_MASTER=y')

#
# SPI Master Controller Drivers
#
ifdef(`ip200',
`CONFIG_SPI_BITBANG=m')
ifdef(`ip250',
`CONFIG_SPI_BITBANG=m')
ifdef(`ip350',
`# CONFIG_SPI_BITBANG is not set')

Sind diese Optionen wirklich hardware-abhängig und müssen daher
immer aktiviert sein oder werden sie nur für den MMC-Betrieb auf
den jeweiligen Boxen benötigt?

[seife]

Ich würde an den Kernel-Konfigurationen nicht zu viel ändern.
Wenn du die falsche Option änderst, dann gehen die Drecks-Binärtreiber nicht mehr (sie laden evtl. noch, aber funktionieren nicht richtig), insofern wäre ich da sehr vorsichtig.