Tuxbox-Forum

Forum des Tuxbox-Projects
Aktuelle Zeit: Donnerstag 23. November 2017, 19:22

Alle Zeiten sind UTC + 1 Stunde




Ein neues Thema erstellen Auf das Thema antworten  [ 119 BeitrĂ€ge ]  Gehe zu Seite 1, 2, 3, 4, 5  NĂ€chste
Autor Nachricht
 Betreff des Beitrags: Ursache fĂŒr 'Kein System'
BeitragVerfasst: Montag 14. Februar 2005, 12:20 
Offline
Interessierter
Interessierter

Registriert: Montag 14. Februar 2005, 10:10
BeitrÀge: 74
Ich bin neu hier im Forum und möchte erst einmal allen ein freundliches 'Hallo' sagen :D

Ich beschĂ€ftige mich nun auch schon ein gewisse Zeit mit der dbox und mir ist aufgefallen, daß hin und wieder nach der Erstellung von images - das gilt sowohl fĂŒr die alten cramfs als auch fĂŒr die neuen squashfs images - die Box nicht mehr bootet.

Es kommt dann im LCD die Meldung 'Kein System' und im log der Hinweis 'superblock not ok: invalid argument'.

AnfĂ€nglich habe ich gedacht, na gut da ist beim flashen etwas schief gelaufen und habe weiter probiert bzw. am image etwas geĂ€ndert bis es irgendwann wieder ging. Das ist natĂŒrlich auf die Dauer etwas unbefriedigend und so habe ich mich mal daran gemacht, die Sache genauer zu analysieren. Nach vielen Versuchen habe ich jetzt eine Systematik entdeckt, die fĂŒr diesen Fehler verantwortlich ist:

Es ist offensichtlich so, das der BR bootloader nach dem Einschalten der box den flash komplett scanned. Wird dabei ein zusammenhĂ€ngender Block im flash endeckt, der grĂ¶ĂŸer als 5767168 bytes (entspricht 44 * 131072 bytes) ist, kommt es immer dann zu diesem Fehler wenn der Quotient aus realer PartitionsgrĂ¶ĂŸe / 131072 gerade vor dem Komma ist.

Anders ausgedrĂŒckt bedeutet das:

Der Fehler tritt nie auf, solange die root Partition real - ohne padding - kleiner als 44 * 128 KB ist. Oberhalb dieses Werts tritt der Fehler immer dann nicht auf, wenn die reale GrĂ¶ĂŸe der root Partition / 131072 eine ungerade Zahl vor dem Komma ergibt.

Danach gibt es zwei LösungsansĂ€tze fĂŒr dieses Problem:

Sollten 5767168 bytes fĂŒr das root nicht ausreichen teilt man das root auf zwei Partionen auf oder man stellt durch ein dummy file sicher, daß bei einer Partition der Ouotient vor dem Komma immer eine ungerade Zahl ergibt.

Im Zuge dieser Tests habe ich auch noch eine Ungereimtheit in den u-boot sourcen bei der Zuordnung/offset Ermittlung der verschiedenen flash Typen festgestellt:


Code:
--- flash.c.old   2005-02-04 09:31:48.000000000 +0100
+++ flash.c   2005-02-07 13:01:41.000000000 +0100
@@ -34,7 +34,6 @@
  */
 #ifndef CONFIG_DBOX2_FLASH_FAKE
 static ulong flash_get_size (vu_long *addr, flash_info_t *info);
-static void flash_get_offsets (ulong base, flash_info_t *info);
 static void flash_get_protect (flash_info_t *info);
 static int write_word (flash_info_t *info, ulong dest, ulong data);
 #endif /* CONFIG_DBOX2_FLASH_FAKE */
@@ -100,11 +99,10 @@
       flash_info[i].flash_id = FLASH_UNKNOWN;
 
    flash_info[0].portwidth = FLASH_CFI_32BIT;
