aXeL - accelerated loader

[DeadBeef]

[quote=""macfan""]Aber für mich ist es ein KO-Kriterium, wenn man nicht mehr mit 0 die TAPs ausblenden kann. Da ich oft Alphas und Betas teste, brauche ich das. DeadBeef, besteht eine Chance, dass du das mit der 0 noch hinbekommst?
[/quote]Die Erkennung der 0 passiert komplett in der Firmware (d.h. nicht im Bootloader). Das Zeitfenster, in dem die 0 einzugeben ist, scheint durch die schnelle Verfügbarkeit der Festplatte signifikant geschrumpft zu sein. Die einzige Möglichkeit, es wieder zu vergrößern, wäre die frühzeitige Festplattenaktivierung auszukommentieren. Sonst ließe es sich nur über TAPs steuern. Man könnte z.B. dem Menu-TAP beibringen, die TAPs grundsätzlich eine Sekunde später zu starten, wenn während dieser Sekunde die 0 nicht gedrückt wird.

[DeadBeef]

[quote=""StevieC""]Also auf meinem 6000er hat es nicht funktioniert. Nach dem Aufspielen bleibt L416 im Display stehen, die Festplatte läuft auch nicht an. ...
[/quote]Gibt es irgendwelche Ausgaben auf der seriellen Schnittstelle?

[StevieC]

[quote=""DeadBeef""]Gibt es irgendwelche Ausgaben auf der seriellen Schnittstelle?[/quote]

Die serielle Schnittstelle kann ich leider nicht abfragen, hab keine. USB Adapter funktioniert bei mir leider nicht.
Glaube aber nicht, das da was kommt, denn sobald man den Topf einschaltet bleibt L416 stehen, ausschalten geht nur per Stecker ziehen.

Gruß

StevieC

[Harvey]

Geniale Idee. Meisterhaft.

Ich gebe zu, mich mit der Cachetechnologie des Mips nicht auszukennen (gibt es einen Link dazu?), aber warum sind innerhalb der Schleife in relocate()

Code: Alles auswählen

    "  cache 0x10,0(%0)\n" // invalidate instruction cache
    "  cache 0x15,0(%0)\n" // flush data cache

notwendig? eigentlich müsste es doch reichen, wenn das RAM genau vor

Code: Alles auswählen

(execute + RELOC_OFFSET)();

konsistent ist .

[DeadBeef]

[quote=""Harvey""]Ich gebe zu, mich mit der Cachetechnologie des Mips nicht auszukennen (gibt es einen Link dazu?), aber warum sind innerhalb der Schleife in relocate()

Code: Alles auswählen

    "  cache 0x10,0(%0)\n" // invalidate instruction cache
    "  cache 0x15,0(%0)\n" // flush data cache

notwendig? eigentlich müsste es doch reichen, wenn das RAM genau vor

Code: Alles auswählen

(execute + RELOC_OFFSET)();

konsistent ist .[/quote]

Einen Link dazu kann ich ich leider nicht anbieten. Man benutze das, was im MIPS User Manual steht.

Man kann nicht davon ausgehen, daß die kopierten Daten dem Instruction Cache sofort zur Verfügung stehen. Jedenfalls geht es ohne "flush" nicht. Es würde vielleicht auch ohne "invalidate" funktionieren, aber "sicher ist sicher".

[Harvey]

Ohne nerven zu wollen:

Berichtige mich, wenn ich mit folgenden Annahmen falsch liege. In Realloc machst Du nichts anderes, als (noch) Daten von 80xxxxxx nach 81xxxxxx zu kopieren. Der Code dazu steht statisch in 80xxxxxx.

Erst wenn Du die Ausführung auf 81xxxxxx umleitest, muss sicher gestellt sein, dass der Datencache ins RAM kopiert wird und der Instructioncache nicht versehentlich was altes aus diesem Bereich hat (z.B. den 2. Original- Loader). Und genau da habe ich mein Verständnisproblem: Warum reicht der Zwangsflush nicht einmalig hinter der Schleife? Innerhalb der Schleife müsste es der Datencache selbst raffen, sich in den Speicher zu schreiben, wann er es für richtig hält, sein Segment zu ändern.

[ByteHunter]

Hallo!

