servus
was ist der ("technische") unterschied zwischen images für dboxen mit einem flashbaustein und für welche mit zwei?
und falls das auch noch jemand weiß: wo gibts programme zum "umwandeln" von 1x images nach 2x images bzw umgekehrt? wenn das besagte programm opensource wär wärs klasse.
ciao, schonmal danke für die hilfe
johannes
unterschied zwischen "1x intel" und "2x intel
-
theclaw
- Neugieriger
- Beiträge: 4
- Registriert: Dienstag 10. August 2004, 13:49
-
myRaiko
- Neugieriger
- Beiträge: 16
- Registriert: Mittwoch 5. Juli 2006, 17:56
-
theclaw
- Neugieriger
- Beiträge: 4
- Registriert: Dienstag 10. August 2004, 13:49
naja, danke für die antwort, aber das war eigentlich nicht das was ich wissen wollte. was ist denn der grund dafür, dass es überhaupt zwei verschiedene images geben muss?myRaiko hat geschrieben:soweit ich weiß sind die 2xI schneller als 1xI. Da 2 Datenpakete gleichzeitig geschrieben werden können.
eigentlich sollte es doch auch images geben die für beide boxen verwendet werden können.
ciao
johannes
-
UEning
- Einsteiger
- Beiträge: 152
- Registriert: Montag 6. September 2004, 18:18
Moineigentlich sollte es doch auch images geben die für beide boxen verwendet werden können.
ciao
johannes
Das Wiki hilft ein wenig weiter...
Die Dbox 2 wurde von drei verschiedenen Herstellern (Nokia, Philips und Sagen) hergestellt.
Jeder Hersteller hat halt seine eigenen "Ideeen" eingebracht...
http://wiki.tuxbox-cvs.sourceforge.net/Dbox2
MfG UEning
-
rasc
- Senior Member
- Beiträge: 5071
- Registriert: Dienstag 18. September 2001, 00:00
Das hat nichts mit Geschwindigkeit zu tun, sondern eher mit der Speicherstruktur. Beim Flashen werden die Bytes/Worte - je nach Speicherbausteinen - anders geschrieben.theclaw hat geschrieben:naja, danke für die antwort, aber das war eigentlich nicht das was ich wissen wollte. was ist denn der grund dafür, dass es überhaupt zwei verschiedene images geben muss?myRaiko hat geschrieben:soweit ich weiß sind die 2xI schneller als 1xI. Da 2 Datenpakete gleichzeitig geschrieben werden können.
eigentlich sollte es doch auch images geben die für beide boxen verwendet werden können.
ciao
johannes
Prinzipiell haette ein Image gereicht, wenn man die Transformation für die Speicherarchitektur im Flash-Programm gemacht haette - nur so wie es jetzt ist, ist es halt einfacher.
-
Carjay
- Developer
- Beiträge: 122
- Registriert: Sonntag 23. April 2006, 12:37
Naja, das erklärt aber immer noch nicht den wahren[TM] Grund. 
Derget hat das an anderer Stelle ( http://forum.tuxbox-cvs.sourceforge.net ... &start=100 ) schon einmal ausgeführt.
Das Problem ist, daß wir den BMon für den ersten Start nutzen müssen, weil wir diesen aus nachvollziehbaren Gründen nicht überschreiben wollen.
Hintergrund: die in der dbox2 verwendeten Flashes lassen sich nicht wahlfrei löschen, d.h. man kann nicht einfach ein Byte überschreiben, sondern muß immer einen ganzen Block mitnehmen. Das sind z.B. 64 kByte. Will man nur ein Byte ändern, muß man die 64 kByte kopieren, das Byte ändern, den Sektor im Flash löschen und zurückschreiben.
Die CPU arbeitet allerdings immer auf 32 Bit gleichzeitig. Bei den 2xFlash-Boxen wird der Zugriff auf die beiden Flashes aufgeteilt, jeweils 16 Bit. Das bedeutet aber auch, daß man immer auf 2 Sektoren zugreift (nämlich jeweils einer in jedem Flash).
Das Ungünstige dabei ist, daß man nun immer 2 Sektoren löschen und somit eine Blockgröße von 128 kByte an einem Stück verwalten muß.
Das war BR wohl zuviel und sie haben sich ein eigenwilliges Konzept ausgedacht, bei dem die Daten linear (an einem Stück) in den Flashes liegen. Da der Zugriff über das verwendete FLFS-Dateisystem abstrahiert wird, ist das auch kein Problem und wird im laufenden Betrieb rückgängig gemacht.
Der BMON muß diese Struktur natürlich beim Booten berücksichtigen und benutzt bei 2x-Boxen eine andere Such/Lesestrategie als bei 1x-Boxen (bei denen diese Trickserei nicht nötig ist, daß dort die minimale Sektorgröße wie gewünscht 64 kByte groß ist).
Es ist daher ohne Platzverschwendung nicht möglich, ein Image für beide Arten von Flashes auszulegen.
Das von Tuxbox verwendete Filesystem ist allerdings unabhängig von der Anzahl der Flashes, die einzige "flashabhängige" Komponente ist der Sektor, in dem der Uboot liegt.
Derget hat das an anderer Stelle ( http://forum.tuxbox-cvs.sourceforge.net ... &start=100 ) schon einmal ausgeführt.
Das Problem ist, daß wir den BMon für den ersten Start nutzen müssen, weil wir diesen aus nachvollziehbaren Gründen nicht überschreiben wollen.
Hintergrund: die in der dbox2 verwendeten Flashes lassen sich nicht wahlfrei löschen, d.h. man kann nicht einfach ein Byte überschreiben, sondern muß immer einen ganzen Block mitnehmen. Das sind z.B. 64 kByte. Will man nur ein Byte ändern, muß man die 64 kByte kopieren, das Byte ändern, den Sektor im Flash löschen und zurückschreiben.
Die CPU arbeitet allerdings immer auf 32 Bit gleichzeitig. Bei den 2xFlash-Boxen wird der Zugriff auf die beiden Flashes aufgeteilt, jeweils 16 Bit. Das bedeutet aber auch, daß man immer auf 2 Sektoren zugreift (nämlich jeweils einer in jedem Flash).
Das Ungünstige dabei ist, daß man nun immer 2 Sektoren löschen und somit eine Blockgröße von 128 kByte an einem Stück verwalten muß.
Das war BR wohl zuviel und sie haben sich ein eigenwilliges Konzept ausgedacht, bei dem die Daten linear (an einem Stück) in den Flashes liegen. Da der Zugriff über das verwendete FLFS-Dateisystem abstrahiert wird, ist das auch kein Problem und wird im laufenden Betrieb rückgängig gemacht.
Der BMON muß diese Struktur natürlich beim Booten berücksichtigen und benutzt bei 2x-Boxen eine andere Such/Lesestrategie als bei 1x-Boxen (bei denen diese Trickserei nicht nötig ist, daß dort die minimale Sektorgröße wie gewünscht 64 kByte groß ist).
Es ist daher ohne Platzverschwendung nicht möglich, ein Image für beide Arten von Flashes auszulegen.
Das von Tuxbox verwendete Filesystem ist allerdings unabhängig von der Anzahl der Flashes, die einzige "flashabhängige" Komponente ist der Sektor, in dem der Uboot liegt.