-
    size = flash_get_size ((vu_long *) FLASH_BASE_PRELIM, &flash_info[0]);
 
    if (flash_info[0].flash_id == FLASH_UNKNOWN)
-   {
+   {
       flash_info[0].portwidth = FLASH_CFI_16BIT;
       size = flash_get_size ((vu_long *) FLASH_BASE_PRELIM, &flash_info[0]);
    }
@@ -115,8 +113,6 @@
       return 0;
    }
 
-   flash_get_offsets (FLASH_BASE_PRELIM, &flash_info[0]);
-
 #ifdef CFG_FLASH_PROTECTION
    flash_get_protect (&flash_info[0]);
 #endif
@@ -138,10 +134,13 @@
    volatile immap_t *immap = (immap_t *) CFG_IMMR;
    volatile memctl8xx_t *memctl = &immap->im_memctl;
    ulong value;
+   ulong base = (ulong)addr;
+   short i;
 
    flash_put (info, addr, 0x0555, 0x00AA00AA);
    flash_put (info, addr, 0x02AA, 0x00550055);
    flash_put (info, addr, 0x0555, 0x00900090);
+
    value = flash_get (info, addr, 0);
 
    if (info->portwidth == FLASH_CFI_16BIT)
@@ -176,31 +175,32 @@
    switch (value)
    {
       case AMD_ID_DL323B:
-         info->flash_id |= FLASH_AMDL323B;
+         info->flash_id += FLASH_AMDL323B;
          info->sector_count = 63 + 8;
          info->size = 0x00800000;
          break;
       case STM_ID_28W320CB:
-         info->flash_id |= FLASH_BTYPE;
-         info->flash_id |= FLASH_STM320CB;
+         info->flash_id += FLASH_STM320CB;
          info->sector_count = 63 + 8;
          info->size = 0x00800000;
          break;
       case INTEL_ID_28F320C3B:
-         info->flash_id |= FLASH_BTYPE;
+         info->flash_id += FLASH_INTEL320B;
+         info->sector_count = 63 + 8;
+         info->size = 0x00800000;
+         break;
       case INTEL_ID_28F320C3T:
-         info->flash_id |= FLASH_INTEL320T;
+         info->flash_id += FLASH_INTEL320T;
          info->sector_count = 63 + 8;
          info->size = 0x00800000;
          break;
       case INTEL_ID_28F640J3A:
-         info->flash_id |= FLASH_28F640J3A;
+         info->flash_id += FLASH_28F640J3A;
          info->sector_count = 64;
          info->size = 0x00800000;
          break;
       case INTEL_ID_28F640C3B:
-         info->flash_id |= FLASH_BTYPE;
-         info->flash_id |= FLASH_28F640C3B;
+         info->flash_id += FLASH_28F640C3B;
          info->sector_count = 127 + 8;
          info->size = 0x01000000;
          memctl->memc_or0 = memctl->memc_or0 & 0xff00ffff;   // reset mask in OR0 to 16MB
@@ -210,37 +210,27 @@
          return 0;
    }
 
