[Gelöst]Umbau 7270 8MB auf 16MB Flash.... (bzw.32MB[Ungelöst])

[highlander78]

Aber eine andere Frage: Kann es sein, dass deine Filesysteme einfach "zu klein" sind? Die Box erkennt ja
"ur8_jffs2_parser_function] magic 20031985 found @pos 0x720000, size 25559040"
und sucht nun ein Image dieser Größe, was aber garnicht angelegt wurde??

Letztlich alles Vermutung, da müsste man wohl den jffs2-Treiber etwas gesprächiger machen, um weiter zu kommen.....

Was meinst du genau zu klein , was könnte ich noch versuchen ?


P.S. schaue die Bitte die Logdatei mal an , ist das hier das gleiche Problem wie in dem Log davor

 

[MaxMuster]

Naja, eigentlich sollte (wenn ich dich richtig verstanden habe) bei dem "nicht funktionierenden Boot" gegenüber dem funktionirenden nur der Bootlader verändert sein, der Rest des Images also gleich.
Dann ist es aber merkwürdig, dass die Box ein größeres JFFS2 Filesystem "findet". Ich habe die Vermutung, dass das (ein Teil deines) Problems sein kann: Die Box versucht im "leeren" Flash ein Filesystem zu finden....
Das muss ja vorher, vor dem Bauen des Images, angelegt worden sein, deshalb meinte ich, dass es "zu klein" ist.

Jörg

EDIT Im Log hast du den Bootlader (mtd2) vergößert. Vielleicht ist darin der Starttpunkt des nächsten Bereichs nochmal woanders "hard-coded" so dass nur "0x90000000 bis 0x90020000" möglich ist ?!? Ich bin da aber im Moment auch nur am Raten...

EDIT2: Könntest du vielleicht mal eine Box so starten, wie du das in #14 beschrieben hast, also "vorne" nur mtd2, dann "nix" und dann ab 16MB (+ Bootlader-Länge) dann mtd1, 3 und 4 und das Log posten? Ich hoffe halt, man findet einen Ansatzpunkt, vielleicht bewegt man sich damit dann "langsam" von oben runter mit dem Anfang von mtd1, also danach dann mal nicht gleich auf "0x90020000,0x91F80000" gehen, sondern z.B. "0x90820000,0x91F80000"

 

[highlander78]

Also willst du den Log von dieser Aufteilung sehen , ist das richtig ?

mtd1 0x91020000,0x91F80000
mtd2 0x90000000,0x90020000
mtd3 0x91F80000,0x91FC0000
mtd4 0x91FC0000,0x92000000

 

[MaxMuster]

jepp

Jörg

...und dann vielleicht mal:

mtd1 0x90820000,0x91F80000
mtd2 0x90000000,0x90020000
mtd3 0x91F80000,0x91FC0000
mtd4 0x91FC0000,0x92000000

 

[highlander78]

So hier die Logdatei

P.S mtd1 0x90820000,0x91F80000 bekommst du morgen , keine Zeit mehr heute

 

[highlander78]

Hier die Logdatei (0x90820000)..

Habe noch was versucht und zwar die reihenfolge der mtds zu ändern.
Ganz vorne mtd2, danach gleich mtd3 und 4 und zum schluss mtd1 ( mtd1 länge F60000).
Die Box habe ich dann mit recover.exe hergestellt , an der mtd Aufteilung wurde nichts geändert.

mtd1"="0x910A0000,0x92000000"
mtd2"="0x90000000,0x90020000"
mtd3"="0x90020000,0x90060000"
mtd4"="0x90060000,0x900A0000"

 

[MaxMuster]

Tja, viel sehe ich da nicht. Was mir aber auffällt: Scheinbar werden beim Logging Sachen manchmal "verschluckt", z.B.

pcibios_read_config: accessing PCI slot not present: 8, where 0, size 4
pcibios_read_config: accessing PCI slot not present: 9, where 0, size 4
pcibios_read_config: accessing PCI slot not present: 10, where 0, size 4
[B]pcibios_rifier][/B]
[ur8_mtd_add_notifier] skip urlader
0x00020000-0x00060000 : "tffs (1)"

