Moin
So ich hab gerade durch zufall mal ins cvs gekukt und da was feines gefunden, was mich schliesslich hierher brachte.
Und da alexw sich ja auch schon zu Wort gemeldet hat wollte ich hier auch noch was klarstellen.
Mein Wissen und meine Rescherschen über das "kein system" Problem waren absolut nicht unpublic, sie waren nur noch so sehr unreif das ich das Programm dazu damals nicht ins cvs eingecheckt hatte, und das dann auch mangels Zeit und Interteresse nicht weiter verfolgt habe.
Mir hätte halt mal wer ne Mail schicken sollen, dem hätte ich die Infos gerne zur verfügung gestellt.
Aber das Meistste habt ihr wohl jetzt schon selber rausgefunden.
Trotzdem hier nun meine Erkenntnisse.
Mein Programm (war auch nur crap) hab ich gerade gesucht und nicht mehr gefunden :( aber aus meinen Chatlogs und meinem Gedächnis kann ich das meiste rekapitulieren.
1.
Bei den ganzen betrachtungen muss man zwischen 1x und 2x Boxen unterscheiden, das liegt dadran das br das Flash bei 2x anders aufteilt als wir und zwar besser :)
bei 2x haben wir zwei 4 Mb grosse Flashes mit je 16 bit daten breite in den Boxen.
diese werden in hardware zu einem virtuellen Flash zusammengefürt das dann 8Mb gross ist und 32 bit daten breite hat und so liegen die Flashes auch für die cpu im 32 bit mode vor
das ganze sorgt aber dafür das ein tolles feature von 2x Anordnungen wieder rückgängig gemacht wird.
Nähmlich das feature das die beiden 4 Mb Flashes aus 64kb grossen errase Regionen bestehen.
Durch die 32 bit Ansteuerung und die dadurch "interlaced" angeordneten Daten wird die erase size auf 128k erhöht.
Das Hardware mässige verschalten der beiden Flashes seitens Nokia
wird aber nur vom Bootloader benutzt, weil der ja für die cpu accesseble sein muss und weil die cpu im 32 bit daten mode arbeitet ...
Br macht ab da dann aber das "interlacen" wieder rückgänging und benutzt beide flash bausteine linerar hintereinadergeschaltet für ihr flfs
was den vorteil hat das die erasesize nur 64kb beträgt (wobei dafür unnötig offt bytes geswappet werden müssen vom br kernel)
Hierzu mal ein "Bild" das ich vor Jahren gezeichnet habe :)
============ =============
= Flash I == == Flash II =
============ =============
= AA BB == == CC DD = 0x0 - 0x10000Bootloader
= EE FF == == GG HH =
============ =============
= AA BB == == GG HH = 0x10000 - 0x400000FLFS
= CC DD == == II JJ =
= EE FF == == KK LL =
============ =============
hmpf irgentwie sucks meine AscII art hier. Besser sieht man es auf
http://noernet.de/flfs.data
So unter linux benutzen wir diesen üblen Trick nicht, wir sprechen das Flash über den ganzen bereich im 32 bit Modus an und schreiben interlaced in beide Flashes.
Das muss man im Kopf haben weil der Bootloader bei 2x im Flash nach den Magics im 16 bit modus sucht und das bei 2x auch noch im 64k schritten und nicht wie auf 1x in 128k schritten.
Das ist aber halb so wild wenn man mal verstanden hat wie das funktioniert.
Deshalb die nächsten Sachen nur für 1x varianten, 2x is nur eine Abwandlung davon ...
2.
das flfs besteht aus 63 Sectoren ah 128k auf 1x
aus 126 sectoren ah 64k auf 2x
Wie die Sectoren im Flash verteilt sind muss keiner logischen Reihenfolge unterliegen, d.h. wo der erste Sector liegt ist egal und wo die anderen Sectoren liegen ist auch egal, d.h. 2 muss nicht hinter 3 liegen etc ...
vom Bootloader wird das gesamte flfs nach der Anfangsmagic vom ersten Sector gescannt diese lautet "0xf0, 0xa4, 0x03, 0x01"
d.h. diese Magic darf an keinem Sector anfang stehen (also bei 2xi NIE
alle 64kb und bei 1xi NIE alle 128kb)
3.
so nur nicht der Anfang sondern auch das Ende der Sectoren wird vom Bl
untersucht.
Das Ende ist nähmlich der Schlüssel um zu erkennen um welchen Sector es sich handelt
Da spielt der erste Sector wieder eine besondere Rolle bei ihm steht am Ende 0xFF, 0xFF, 0xC3, 0xFE
Dieses darf so nur bei dem Sector stehen der am Anfang das "0xf0, 0xa4, 0x03, 0x01" hat
so und nun sind wir da wo ich vor 1 Jahr aufgehört habe :)
4.
noch ein paar nicht ausprobierte Theorien zu dem Sector Ende
die Sectoren sind durchgezählt was durch die 4 letzten bytes am ende dargestellt wird
Sector 1 btw hm ich seh grad es ist eigentlich Sector 0 :)
ist da ja besonders mit 0xFF, 0xFF, 0xC3, 0xFE
das wichtige ist da das 0xFE
alle anderen haben 0xFF
in welchem sector man ist erkennt man an dem 2ten byte
0xFF ==> sector 0
0xFE ==> sector 1
0xFD ==> sector 2
etc ...
siehe auch mkfls.c
sector_63 hat 0xFF, 0xc0, 0xC3, 0xFF
0xc0 = 255 - 63
Jetzt ist die frage wie pingelig der Bootloader da ist
das wollte ich eigentlich mal reverse assemblen aber dazu binn ich noch nicht gekommen :)
meine Theorie währe das sobalt der Bootloader einen sector 2x mal findet
dann ist er der meinung das da was kaput ist :)
z.b. wenn er 2x 0xFF, 0xFA, 0xC3, 0xFF
oder 2x 0xFF, 0xDD, 0xC3, 0xFF
oder 2x 0xFF, 0xCF, 0xC3, 0xFF
etc ...
am ende der Sectoren findet.
Wobei es auch gut sein könnte das er die Bytes die sich eh nicht ändern bei dem Check sogar ignoriert.
So soweit mal die Infos von mir
macht da mal fleissig weiter
derget
.