-   flash_put (info, addr, 0, 0x00F000F0);
-   return info -> size;
-}
-
-static void flash_get_offsets (ulong base, flash_info_t *info)
-{
-   int i;
-
-   if (info->flash_id & FLASH_BTYPE)
-   {
-      /* set sector offsets for bottom boot block type */
-      if ((info->flash_id & FLASH_TYPEMASK) != FLASH_28F640J3A)
-      {
-         info->start[0] = base;
-         info->start[1] = base + 0x4000;
-         info->start[2] = base + 0x8000;
-         info->start[3] = base + 0xC000;
-         info->start[4] = base + 0x10000;
-         info->start[5] = base + 0x14000;
-         info->start[6] = base + 0x18000;
-         info->start[7] = base + 0x1C000;
-         for (i = 8; i < info->sector_count; i++)
-            info->start[i] = base + ((i - 7) * 0x20000);
-      }
-      else
-         for (i = 0; i < info->sector_count; i++)
-            info->start[i] = base + (i * 0x20000);
-   }
-   else
+   /* set up sector start address table */
+   switch (value)
    {
-      /* set sector offsets for top boot block type */
+   case AMD_ID_DL323B:
+   case STM_ID_28W320CB:
+   case INTEL_ID_28F320C3B:
+   case INTEL_ID_28F640C3B:
+      /* set sector offsets for bottom boot block type   */
+      info->start[0] = base;
+      info->start[1] = base + 0x4000;
+      info->start[2] = base + 0x8000;
+      info->start[3] = base + 0xC000;
+      info->start[4] = base + 0x10000;
+      info->start[5] = base + 0x14000;
+      info->start[6] = base + 0x18000;
+      info->start[7] = base + 0x1C000;
+      for (i = 8; i < info->sector_count; i++)
+         info->start[i] = base + ((i - 7) * 0x20000);
+      break;
+   case INTEL_ID_28F320C3T:
+      /* set sector offsets for top boot block type      */
       i = info->sector_count - 1;
       info->start[i--] = base + info->size - 0x4000;
       info->start[i--] = base + info->size - 0x8000;
@@ -251,7 +241,19 @@
       info->start[i--] = base + info->size - 0x1C000;
       for (; i >= 0; i--)
          info->start[i] = base + info->size - ((i - 6) * 0x20000);
+      break;
+   case INTEL_ID_28F640J3A:
+      for (i = 0; i < info->sector_count; i++)
+         info->start[i] = base + (i * 0x20000);
+      break;
+
+   default:
+      return 0;
+      break;
    }
+
+   flash_put (info, addr, 0, 0x00F000F0);
+   return info -> size;
 }
 
 #ifdef CFG_FLASH_PROTECTION
@@ -311,7 +313,7 @@
       default:
          printf ("Unknown Vendor Unknown Chip Type\n");
    }
-#else /* CONFIG_DBOX2_FLASH_FAKE */
+#else  /* CONFIG_DBOX2_FLASH_FAKE */
    switch (info->flash_id  & FLASH_VENDMASK)
    {
       case FLASH_MAN_AMD:
@@ -365,7 +367,7 @@
                 default:
          printf ("\n");
         }
-#endif /* CONFIG_DBOX2_FLASH_FAKE */
+#endif  /* CONFIG_DBOX2_FLASH_FAKE */
 
    printf ("\n  Size: %ld kB in %d Sectors\n",
       info->size >> 10, info->sector_count);


So, das soll es jetzt erst einmal gewesen sein. Bei Interesse fĂŒr das cvs, ich habe auch ein patch auf u-boot-1.1.2 und squashfs-2.1 generiert.

Viele GrĂŒĂŸe,
e46ti


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Montag 14. Februar 2005, 13:51 
Offline
Senior Member

Registriert: Donnerstag 24. April 2003, 11:12
BeitrÀge: 1339
Jo, thanks, JtGRiker war auch schon am u-boot dran, hatte allerdings noch Probs mit cramfs.

Daß mit dem 28F640J3A ist mir auch aufgefallen, hab das auch schon korrigiert, ist nur noch nicht im CVS gelandet.

Mit dem BMon weiß ich nur, daß der nach bestimmten Bytefolgen sucht, aber ich mach selber nichts mit Images, daher hat mich das nicht tiefer interessiert.

Daß da diese BeschrĂ€nkung bei der PartitionsgrĂ¶ĂŸe drin ist ist mir allerdings neu. Hast du das im BMon selber nachgeschaut oder ist das nur eine Vermutung?


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Montag 14. Februar 2005, 14:24 
Offline
Interessierter
Interessierter

Registriert: Montag 14. Februar 2005, 10:10
BeitrÀge: 74
Hallo Npq,

