Box reboot beim 'fsload'

Beitrag von **Brain-Store** » Samstag 6. Mai 2006, 04:00

Hallo !
Habe eben ein neues Newmake Image erstellt - klappte soweit alles wunderbar - Hab jeweils ein 'flash-neutrino-squashfs-1x und -2x' gebaut.

(Hab eine Sagem 1x und eine Sagem 2x - das Problem tritt bei beiden auf !)

Das Problem ist, das die Box rebootet sobald vmlinux geladen werden soll..

Hier mal das Log:

---------------------------------------
debug: DDF: Calibrating delay loop... debug: DDF: 66.76 BogoMIPS
debug: LCD init error -1
debug: WATCHDOG RESET
debug: BMon V1.0 mID 03
debug: feID 00 enxID 03
debug: fpID 52 dsID xx-xx.xx.xx.xx.xx.xx-xx
debug: HWrev 41 FPrev 0.23
debug: B/Ex/Fl(MB) 32/00/08
WATCHDOG reset enabled
dbox2:root> debug:
BOOTP/TFTP bootstrap loader (v0.3)
debug:
debug: Transmitting BOOTP request via broadcast
debug: Given up BOOTP/TFTP boot
boot net failed

Flash-FS bootstrap loader (v1.5)

Found Flash-FS superblock version 3.1
Found file /root/platform/sagem-dbox2/kernel/os in Flash-FS
debug: Got Block #0040

will verify ELF image, start= 0x800000, size= 154948
verify sig: 262
Branching to 0x40000

U-Boot 1.1.4 (Tuxbox) (May 5 2006 - 12:39:08 )

CPU: PPC823ZTnnB2 at 66 MHz: 2 kB I-Cache 1 kB D-Cache
Board: DBOX2, Sagem, BMon V1.0
Watchdog enabled
I2C: ready
DRAM: 32 MB
FLASH: 8 MB
Scanning JFFS2 FS: .

.
find_inode failed for name=boot.conf
load: Failed to find inode
FB: ready
LCD: ready
In: serial
Out: serial
Err: serial
Net: SCC ETHERNET
find_inode failed for name=logo-lcd
load: Failed to find inode
ready - can't find logo in flash
find_inode failed for name=logo-fb
load: Failed to find inode
can't find logo in flash

Options:
1: Console on null
2: Console on ttyS0
3: Console on framebuffer
Select option (1-3), other keys to stop autoboot: 0
=> fsload <-[habs hier mal von Hand versucht ...]
### FS (squashfs) loading 'vmlinuz' to 0x100000

[ hier erfolgt nach ca 2 Sekunden der RESET]

debug: DDF: Calibrating delay loop... debug: DDF: 66.76 BogoMIPS
debug: LCD init error -1
debug: WATCHDOG RESET
debug: BMon V1.0 mID 03
debug: feID 00 enxID 03

---------------------------------------------------

Seltsamerweise bootet ein 'flash-neutrino-jffs2-1x' ohne zicken !! Aber warum? Liegt das am Squashfs ? Beim CRAMFS ist es aber genau das selbe ...

Beitrag von **Barf** » Sonntag 7. Mai 2006, 11:43

Ich bin nicht ganz sicher, wurde aber schätzen dass das squashfs irgendwie nicht in ordnung ist. Dass boot.conf nicht gefunden wird, ist ein Hinweis. Sicherstelle dass es ein boot.conf drin gibt. Ich wurde auch die logos drinpacken, nicht weil sie erfordelich sind, sondern als check für u-boot und das squashfs. Welches Programm benutzt du für squashfserstellung?

Beitrag von **Barf** » Dienstag 9. Mai 2006, 19:19

Es ist das gleiche Problem als hier. Inzwischen muss ich zugeben, dass meine Antwort oben etwas daneben ist, Problem ist nur, dass wir die Antwort nicht kennen!

Beitrag von **dietmarw** » Dienstag 9. Mai 2006, 20:55

könnte ein mod diese treads zusammenführen?

Beitrag von **dietmarw** » Dienstag 9. Mai 2006, 20:57

@brain

welche hardware genau?

Beitrag von **Barf** » Mittwoch 10. Mai 2006, 21:50

