CDK nach Image

Kreuzuebersetzer, Diskussion über Änderungen im Tuxbox-CDK und Tuxbox-CVS
Space_2063
Einsteiger
Einsteiger
Beiträge: 294
Registriert: Samstag 8. Dezember 2001, 00:00

CDK nach Image

Beitrag von Space_2063 »

Hi miteinander, nachdem ich mir ein CDK gebaut bzw. kompiliert habe (Stand 3.2.2002) und dieses auch super laeuft, habe ich heute den ganzen Tag verbracht, um ein Image zu bauen.

Versuch 1 ueber mkcramfs fuehrte zu keinem finalen Ergebnis, das cramfs Image hatte die richtige Groesse (kleiner 6.1MB) und auch das schreiben nach /dev/mtd/3 schien erfolgreich. Aber nach dem reset und reboot kam ich immer nur bis zum Startlogo.

Danach habe ich das ganze ueber field's Bootmanager probiert und die bewusste kernel-flash verwendet. Und wieder gescheitert. Laut dem Log sieht es so aus, also ob ein fp.o nicht initialisiert werden kann. Wenn ich mein kompiliertes kernel-cdk verwende, aber wohl.

Bleibt die Frage, braeuchte ich ein neueres kernel-flash (gibt es das irgendwo ?) und steckt noch woanders ein Denkfehler. Waere nett, wenn jemand helfen koennte.
## Booting Linux kernel at 00100000 ...
Image Name: dbox2
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 600241 Bytes = 586 kB = 0 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
Linux version 2.4.2 (root@noer-lab.noernet.de) (gcc version 3.0.1 20010702 (prerelease)) #89 Fri Aug 24 21:37:54 CEST 2001
Boot arguments: console=ttyS0 root=/dev/nfs rw nfsroot=192.168.0.1:C/dbox2/cdkroot/
On node 0 totalpages: 8192
zone(0): 8192 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: console=ttyS0 root=/dev/nfs rw nfsroot=192.168.0.1:C/dbox2/cdkroot/
time_init: decrementer frequency = 251250000/60
Warning: real time clock seems stuck!
Console: colour dummy device 80x25
Calibrating delay loop... 66.56 BogoMIPS
Memory: 30624k available (1088k kernel code, 424k data, 64k init, 0k highmem)
Dentry-cache hash table entries: 4096 (order: 3, 32768 bytes)
Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes)
Page-cache hash table entries: 8192 (order: 3, 32768 bytes)
Inode-cache hash table entries: 2048 (order: 2, 16384 bytes)
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Starting kswapd v1.8
i2c-core.o: i2c core module
CPM UART driver version 0.03
ttyS00 at 0x0280 is a SMC
pty: 256 Unix98 ptys configured
block: queued sectors max/low 20264kB/6754kB, 64 slots per queue
eth0: CPM ENET Version 0.2, 00:50:9c:40:97:1b
JFFS2 version 2.1. (C) 2001 Red Hat, Inc., designed by Axis Communications AB.
D-Box 2 flash driver (size->0x800000 mem->0x10000000)
D-Box 2 flash memory: Found 2 x16 devices at 0x0 in 32-bit mode
Creating 7 MTD partitions on "D-Box 2 flash memory":
0x00000000-0x00020000 : "BR bootloader"
0x00020000-0x000c0000 : "idxfs"
0x000c0000-0x001c0000 : "var"
0x001c0000-0x00760000 : "root"
0x00760000-0x00800000 : "flfs"
0x00020000-0x00800000 : "GesamteFlashOhneBL"
0x007e0000-0x00800000 : "flfs_128"
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 2048 bind 4096)
Sending BOOTP requests.... OK
IP-Config: Got BOOTP answer from 192.168.0.1, my address is 192.168.0.202
IP-Config: Guessing netmask 255.255.255.0
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
devfs: v0.102 (20000622) Richard Gooch (rgooch@atnf.csiro.au)
devfs: boot_options: 0x0
Looking up port of RPC 100003/2 on 192.168.0.1
Looking up port of RPC 100005/2 on 192.168.0.1
VFS: Mounted root (nfs filesystem).
Mounted devfs on /dev
Freeing unused kernel memory: 64k in
init started: BusyBox v0.60.1 (2002.02.09-17:52+0000) multi-call Setting hostname
Mounting anything
Starting inetd
Loading modules
Real Time Clock Driver v0.1
i2c-core.o: driver FOR_PROBE_ONLY registered.
i2c-core.o: driver unregistered: FOR_PROBE_ONLY
mID: 01
feID: dd
fpID: 5a
enxID: ffffffff
gtxID: 0b
hwREV: 05
fpREV: 81
DEMOD: VES1893
i2c-core.o: driver i2c saa7126 driver registered.
event: init ...
i2c-core.o: driver DBox2 Frontprocessor driver registered.
i2c-core.o: driver unregistered: DBox2 Frontprocessor driver
/lib/modules/2.4.2/misc/fp.o: init_module: Device or resource busy
Hint: insmod errors can be caused by incorrect module parameters, including invalid IO or IRQ parameters
/lib/modules/2.4.2/misc/fp.o: insmod /lib/modules/2.4.2/misc/fp.o failed
event: cleanup ...
/lib/modules/2.4.2/misc/fp.o: insmod dvb failed
event: init ...
i2c-core.o: driver DBox2 Frontprocessor driver registered.
i2c-core.o: driver unregistered: DBox2 Frontprocessor driver
/lib/modules/2.4.2/misc/fp.o: init_module: Device or resource busy
Hint: insmod errors can be caused by incorrect module parameters, including invalid IO or IRQ parameters
/lib/modules/2.4.2/misc/fp.o: insmod /lib/modules/2.4.2/misc/fp.o failed
event: cleanup ...
/lib/modules/2.4.2/misc/fp.o: insmod tuner failed
gtx-core.c: init_gtx: gtxID 0b
gtx-core.c: init_gtx: loaded AViA GTX core driver
Console: switching to colour frame buffer device 90x36
fb0: AViA eNX/GTX Framebuffer frame buffer device
event: init ...
i2c-core.o: driver DBox2 Frontprocessor driver registered.
i2c-core.o: driver unregistered: DBox2 Frontprocessor driver
/lib/modules/2.4.2/misc/fp.o: init_module: Device or resource busy
Hint: insmod errors can be caused by incorrect module parameters, including invalid IO or IRQ parameters
/lib/modules/2.4.2/misc/fp.o: insmod /lib/modules/2.4.2/misc/fp.o failed
event: cleanup ...
avia_vbi: version (Feb 9 2002-19:20:00)
avia_vbi: error - no demux found
/lib/modules/2.4.2/misc/gtx_vbi.o: init_module: Input/output error
Hint: insmod errors can be caused by incorrect module parameters, including invalid IO or IRQ parameters
/lib/modules/2.4.2/misc/gtx_vbi.o: insmod /lib/modules/2.4.2/misc/gtx_vbi.o failed
$Id: gtx_capture.c,v 1.3 2001/12/01 06:37:06 gillem Exp $
gtx_pig: init
gtx_pig: WIDTH=160, S=0, HEIGHT=144
lcd.o: LCD driver (KS0713) module
Starting loopback device
/dev/dbox/rc0: No such file or directory