wie gesagt zunĂ€chst bin ich immer davon ausgegangen, daß da irgend etwas beim flashen schief gegangen ist. Es gibt ja auch die Theorie, daß u-boot am Ende helfen soll, oder die Vermutung fĂŒr einen bug im squashfs code.

Irgendwann kam mir dann die Idee, daß es irgendwie mit der absoluten GrĂ¶ĂŸe der Partition - nicht mit dem prozentualen FĂŒllstand!! - zu tun hat. Ein bug im mkflfs code scheidet wohl aus - bis dahin kommt die box nĂ€mlich gar nicht, wenn dieser Fehler auftritt-.

Mit dieser Idee im Hinterkopf habe ich dann gezielt Tests mit verschiedenen root Verzeichnis GrĂ¶ĂŸen durchgefĂŒhrt.

Die Analyse der so gewonnenen Daten ergab dann:

bis zu einer GrĂ¶ĂŸe 44 * 131072 --> kein Fehler

oberhalb dieses Wertes kommt bei:

z.B 44,01, 46,xx, 48,xx usw. * 131072 --> kein System

45,xx, 47,xx, 49,xx usw. * 131072 --> funktionieren tadelos

Wichtig ist dabei nur, daß sich die o.g. GrĂ¶ĂŸenangaben auf die absolute GrĂ¶ĂŸe des squashfs/cramfs images beziehen und nicht auf die, die das flashmanage.pl script entsprechend den Vorgaben durch AuffĂŒllen mit 0xFF Werten - padding - erstellt.

e46ti


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Montag 14. Februar 2005, 14:57 
Offline
Tuxbox-Meister
Tuxbox-Meister

Registriert: Montag 21. Oktober 2002, 09:04
BeitrÀge: 2452
Box: dbox2 NOKIA Avia500 2xI
2. Box: Golden Media 990 Spark Reloaded
3. Box: DREAMBOX
e46ti hat geschrieben:
[...]
1. Es gibt ja auch die Theorie, daß u-boot am Ende helfen soll
[...]


So ist es ja beim Yadi-Image, trotzdem tritt (allerdings seltener als zuvor) "kein System" auf.

_________________
Schon gelesen ???
ENIGMA-DOC


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Montag 14. Februar 2005, 15:00 
Offline
Developer

Registriert: Mittwoch 10. Dezember 2003, 07:59
BeitrÀge: 2183
Wohnort: Rhein-Main-Gebiet
Wo wir gerade beim u-boot flashfile sind.
Ich habe euer File fĂŒr ein ARM7 board benutzt und dabei festgestellt,
dass die Sektorenoffsets beim Flash mit top boot block nicht stimmen.
(ich weiss wird bei der dbox nicht benutzt)
Folgende version funktioniert bei mir.

/* set sector offsets for top boot block type */
i = info->sector_count - 1;
info->start[i--] = base + info->size - 0x4000;
...
info->start[i--] = base + info->size - 0x1C000;
for (; i >= 0; i--)
info->start[i] = base + info->size - ((64 - i) * 0x20000);

Houdini


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Montag 14. Februar 2005, 15:03 
Offline
Interessierter
Interessierter

Registriert: Montag 14. Februar 2005, 10:10
BeitrÀge: 74
Hallo essu,

den Eindruck hatte ich in der Tat zunĂ€chst auch, daß es dann seltener auftritt. Unter den von mir oben geschilderten Bedingungen kommt allerdings auch unter diesen Bedingungen --> kein System. Ich habe daraus geschlossen, daß die absolute Position der Partition im Flash, wenn ĂŒberhaupt nur eine unwesentliche Rolle spielt.

e46ti


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Montag 14. Februar 2005, 15:12 
Offline
Tuxbox-Meister
Tuxbox-Meister

Registriert: Montag 21. Oktober 2002, 09:04
BeitrÀge: 2452
Box: dbox2 NOKIA Avia500 2xI
2. Box: Golden Media 990 Spark Reloaded
3. Box: DREAMBOX
http://prdownloads.sourceforge.net/dbox ... g?download

