U-Boot und Squash21 genereller Bug irgendwo...!?!?!

[T-Nec]

Es scheint einen generellen Bug im aktuellen Squashfs (seit 9 Monaten?) zu geben.
Aufgefallen ist mir das als ich versuchte ein Image zu backen mit den Boot-images im root statt im JFFS2... (mit Squash 1.x geht das!!!)
Die Bilder werden am Bildschirm und im Display angezeigt aber anschließend ist das root nicht mehr ansprechbar.
Egal on in der u-boot.config die Dateien per "0:boot/blah..." oder per "boot/blah.." angesprochen werden.

Nach diversen Versuchen den Fehler zu finden fand ich eine Möglichkeit ih n zu provozieren:
Das U-Boot beim Start per Konsole anhalten (egal ob 1.1.2 oder 1.1.4)
und 3 mal fsload eingeben.
Dann wird ja der kernel nach 0x100000 geladen.

Log:

Code: Alles auswählen

...
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/philips-dbox2/kernel/os in Flash-FS
debug: Got Block #0040

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


U-Boot 1.1.4 (Tuxbox) (Jan  8 2006 - 01:50:08)

CPU:   PPC823ZTnnB2 at 66 MHz: 2 kB I-Cache 1 kB D-Cache
Board: DBOX2, Philips, BMon V1.0
       Watchdog enabled
I2C:   ready
DRAM:  32 MB
FLASH:  8 MB
Scanning JFFS2 FS: .. done.
FB:    ready
LCD:   ready
In:    serial
Out:   serial
Err:   serial
Net:   SCC ETHERNET

Options:
  1: Console on null
  2: Console on ttyS0
  3: Console on framebuffer
Select option (1-3), other keys to stop autoboot:  0 
=> 
=> fsload
### FS (squashfs) loading 'vmlinuz' to 0x100000
### FS load complete: 641310 bytes loaded to 0x100000
=> fsload
### FS (squashfs) loading 'vmlinuz' to 0x100000
### FS load complete: 641310 bytes loaded to 0x100000
=> fsload
### FS (squashfs) loading 'vmlinuz' to 0x100000
Error: inflateInit() returned -4
SQUASHFS error: squashfs_readdir: read_block
### FS LOAD ERROR<0> for vmlinuz!
=>

Ich dachte erst ich haette was falsch gemacht... (klar)
Aber nachdem ich ein yadi-image getestet habe (200505261551_neutrino_yadi_squashfs_head_2x.img) und der selbe Fehler da auch provozierbar war muss es wohl an der Squashfs-Implementierung liegen

Ist das schon bekannt? Ich habe nicht diesbezüglich gefunden!

[Npq]

Fehler "-4" ist Z_MEM_ERROR, heißt also, daß die zlib keinen freien Speicher mehr anfordern kann.

Das macht sich wohl erst bemerkbar, wenn man mehrere Male hintereinander "fsload" eingibt, da dann die Speicherlecks immer größer werden.

Ist wirklich ein Bug, der bislang noch nicht gemeldet wurde.

Aber bist du sicher, daß das dein ursprüngliches Problem war, da es ja nicht beim ersten Mal passiert (und der Kernel wird ja fürs Booten nur einmal geladen)?

[T-Nec]

Ich habs mit Squashfs 1 und mit den alten sources von 2er geprüft, da gehts noch.
Da kann fsload so oft eingeben wie man will...
Und wenn die Boot-Images aus dem Root geladen werden müssen diese ja auch erst entpackt werden.Und das passiert bevor der Kernel geladen wird.
Passt also zum Z_MEM_ERROR ...

[T-Nec]

OK!
Das Update vom Source behebt den Fehler!
Das ging fix

Danke!

[Npq]

Stimmt, da hatte ich nicht dran gedacht.

Tja, da sage noch einer, "in einem Bootloader sind memleaks zweitrangig"