Ursache für 'Kein System'

[e46ti]

Ich bin neu hier im Forum und möchte erst einmal allen ein freundliches 'Hallo' sagen

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: Alles auswählen

--- 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

[Npq]

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?

[e46ti]

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

[essu]

[...]
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.

[Houdini]

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 = base + info->size - ((64 - i) * 0x20000);

Houdini

[e46ti]

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

[essu]

http://prdownloads.sourceforge.net/dbox ... g?download

Damals noch mtd3, also u-boot vorn.

Filesize: 5824512. Widerspricht das nicht deiner Theorie?

[essu]

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....

[e46ti]

@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

[JtG-Riker]

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

[e46ti]

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

e46ti

[Sat_Man]

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.

[HEAD]

Bei jffs2only hab ich noch nie kein sysem nach flashen und da ist / (root) sicher grösser als 44*131072.

[e46ti]

@Head

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

e46ti

[HEAD]

ja lezte hat ca 5 mon gehalten und x updaten (mach ich fast täglich) erst bei kernel update war schluss.

[e46ti]

@essu

Vielen Dank für den Hinweis auf eines eurer images, die Größe allein ist offensichtlich nicht des Rätsels Lösung.

e46ti

[e46ti]

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'??

Danke,
e46ti

[mogway]

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

Ist AFIK non public.

Gruß
mogway

[e46ti]

@mogway
Eine andere Antwort hätte mich ehrlich gesagt auch sehr erstaunt.
Aber trotzdem danke für die schnelle Antwort.

Gruß,
e46ti

[essu]

...Eine andere Antwort hätte mich ehrlich gesagt auch sehr erstaunt....

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

[e46ti]

Hallo essu,

ja das ist es

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
e46ti

[e46ti]

@all

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

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

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

Code: Alles auswählen

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

[gurgel]

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.

[e46ti]

@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

[gurgel]

aha, danke, kannst du mir vielleicht mal so ein Image zur Analyse schicken?