Ich denke auch, daß ein Flush in einer Schleife unnötig Zeit verbraucht. Wenn der MIPS da nur ein internes Flag setzt, um den Cache für ungültig zu erklären, mag das noch angehen (wäre allerdings auch ein unnötiger Zugriff auf den Programmspeicher), wenn der aber tatsächlich alles mit Nullen oder Einsen füllt...

Also einen Versuch wär's wert, das Flushen aus der Schleife rauszunehmen. Habe leider noch keine Entwicklungsumgebung laufen, sonst hätte ich's schon probiert. Was kann schon schiefgehen? Der alte Booter nimmt doch im Falle eines Mißerfolgs auch wieder die alte Firmware von USB/RS232 entgegen, oder?

Viele Grüße vom ByteHunter

[DeadBeef]

[quote=""Harvey""]Ohne nerven zu wollen:
....
Und genau da habe ich mein Verständnisproblem: Warum reicht der Zwangsflush nicht einmalig hinter der Schleife? Innerhalb der Schleife müsste es der Datencache selbst raffen, sich in den Speicher zu schreiben, wann er es für richtig hält, sein Segment zu ändern.[/quote]

Ohne genervt zu erscheinen , schau doch mal, was die Firmware ziemlich am Anfang macht:

Code: Alles auswählen

    80000078:    340b4000    move    $t3,0x4000        
    8000007c:    340a0010    move    $t2,0x10        
    80000080:    3c098000    lui    $t1,0x8000        
    80000084:    00004025    move    $t0,0            
    80000088:    bd200000    cache    0,0($t1)        
    8000008c:    00000000    nop                
    80000090:    012a4821    addu    $t1,$t2            
    80000094:    150bfffc    bne    $t0,$t3,80000088r    
    80000098:    010a4021    addu    $t0,$t2            

Ein Flush bremst die CPU natürlich auf die Geschwindigkeit vom RAM runter, weil es sicherstellt, daß die Daten im RAM landen. Ein Cache-Befehl bedient immer nur eine Cache-Line (in dem Fall 16 bytes). Und Schreiben einer Cache-Line ins RAM bedeutet nicht, daß die nächste Cache-Line bald auch dort landet. Es ist nicht so, daß aXeL seinen Code megabyteweise umkopiert. Daher ist der Zeitaufwand verschwindend gering, wenn man ihn mit dem Entpacken der Firmware vergleicht (~1,7 MB => ~3,6MB).
Darüber hinaus wollte die CPU ohne ein Cache-Flush sowieso nicht weitermachen. Also hat sie das bekommen, womit sie glücklich ist. Ihr seid aber herzlich eingeladen, selbst zu experimentieren - dafür sind die Sourcen da.

[nilssohn]

Wann immer ich Euch Architekten zuhöre, fühle ich mich wie in der "Matrix". Voller Staunen, welches TAP-Universum Ihr um uns Benutzer herum bastelt, ohne dass wir es bemerken. Respekt! :

Viele Grüße

nilssohn

[DeadBeef]

Ich habe eine neue aXeL-Version erstellt - 1.01. Diese Verison unterscheidet zwischen Einschalten durch Fernbedienung und am Gehäuse. Wenn der Receiver am Gehäuse eingeschaltet wird, läßt aXeL die frühzeitige Aktivierung der Festplatte aus. Somit steht mehr Zeit zum Drücken der 0 zur Verfügung, um das Starten von TAPs zu unterbrechen.

Des weiteren sollte es jetzt auch mit dem TF6000 klappen. Die erste Version wurde vom Bootloader wegen der Größe nicht akzeptiert.

Sobald es positive Rückmeldungen gibt, werde ich den ersten Beitrag aktualisieren.

[StevieC]

[quote=""DeadBeef""]Ich habe eine neue aXeL-Version erstellt - 1.01. Diese Verison unterscheidet zwischen Einschalten durch Fernbedienung und am Gehäuse. Wenn der Receiver am Gehäuse eingeschaltet wird, läßt aXeL die frühzeitige Aktivierung der Festplatte aus. Somit steht mehr Zeit zum Drücken der 0 zur Verfügung, um das Starten von TAPs zu unterbrechen.

Des weiteren sollte es jetzt auch mit dem TF6000 klappen. Die erste Version wurde vom Bootloader wegen der Größe nicht akzeptiert.