Damals noch mtd3, also u-boot vorn.

Filesize: 5824512. Widerspricht das nicht deiner Theorie?

_________________
Schon gelesen ???
ENIGMA-DOC


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Montag 14. Februar 2005, 15:17 
Offline
Tuxbox-Meister
Tuxbox-Meister

Registriert: Montag 21. Oktober 2002, 09:04
BeitrÀge: 2452
Box: dbox2 NOKIA Avia500 2xI
2. Box: Golden Media 990 Spark Reloaded
3. Box: DREAMBOX
Noch ein Hinweis:
Ryker(nicht Jtg-Riker) beschreibt hier im Forum, dass er allein durch VerÀnderung der jffs2-Partition reproduzierbar *Kein System* erzeugen konnte....

_________________
Schon gelesen ???
ENIGMA-DOC


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Montag 14. Februar 2005, 15:48 
Offline
Interessierter
Interessierter

Registriert: Montag 14. Februar 2005, 10:10
BeitrÀge: 74
@essu,

ich habe alle meine Tests bisher mit u-boot hinten durchgefĂŒhrt. Bei dem image das Du angibst lag u-boot vorn. Nehmen wir jetzt einmal an, daß doch die absolute Position im Flash einen Einfluß hat - wĂŒrde bei u-boot vorn vielleicht sogar Sinn machen, da in der flfs Partion ganz am Ende auch noch zusammenhĂ€ngend Daten stehen - kein padding -. Damit ergĂ€be sich fĂŒr das von Dir genannte image:

(131072 + 5824512) / 131072 = 45,4375 ---> sollte laufen

Ich werde das auch nochmal dahingehend ĂŒberprĂŒfen...

e46ti


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Montag 14. Februar 2005, 16:24 
Offline
Image-Team

Registriert: Freitag 7. Februar 2003, 18:37
BeitrÀge: 1015
Wohnort: In der Dbox
Fragt doch ma jemand derget, der hat das doch auch analysiert mit dem Bootloader, das mit der GrĂ¶ĂŸe kann ich nicht glauben, denn sonst gingen ja keine grösseren Images, ich weis nur das alexW das wohl als einziger bis jetzt weis wie man das umgehen kann...

derget hat ja mal angefangen ein tool zu schreiben das das Image checkt, aber das is noch nicht fertig.

Also ich hab den u-boot 1.1.2 angepasst ans cvs da ist aber anscheind irgendwas am cramfs broken, squashfs bootet und cdk geht auch.

Gruß Riker


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Montag 14. Februar 2005, 17:02 
Offline
Interessierter
Interessierter

Registriert: Montag 14. Februar 2005, 10:10
BeitrÀge: 74
Zitat:

Fragt doch ma jemand derget, der hat das doch auch analysiert mit dem Bootloader, das mit der GrĂ¶ĂŸe kann ich nicht glauben, denn sonst gingen ja keine grösseren Images...



Doch, solange der Quotient ungerade ist und sich uboot im flash hinten befindet. Wie sich das verhĂ€lt, wenn u-boot vorne steht, muß ich noch ĂŒberprĂŒfen. Es kann aber gut sein, daß sich dann die Sache umkehrt und der Ouotient gerade sein muß. Wenn dem nicht so sein sollte, ist meine Theorie so nicht haltbar :evil:

e46ti


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Montag 14. Februar 2005, 17:13 
Offline
Tuxboxer
Tuxboxer

Registriert: Donnerstag 24. Oktober 2002, 19:14
BeitrÀge: 351
JtG-Riker hat geschrieben:
ich weis nur das alexW das wohl als einziger bis jetzt weis wie man das umgehen kann...


Jein, alexW hat ein Programm geschrieben, welches genauso wie das von derget, dass cramfs oder squashfs auf bad magics untersucht.