Jetzt weiss ich mehr. Das Problem mit cramfs ist gelöst, siehe den anderen Thread. Das Problem mit squashfs-Images hat sich leider als desto schwieriger erwiesen.

Das Problem besteht dadrin, dass in squashfs-Images fsload (was den Kernel, als File, ins RAM laden soll) bei einige (nicht alle!) squashfs-images nicht funktioniert, sondern ein Abstürtz bringt ("Schleife"). Ich habe SQUASHFS_TRACE eingeschaltet, und Folgendes bekommen:

.

Code: Alles auswählen

Options:
  1: Console on null
  2: Console on ttyS0
  3: Console on framebuffer
Select option (1-3), other keys to stop autoboot:  0 
### FS (squashfs) loading 'vmlinuz' to 0x100000
SQUASHFS: fragments: 61
SQUASHFS: fragment_table_start: 0x505b0c
SQUASHFS: inode_table_start: 0x503152
SQUASHFS: directory_table_start: 0x504448
SQUASHFS: reading 1 fragment indexes from 0x505b0c
SQUASHFS: read_bytes @ 0x505b0c, size 4, buffer 0x1fab9f0
SQUASHFS: reading fragment table block @ 0x505958
SQUASHFS: read_bytes @ 0x505958, size 2, buffer 0x1fab998
SQUASHFS: compressed block @ 0x505958, compressed size 434
SQUASHFS: read_bytes @ 0x50595a, size 434, buffer 0x1f9b990
SQUASHFS: compressed block @ 0x505958, uncompressed size 488
SQUASHFS: root_inode @ 50442d:a
SQUASHFS: read_bytes @ 0x50442d, size 2, buffer 0x1faba08
SQUASHFS: uncompressed block @ 0x50442d, size 25
SQUASHFS: read_bytes @ 0x50442f, size 25, buffer 0x1fb4420
SQUASHFS: initial_offset 0x4bc, table_start 0x504448
SQUASHFS: read_bytes @ 0x505634, size 2, buffer 0x1fab8a8
SQUASHFS: compressed block @ 0x505634, compressed size 802
SQUASHFS: read_bytes @ 0x505636, size 802, buffer 0x1f9b8a0
SQUASHFS: compressed block @ 0x505634, uncompressed size 1318
SQUASHFS: dir_count: 10 file_size: 106 bytes: 4
SQUASHFS: dir_count: 4 file_size: 106 bytes: 76
SQUASHFS: entry found: vmlinuz
SQUASHFS: inode @ 503bc9:1fc6
SQUASHFS: read_bytes @ 0x503bc9, size 2, buffer 0x1faba08
SQUASHFS: compressed block @ 0x503bc9, compressed size 2146
SQUASHFS: read_bytes @ 0x503bcb, size 2146, buffer 0x1f9ba00
SQUASHFS: compressed block @ 0x503bc9, uncompressed size 8192
SQUASHFS: regular file, size 657715, blocks 11, start_block 0x462487
SQUASHFS: reading block 0
SQUASHFS: uncompressed block @ 0x462487, size 65536
SQUASHFS: read_bytes @ 0x462487, size 65536, buffer 0x100000
SQUASHFS: reading block 1
SQUASHFS: uncompressed block @ 0x472487, size 65536
SQUASHFS: read_bytes @ 0x472487, size 65536, buffer 0x110000
SQUASHFS: reading block 2
SQUASHFS: uncompressed block @ 0x482487, size 65536
SQUASHFS: read_bytes @ 0x482487, size 65536, buffer 0x120000
SQUASHFS: reading block 3
SQUASHFS: uncompressed block @ 0x492487, size 65536
SQUASHFS: read_bytes @ 0x492487, size 65536, buffer 0x130000
SQUASHFS: reading block 4
SQUASHFS: uncompressed block @ 0x4a2487, size 65536
SQUASHFS: read_bytes @ 0x4a2487, size 65536, buffer 0x140000
SQUASHFS: reading block 5
SQUASHFS: uncompressed block @ 0x4b2487, size 65536
SQUASHFS: read_bytes @ 0x4b2487, size 65536, buffer 0x150000
SQUASHFS: reading block 6
SQUASHFS: uncompressed block @ 0x4c2487, size 65536
SQUASHFS: read_bytes @ 0x4c2487, size 65536, buffer 0x160000
SQUASHFS: reading block 7
SQUASHFS: uncompressed block @ 0x4d2487, size 65536
SQUASHFS: read_bytes @ 0x4d2487, size 65536, buffer 0x170000
SQUASHFS: reading block 8
SQUASHFS: compressed block @ 0x4e2487, compressed size 16777216
SQUASHFS: read_bytes @ 0x4e2487, size 16777216, buffer 0x1f9ba00