Ob da was "wichtiges" fehlt, kann man nicht wissen...


Rein vom Inhalt her hat mir dein erster 32MB-Versuch "noch am besten gefallen": Das squashfs wurde gefunden, die Box hat das init (also die busybox gestartet) und "nur" beim jffs2 gab es Probleme.
Wenn ich die Logs richtig gelesen habe hast du den 32MB-Log mit einem Original-Image,

mknod: /var/flash/ar7.cfg: File exists
Piglet_noemif: module license '

den drauffolgenden "guten" 16MB-Log aber mit einem Freetzimage gemacht:

mknod: /var/flash/ar7.cfg: File exists
Loading /var/flash/freetz...done.
Loading users, groups and passwords...done.
Loading hosts...done.
Loading config...done.
Loading modules...done.
Piglet_noemif: module license '

Könntest du bitte mal einen Test machen mit 32MB-Aufteilung und freetz 16MB Image?

Jörg

EDIT Vielleicht kannst du ja mal ein "Mega-Image" bauen und das per "push-firmware" oder per FTP flashen, analog zu diesem Patch sollte der anhängenden auf 32 MB angepasst sein:

Größe für mtd1 ist 0x1F60000 = 32,128 MB = 502 * 64k

 

[highlander78]

Was soll es eigentlich bringen ein "Mega-Image" zu bauen und zu flashen wenn ein "normales" bis jetzt in dem 32MB Flash nicht läuft ?

 

[MaxMuster]

Ich würde zumindest gerne sehen, wie ein Image aussieht, das für diese Flashgröße gebaut wird.
Ein "Problem" ist: Beim (laufenden) 16 MB Image findet die Box das JFFS in der "richtigen" Größe; obwohl noch "viiiiiel Platz im Flash wäre ist das Ergebnis:

[ur8_jffs2_parser_function] mtd_info->name physmap-flash.1 mtd_info->index 0 param=0 p_mtd_pat=0x947814bc
[ur8_jffs2_parser_function] try partition kernel (offset 0x20000 [B]len 16121856[/B])
[ur8_jffs2_parser_function] magic 20031985 found @pos 0x9a0000, [B]size 6160384[/B]

beim 32MB Log jedoch scheint die Box "den ganzen Rest" als JFFS nehmen zu wollen, was so nicht stimmen kann, denn schließlich ist das ein "kleines" Image:

[ur8_jffs2_parser_function] mtd_info->name physmap-flash.1 mtd_info->index 0 param=0 p_mtd_pat=0x947814bc
[ur8_jffs2_parser_function] try partition kernel (offset 0x20000 [B]len 32899072[/B])
[ur8_jffs2_parser_function] magic 20031985 found @pos 0x720000, [B]size 25559040[/B]

Ich hoffe halt, hier eine Veränderung zu erzielen, wenn die richtige Größe beim Bauen genutzt wird (es soll ja nicht "voller" werden, nur die maximale Größe soll korrekt sein...)

Jörg

 

[jenswmeyer]

Die neue Labor "all in one" 54.04.63-11876 ist auch größer als 8 MB ~ ca. 9,8 MB, ich frage mich wie das gehen soll, wenn es auch 8 MB Boxen geben soll? Also müsste ein flashen über das Web-Interface doch dann auch möcglich sein? Ich musste bisher immer über push firmware das update machen, oder ist es seit der x.58 generell möglich über 8 MB über das webinterface zu flashen?

 

[MaxMuster]

Gerade was "blödes" gefunden in source/ref-8mb_26-7270/kernel/kernel_8mb_26_build/kernel/linux-2.6.19.2/arch/mips/mips-boards/ur8/ur8_mtd.c:

/* NOTE: CFI probe will correctly detect flash part as 32M, but EMIF
 * limits addresses to 16M, so using addresses past 16M will wrap */

EMI ist wohl der Memory-Controller...

Hoffentlich ist das kein k.o.-Kriterium...


Jörg

 

[highlander78]