Sobald es positive Rückmeldungen gibt, werde ich den ersten Beitrag aktualisieren.[/quote]

Danke Deadbeef, kann ich aber erst heute Nacht testen.

Gruß

StevieC

[cbr900de]

Also das mit der 0 beim Starten funktioniert bei mir jetzt dadurch wieder ohne Probleme, dake dafür!

Ansonsten hatte ich bis jetzt auch keine anderen Probleme mit aXeL. Wircklich Toll was Du da machst!!

Gruß Marcel

[BlackOne]

also die 1.01 geht auf meinem 6oooer sehr gut
(und auch ohne bildflackern )
(hat aber auch nur 3 taps im autostart)

beim 55ooer werde ich morgen mal testen

[StevieC]

Grad ausprobiert, 101 läuft perfekt auf dem 6000er. Starten ohne Taps mit 0 ist auch möglich.

Gruß

StevieC

[ameise999]

hallo,

ehrlich gesagt verstehe ich die funktion nicht ops:
wenn ich den topf mit 0 starte, werden doch auch keine taps geladen.
was ist denn dann anders mit diesen funktionen ?

vielleicht kann mir jemand das ganze, für mich verständlich, erklären.

gruss
marianne

[Homer]

[quote=""ameise999""]hallo,

ehrlich gesagt verstehe ich die funktion nicht ops:
wenn ich den topf mit 0 starte, werden doch auch keine taps geladen.
was ist denn dann anders mit diesen funktionen ?

vielleicht kann mir jemand das ganze, für mich verständlich, erklären.

gruss
marianne[/quote]Hast du die von mir zitierten Posts nicht gelesen?

Viele Grüße
Homer

[BartW]

Vielen Dank, werde gleich testen.

[Töppi]

In der 1.0 ging das Laden wohl so schnell, dass man trotz drücken der Null den engen möglichen Zeitraum wohl nicht mehr traf. Daher diese neue Version. Elle meinte, dass er schon einige male versuche musste, um es erfolgreich zu treffen.

[mvordeme]

[quote=""ameise999""]vielleicht kann mir jemand das ganze, für mich verständlich, erklären. [/quote]

Ich versuch's mal. (keine Ahnung, wie viel Du bisher verstanden hast)

aXeL ist kein TAP, sondern ein verbesserter Loader für die Firmware. aXeL sorgt für ein schnelleres Starten des Topfs durch frühzeitiges Anwerfen der Festplatte und eine beschleunigte Dekompression der (komprimierten) Firmware. Leider ist aXeL so schnell, dass es praktisch unmöglich wird, den Topf ohne TAPs zu starten, weil man den Zeitpunkt zum Drücken der 0 verpasst. In der neuen Version wird jetzt beim Starten des Topfs über den Standby-Knopf am Gerät die Festplatte nicht frühzeitig angeworfen, so dass genügend Zeit bleibt, auf der Fernbedienung die 0 zu drücken. Das ist wichtig für TAP-Entwickler und -Tester, bei denen (fehlerhafte) TAPs häufiger mal den Topf lahm legen.

Hoffentlich hilft's.

Grüße,
-- mvordeme

[ameise999]

[quote=""mvordeme""]Ich versuch's mal. (keine Ahnung, wie viel Du bisher verstanden hast)

aXeL ist kein TAP, sondern ein verbesserter Loader für die Firmware. aXeL sorgt für ein schnelleres Starten des Topfs durch frühzeitiges Anwerfen der Festplatte und eine beschleunigte Dekompression der (komprimierten) Firmware. Leider ist aXeL so schnell, dass es praktisch unmöglich wird, den Topf ohne TAPs zu starten, weil man den Zeitpunkt zum Drücken der 0 verpasst. In der neuen Version wird jetzt beim Starten des Topfs über den Standby-Knopf am Gerät die Festplatte nicht frühzeitig angeworfen, so dass genügend Zeit bleibt, auf der Fernbedienung die 0 zu drücken. Das ist wichtig für TAP-Entwickler und -Tester, bei denen (fehlerhafte) TAPs häufiger mal den Topf lahm legen.

Hoffentlich hilft's.

Grüße,
-- mvordeme[/quote]

vielen dank für deine ausführung !!!
jetzt habe ich endlich verstanden

gruss
marianne