debug: DDF: Calibrating delay loop... debug: DDF: 67.79 BogoMIPS

Die letzte Zeile bedeutet dass das System gecrasht hat, und neustartet. Mann beachtet die drittletzte Zeile, und die offensichtlich fehlerhaftige "compressed size".

Squashfs-unterstützung ist nicht ein offizieller Teil von u-boot, sonden ein Tuxbox extension, die sich in .../boot/u-boot-tuxbox/fs/squashfs/ befindet. Die Dateien dadrin scheint veraltet zu sein, von 2004, und squashfs hat sich inzwischen weiterentwickelt. Die Code funktioniert also nicht mehr.

Es scheint hardwareunabhängig zu sein, beide auf meinem Nokia 2x-Box als auch mein Sagen 1x.

Carjay, kannst du es anschauen?

Beitrag von **Carjay** » Donnerstag 11. Mai 2006, 22:07

Huch, jo, ein 16 MiByte großer Block ist wohl ein bißchen viel für den armen U-Boot-Heap.

Von 2004 stammt der 1.x Code (von mir), Marsellus hatte zwischenzeitlich die 2.xer-Unterstützung nachgerüstet.

Es gibt zwar jetzt auch 3.x, aber da wurde hauptsächlich die Größe des möglichen Dateisystems bzw. der Dateien aufgebohrt, aber ich glaube nicht ernsthaft, daß es für die dbox2 mal nötig sein wird, ein mehr als 4 GiByte fassendes Squashfs zu bauen.

Die Unterstützung im U-Boot ist auch sehr einfach gehalten, mehr als den Kernel finden und ins RAM laden ist auch absolut nicht nötig.

Irgendwas geht da beim Parsen der Blockliste schief, da sollte eigentlich keine 0 drin stehen, hmm.

Kann das aber reproduzieren, mal schauen. "Ist bestimmt nur eine Kleinigkeit"

Beitrag von **Carjay** » Freitag 12. Mai 2006, 01:34

Ok, Problem erkannt und aus Zeitmangel erstmal Workaround eingecheckt.

Die Blockliste ist unvollständig weil der Block, in dem sie liegt, länger als die maximalen 8192 Byte ist. Momentan wird in dem Fall einfach noch der folgende Block mitgenommen.

Ich muß bei Gelegenheit nochmal einen Blick auf den VFS-Code werfen, um rauszubekommen wie man das "ordentlich" handhabt.

Beitrag von **Brain-Store** » Mittwoch 17. Mai 2006, 09:53

Ja ... jetzt habe ich wohl den Einsatz verpasst - da hat man mal 2 Wochen Urlaub und schon zieht die Welt an einem vorbei

Na wie auch immer - ich denke mal die Frage nach meiner Hardware hat sich erübrigt - aber falls es was bringt - die Ausgabe im ersten Beitrag stammt von meiner alten Kabel Box, die ich nur zum testen für neue Images nehme - ist eine Sagem 2xIntel - der Rest steht ja oben im Log - meine andere Box ist auch eine Sagem, aber nur 1xIntel(BMon 1.2).
Die Log Ausgabe ist absolut identisch (bis auf den Display Fehler

)
An den fehlenden Dateien (boot.conf, LOGOs) lag es natürlich auch nicht - bei meinen ersten Test Images waren die noch vorhanden...

Stimmt es eigentlich, das ich bei einer Sagem KabelBox nur den Sat-Tuner einer Sat Box einlöten muss um umzurüsten ? Finde das die Testbox stabiler läuft und würde daher gerne tauschen(brauche zuverlässiges Aufnahme System)

Und danke für die schnelle Hilfe hier im Forum !