MIr ist was komisches aufgefallen.
Wenn ich zuerst den geänderten Urlader Flashe ( mtd1 natürlich auf 32MB angepast) ist zuerst alles ok.
Danach Flashe ich per FTP mtd3 und mtd4, nach dem neustart startet der Urlader noch.
Erst wenn ich mtd1 flashe startet die box nicht mehr, so als wäre der Urlader hinüber...erst nach dem erneutem flashen vom Urlader (mtd2) startet die Box wieder.So war es bis jetzt jedes mal mit der reänderten grösse von mtd1..

Habe irgendwie das Gefühl das das irgendwo begrenzt ist....auf (F60000)

 

[GuruHacker]

das heißt genau das eigentlich mehr als 16MB nicht gehen?

Villeicht haben die immernoch den "alten" controller, weil sie sonst noch mehr am Board rumfummeln müssten?

Ich habe hier die ganze Thematik mitverfolgt, aber wie ich das gelesen habe, ist es wohl nicht möglich über 16MB zu gehen.

@edit: Vor mir war wieder highlander78 schneller

 

[GuruHacker]

/* NOTE: CFI probe will correctly detect flash part as 32M, but EMIF
 * limits addresses to 16M, so using addresses past 16M will wrap */

Öhm wie soll ich das verstehen jetzt genau:

Will das heißen das der/das CFI den flash als 32M erkennt, aber das EMIF nur adressen bis 16M unterstützt? Na das nenn ich mal wieder eine "geniale logik".
Kann es sein, das in den 16MB Boxen eigentlich 32M Speicher sind, aber die nur als 16M erkannt werden? Oder leite ich das falsch vom text ab?

 

[MaxMuster]

Ich würde daraus lesen, für die Box ist der Bereich 0x90000000,0x90ffffff "identisch" mit 0x91000000,0x91ffffff , weil die Box bei Zugriffen über die 16MB-Grenze hinaus "wieder unten anfängt"...


Jörg

 

[highlander78]

Dann kann ich das ganze testen schön langsam aufgeben

 

[MaxMuster]

Du könntest die Vermutung zumindest verifizieren:
Wenn ich das recht erinnere, haben die Versuche funktioniert, die dem Schema entsprachen: Entweder "normal" alle mtd's im unteren 16MB Bereich oder auch mtd2 "unten" (0x90000000,0x90020000), aber dann lagen die anderen mtd im oberen Bereich "parallel" dazu (also ab 0x91020000, was ja der Theorie nach mit 0x90020000 "identisch" wäre.)

Ein Versuch wäre dann, die mtd1 "über die Grenze" zu legen (z.B. 0x90820000,0x91780000 mit der "richtigen" Größe 0xF60000), also in etwa so:

mtd1"="0x90820000,0x91780000"
mtd2"="0x90000000,0x90020000"
mtd3"="0x90020000,0x90060000"
mtd4"="0x90060000,0x900A0000"

Stimmt die Theorie "es kommt nur auf die Größe an", sollte das gehen, werden die Adressen oberhalb von 0x91000000 auf die unteren gemapped, würde das Einspielen von mtd1 "alles Zerstören" und du müsstest wieder per JTAG ran....

Jörg

 

[highlander78]

Also habe es so probiert:

mtd1"="0x90820000,0x91780000"
mtd2"="0x90000000,0x90020000"
mtd3"="0x90020000,0x90060000"
mtd4"="0x90060000,0x900A0000"

mtd2 per EJTAG , danach mtd3 und mtd4 per FTP ( mal kurz angesteckt , Urlader kommt nocht ). Danach mtd1 per FTP und nichts geht mehr, Urlader wieder hinüber .... glaube da ist nichts zu machen um die 32MB nutzen zu können . Habe keine Idee mehr was ich nocht testen soll.....

 

[MaxMuster]

Ja, denke ich auch dass damit wohl "bewiesen ist", dass alles über der 16MB-Grenze nach unten "gespiegelt" wird....
Hat ja einiges an Zeit gebraucht, das herauszuarbeiten, aber zumindest weiß man, woran man ist.

Danke für deinen Forscher-Einsatz!

Jörg

 

[PsychoMantis]

"Geht nicht". Geht es von der Software her nicht oder von der Hardware her nicht?
Der Thread sollte meiner Meinung nach umbenannt werden (statt 16MB 32MB).