Es meldet also auch nur wenn eine bad magic enthalten ist, Àndert aber nichts an der Tatsache.

Also ohne Analyse des BMon's wird man die magics nicht herausfinden.

_________________
Mfg Sat_Man


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Montag 14. Februar 2005, 17:30 
Offline
Tuxboxer
Tuxboxer

Registriert: Freitag 14. Februar 2003, 15:59
BeitrÀge: 313
Bei jffs2only hab ich noch nie kein sysem nach flashen und da ist / (root) sicher grösser als 44*131072.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Montag 14. Februar 2005, 17:36 
Offline
Interessierter
Interessierter

Registriert: Montag 14. Februar 2005, 10:10
BeitrÀge: 74
@Head

aber sicherlich spÀter ab und zu mal ein offensichtlich 'zerschossenes' image, oder??

e46ti


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Montag 14. Februar 2005, 17:43 
Offline
Tuxboxer
Tuxboxer

Registriert: Freitag 14. Februar 2003, 15:59
BeitrÀge: 313
ja lezte hat ca 5 mon gehalten und x updaten (mach ich fast tÀglich) erst bei kernel update war schluss.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Montag 14. Februar 2005, 21:40 
Offline
Interessierter
Interessierter

Registriert: Montag 14. Februar 2005, 10:10
BeitrÀge: 74
@essu

Vielen Dank fĂŒr den Hinweis auf eines eurer images, die GrĂ¶ĂŸe allein ist offensichtlich nicht des RĂ€tsels Lösung.

e46ti


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Donnerstag 17. Februar 2005, 13:38 
Offline
Interessierter
Interessierter

Registriert: Montag 14. Februar 2005, 10:10
BeitrÀge: 74
Sat_Man hat geschrieben:
JtG-Riker hat geschrieben:
ich weis nur das alexW das wohl als einziger bis jetzt weis wie man das umgehen kann...


Jein, alexW hat ein Programm geschrieben, welches genauso wie das von derget, dass cramfs oder squashfs auf bad magics untersucht.

Es meldet also auch nur wenn eine bad magic enthalten ist, Àndert aber nichts an der Tatsache.

Also ohne Analyse des BMon's wird man die magics nicht herausfinden.


Hallo,

ist es hier möglich eine Version dieser Programme zu bekommen, oder sind die 'non public'?? :gruebel:

Danke,
e46ti


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Donnerstag 17. Februar 2005, 16:31 
Offline
Tuxbox-Semiprofi
Tuxbox-Semiprofi

Registriert: Montag 30. Dezember 2002, 08:02
BeitrÀge: 1287
Wohnort: http://yadi.org Anleitungen gibt es unter: http://wiki.godofgta.de
e46ti hat geschrieben:
ist es hier möglich eine Version dieser Programme zu bekommen, oder sind die 'non public'?? i


Ist AFIK non public. :(

Gruß
mogway


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Donnerstag 17. Februar 2005, 16:48 
Offline
Interessierter
Interessierter

Registriert: Montag 14. Februar 2005, 10:10
BeitrÀge: 74
@mogway
Eine andere Antwort hÀtte mich ehrlich gesagt auch sehr erstaunt.
Aber trotzdem danke fĂŒr die schnelle Antwort. 8)

Gruß,
e46ti


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Donnerstag 17. Februar 2005, 17:33 
Offline
Tuxbox-Meister
Tuxbox-Meister

Registriert: Montag 21. Oktober 2002, 09:04
BeitrÀge: 2452
Box: dbox2 NOKIA Avia500 2xI
2. Box: Golden Media 990 Spark Reloaded
3. Box: DREAMBOX
e46ti hat geschrieben:
...Eine andere Antwort hÀtte mich ehrlich gesagt auch sehr erstaunt....


Bleib trotzdem am Ball und berichte hier, ich finde das Thema sehr interessant.