Please press Enter to activate this console.


BusyBox v0.60.1 (2002.02.09-17:52+0000) Built-in shell (msh)
Belgarad
Einsteiger
Einsteiger
Beiträge: 182
Registriert: Donnerstag 1. November 2001, 00:00

Beitrag von Belgarad »

Na da bist Du weiter als ich :)

ich kaempfe im augenblick damit mit strip die module klein zu kriegen sowie alles unoetige rauszuwerfen.
Kannst du mal stichpunktartig schreiben wie du bisher vorgegangen bist? (Speziell wie die Strip benutzt hast und wie Du die ueberfluessigen Dateien rausgeworfen hast (ich hoffe nicht per hand :-( )

Ansonsten - existiert:
/lib/modules/2.4.2/misc/fp.o
in deinem Image?
Space_2063
Einsteiger
Einsteiger
Beiträge: 294
Registriert: Samstag 8. Dezember 2001, 00:00

Beitrag von Space_2063 »

Na wenigstens einer der Hundert Lesenden erbarmt sich, mal was zu schreiben.

Strip geht in einem Rutsch mit einem kleinen Befehlszeile im Linux.

find . -type f -perm -100 -exec powerpc-linux-strip \{} \;

(Suche ab aktuellem Verzeichnis rekursiv alle Files mit execute permission fuer den Owner und wende powerpc-linux-strip an)

Durch die permssion Eingrenzung verhindert man, dass die Module angefasst werden.

Und fuers Loeschen - tja da habe ich wirklich Hand angelegt und die Inhalte vom yadd 14.1.2002 als Referenz hergenommen. Hat aber auch ein paar Stunden gedauert. Habe es aber protokolliert. D.h. wenn ich mal ein paar Minuten Zeit habe, schreibe ich ein kleines Shellscript.

... und da ich zum Testen erstmal nur Neutrino nutze, hat mir ein Loeschen von ezap schon einiges gebracht. ;)

Bzgl. fp.o - ja existiert. Ansonsten wuerde ja das front processor Modul nicht geladen, wenn ich ueber die kompilierte kernel-cdk boote. Das macht mich ja so ratlos.
beathe
Neugieriger
Neugieriger
Beiträge: 12
Registriert: Freitag 8. Februar 2002, 13:14

Beitrag von beathe »

hi space,

wird denn überhaupt die richtige Box erkannt? Was hast Du für eine Box?

Für das Erstellen einer eigenen Yadd wäre so eine Art replace, wie unter NT, recht hilfreich. Vorschlag: Man kopiert eine yadd in ein neues Verzeichnis und überklatscht die dort existierenden Dateien mit der selbst kompilierten "yadd". Damit hätte man schon die meisten benötigten Dateien aktualisiert und müsste nur noch für ein paar einzelne Dateien Hand anlegen, vorausgesetzt, es hat sich nicht zuviel in der Verzeichnisstruktur geändert. Geht vermutlich schneller als weglöschen.
Space_2063
Einsteiger
Einsteiger
Beiträge: 294
Registriert: Samstag 8. Dezember 2001, 00:00

Beitrag von Space_2063 »

Ja, die Box wird richtig erkannt. Sprich die GTX Treiber geladen, da es eine Nokia 2xI Avia 600 ist. Wie gesagt, wenn ich nur das CDK in den RAM lade, funktioniert es ja.

Aber - ich denke ich weiss mittlerweile, woran es liegt. Es war bloss gestern nach zu spaet, um noch den finalen Test zu fahren. Werde ich heute tun. Bin aber zu 99% sicher, dass es nun funktionieren wird.
Homar
Senior Member
Beiträge: 1278
Registriert: Mittwoch 5. September 2001, 00:00

Beitrag von Homar »

Hi Folks,

@space:

sag mal, muss das nicht heissen:


find . -type f -perm -100 -exec ../cdk/bin/powerpc-tuxbox-linux-gnu-strip \{} \;


und das im

dbox2/cdkroot/

Verzeichniss ????




MFG
Hoamar
NoClue
Einsteiger
Einsteiger
Beiträge: 226
Registriert: Dienstag 30. Oktober 2001, 00:00

Beitrag von NoClue »

Nimm cdk/bin mit auf in den Pfad:

export PATH=<<Pfad zu cdk/bin>>:$PFAD

dann

cd cdkroot

und

find . -type f -perm -100 -exec powerpc-tuxbox-linux-gnu-strip \{} \;
Sagem mit 1*Intel Flash und Avia 600 :-)
Homar
Senior Member
Beiträge: 1278
Registriert: Mittwoch 5. September 2001, 00:00

Beitrag von Homar »

Hi folks,

@NoClue: danke für den Tip...

Wo muss ich den Export-Path eintragen ??

Mit Joe oder Vi oder womit und wohin ??

MFG
Homar
Space_2063
Einsteiger
Einsteiger
Beiträge: 294
Registriert: Samstag 8. Dezember 2001, 00:00

Beitrag von Space_2063 »

Wer ist Joe ? Kenne ich den ;)

Ich weiss nicht welche Umgebung du verwendest, gehe mal von Linux aus. Also entweder du exportierst den PATH in der aktuellen Shell, dann ist diese Definition nur fuer diese Sitzung aktiv.

Oder aber du du fuegst dies in die resource Dateien der jeweiligen Shell ein, die du verwendest. Sprich in die .bashrc oder .kshrc oder ... Da diese Resource Dateien immer geladen werden, sobald du eine Shell oeffnest, ist die Variable immer exportiert.

Womit du dies editierst, ist ziemlich egal, vi oder emacs oder was auch immer (aber emacs rulez :D )
Homar
Senior Member
Beiträge: 1278
Registriert: Mittwoch 5. September 2001, 00:00

Beitrag von Homar »

Hi folks,
it es spacy... thanks

MFG
Homar