_________________
Schon gelesen ???
ENIGMA-DOC


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Donnerstag 17. Februar 2005, 18:07 
Offline
Interessierter
Interessierter

Registriert: Montag 14. Februar 2005, 10:10
BeitrÀge: 74
Hallo essu,

ja das ist es 8)

Die Theorie das es an der GrĂ¶ĂŸe liegt war Zufall und deshalb Blödsinn.

Es scheint wohl vielmehr so zu sein, das eine bestimmte Zeichenfolge im squashfs/cramfs fĂŒr diesen Fehler verantwortlich ist. Man kann dies schön dadurch zeigen, daß wenn man ein squashfs was eigentlich geht mit dem hex Editor auf die GrĂ¶ĂŸe von einem etwas kleineren squashfs reduziert was nicht geht. Dann stellt man fest, daß das reduzierte squashfs immer noch geht - gilt natĂŒrlich nur fĂŒr den initialen scan -.

Bei mir war es bisher immer so, daß wenn ein squashfs nicht geht, es eigentlich egal ist wo es oder u-boot im flash absolut gesehen stehen - deswegen auch meine Frage nach images die nicht gehen -. Es geht dann einfach nicht - macht ja auch Sinn, wenn der flash komplett gescanned wird -.

Wenn man sich so ein squashfs mal mit dem hex editor ansieht, gibt es da einen kleinen Bereich in dem Zeichenfolgen erscheinen, die einen sehr stark an die 128 KB Blocksignaturen im BM Orginal image erinnern - C0 C3 FF C3 FE usw. -. Ich denke das so eine Zeichenfolge fĂŒr den Fehler verantwortlich ist.

Was ich jetzt als nÀchste mal probieren werde, ist mit den mksquashfs parametern zu spielen, d.h. blocksize oder noI z.B.. Dies löst zwar nicht das eigentliche Problem, hilft aber vielleicht aus einem squashfs was nicht geht, ein laufendes zu machen.

Also richtige Grundlagenforschung 8)
e46ti


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Samstag 19. Februar 2005, 15:21 
Offline
Interessierter
Interessierter

Registriert: Montag 14. Februar 2005, 10:10
BeitrÀge: 74
@all

So habe mal wieder ein wenig getestet. Hier kurz die Ergebnisse verbunden mit einer Frage an die Fachleute hier :gruebel:

Verwendung des mksquashfs Parameters -noI bringt keine VerÀnderung

Verkleinerung der block_size auf 32768 macht aus einem nicht lauffÀhigen squashfs ein funktionierendes squashfs


Diese Reduktion fĂŒhrt dabei natĂŒrlich zu einer geringfĂŒgigen Verschlechterung der Kompressionsrate:

block_size=65536 ---> image_size=6492160 bytes
block_size=32768 ---> image_size=6582272 bytes

Mit dieser Verschlechterung könnte ich aber gut leben 8)

Ob mit dieser block_size immer vermieden werden kann, daß in einem squashfs die Zeichenfolge erzeugt wird, die den Fehler im BM loader auslöst kann ich so noch nicht sagen. In diesem Fall hat es aber funktioniert. Vielleicht funktioniert die Sache ja auch umgekehrt, d.h block_size=32768 --> Fehler und block_size=65536 --> funktioniert. Dann könnte man einfach im Bedarfsfall entscheiden, welche Version Verwendung findet.

Einen Schönheitsfehler hat die Sache aber noch :oops:

Code:
FB:    ready
LCD:   ready
In:    serial
Out:   serial
Err:   serial
Net:   SCC ETHERNET
Hit any key to stop autoboot:  0
### FS (squashfs) loading 'vmlinuz' to 0x100000
SQUASHFS error: zlib::uncompress failed
### FS load complete: 622592 bytes loaded to 0x100000
...............................................................
Un-Protected 63 sectors
## Booting image at 00100000 ...
   Image Name:   dbox2
   Image Type:   PowerPC Linux Kernel Image (gzip compressed)
   Data Size:    623028 Bytes = 608.4 kB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... Bad Data CRC
=> ls
SquashFS version: 2.1
Files: 675
Bytes_used: 6581529
Block_size: 32768
Inodes are compressed
Data is compressed
Fragments are compressed
Check data is not present in the filesystem
Fragments are present in the filesystem
Always_use_fragments option is specified
Duplicates are removed
Filesystem size 6581529 bytes
Number of fragments 108
Number of inodes 675
Number of uids 1
Number of gids 0
[/code]

u-boot hat mit der geĂ€nderten block_size Probleme den Kernel zu starten. TatsĂ€chlich ist der Kernel 623092 bytes groß, deshalb wohl auch die obige Fehlermeldung. FĂŒr debug Zwecke habe ich mal den u-boot eigenen ls Befehl etwas abgeĂ€ndert, so zeigt sich das die Rahmendaten fĂŒr die squashfs Partition eigentlich richtig gesetzt sind.

Ich vermute, daß bei einer VerĂ€nderung der block_size fĂŒr die root Partition etwas im flfs code angepaßt werden muß? Kann mir dazu hier jemand einen Tip geben?

e46ti


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Samstag 19. Februar 2005, 16:40 
Offline
Tuxbox-Meister
Tuxbox-Meister

Registriert: Dienstag 8. Oktober 2002, 20:06
BeitrÀge: 2473
Wohnort: Hallenberg.com
mich wĂŒrde mal interessieren was mein Flashassistent zu solchen Images sagt, in der letzten Version habe ich ja eine ÜberprĂŒfung auf den Superblock eingebaut, damit erkannt werden kann ob das Image auch booten kann und nicht nachher die Meldung "Kein System" kommt.
Vielleicht könnte ja mal jemand so ein fehlerhafte Image auslesen und im dbox_ifa laden und dann die Meldung unter dem Dateinamentextfeld hier posten.

_________________
Test


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Samstag 19. Februar 2005, 18:25 
Offline
Interessierter
Interessierter

Registriert: Montag 14. Februar 2005, 10:10
BeitrÀge: 74
@gurgel,

ich weiß natĂŒrlich nicht wie Deine ÜberprĂŒfungsroutine funktioniert. Ich kann Dir aber sagen, daß sie auf den Fehler an dem ich im Moment arbeite in keiner Weise reagiert. Soll heißen, egal welches image ich von mir lade es kommt immer nur:

> Image fĂŒr eine d-box mit zwei Flashbausteinen

e46ti


Zuletzt geÀndert von e46ti am Samstag 19. Februar 2005, 21:02, insgesamt 1-mal geÀndert.

Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Samstag 19. Februar 2005, 18:34 
Offline
Tuxbox-Meister
Tuxbox-Meister

Registriert: Dienstag 8. Oktober 2002, 20:06
BeitrÀge: 2473
Wohnort: Hallenberg.com
aha, danke, kannst du mir vielleicht mal so ein Image zur Analyse schicken?

_________________
Test


Nach oben
 Profil  
Mit Zitat antworten  
BeitrĂ€ge der letzten Zeit anzeigen:  Sortiere nach  
Ein neues Thema erstellen Auf das Thema antworten  [ 119 BeitrĂ€ge ]  Gehe zu Seite 1, 2, 3, 4, 5  NĂ€chste

Alle Zeiten sind UTC + 1 Stunde


Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder


Du darfst keine neuen Themen in diesem Forum erstellen.
Du darfst keine Antworten zu Themen in diesem Forum erstellen.
Du darfst deine BeitrÀge in diesem Forum nicht Àndern.
Du darfst deine BeitrÀge in diesem Forum nicht löschen.
Du darfst keine DateianhÀnge in diesem Forum erstellen.

Gehe zu:  
Powered by phpBB® Forum Software © phpBB Group
Deutsche Übersetzung durch phpBB.de