Für TAP-Entwickler: Start TAP

[Gerti]

Hi!

Macht es das auch, wenn Du den eigentlichen Aufruf ins IDLE verlegst?

Gruß,
Gerti

[Happy]

Macht es das auch, wenn Du den eigentlichen Aufruf ins IDLE verlegst?

Kann ich Dir kurz nach 9 sagen, nach der Aufnahme.

[Happy]

Im Idle stürzt es auch ab.

[Elle4u]

Oh, oh.

Da bin ich ja mal gespannt, wenn ich versuche es bei mir einzubauen (wird aber noch etwas dauern...)

[DeadBeef]

Sobald ich es aber umschreibe, damit dass TAP auf ein EVT_KEY hin gestartet werden soll, schmiert der Topf beim Aufruf, also beim Drücken der Taste, ab.

Ideen ?

Dann war ich doch zu optimistisch, was den Code-Wrapper angeht. Bei ersten Versuchen habe ich einen (bewährten) Code-Wrapper benutzt, aber der Topf stürzte trotzdem ab, weil das $gp Register nach der Rückkehr aus dem Wrapper nicht richtig gesetzt wurde ($gp = 0). Deswegen habe ich beschlossen, das $gp Register selbst zu sichern, was in TAP_Main offensichtlich funktioniert. Vielleicht werden die Register in den Assembleranweisungen anders zugewiesen, wenn der Code in einer anderen Umgebung eingebunden wird. Je nach Wahl des Registers kann dessen Inhalt bei Funktionsaufrufen überschriben werden.
Muß ich wohl weiter forschen ...

Ich komme momentan an den Topf nicht ran, aber Du könntest folgendes ausprobieren, falls Du Lust hast:

Code: Alles auswählen

[color=red][b]volatile[/b][/color] dword tapGp = 0;
...
  __asm__ __volatile__ ("or %0,$28,$00\n" [color=red][b]: "=r"(tapGp) :[ /b][/color] );

Das würde den TAP-Wert nicht nur im Register zwischenspeichern, sondern auch auf dem Stack.

[Happy]

Ich komme momentan an den Topf nicht ran, aber Du könntest folgendes ausprobieren, falls Du Lust hast:

Code: Alles auswählen

[color=red][b]volatile[/b][/color] dword tapGp = 0;
...
  __asm__ __volatile__ ("or %0,$28,$00\n" [color=red][b]: "=r"(tapGp) :[ /b][/color] );

Das würde den TAP-Wert nicht nur im Register zwischenspeichern, sondern auch auf dem Stack.

Ich habe die beiden Zeilen bei mir mal ersetzt, aber mit gleichem Ergebnis.

Gruß,
Happy

[DeadBeef]

DeadBeef,

Will this be added into your FW hooks page (or somewhere in your pages)?

I will add it later to the hooks page, once it is stable (there seem to be some issues).

[DeadBeef]

Ich habe die beiden Zeilen bei mir mal ersetzt, aber mit gleichem Ergebnis.

Gruß,
Happy

Könntest Du den Exceptiontext hier posten?

Eine weitere Theorie: möglicherweise hat die FW was dagegen, wenn in einem Event-Loop ein weiteres TAP angelegt wird, denn das ändert die TAP-Tabelle.

Was habe ich mir bloß dabei gedacht ...

[Happy]

Könntest Du den Exceptiontext hier posten?

Code: Alles auswählen

TAP_Main = 82A8896C
startTap = 8018A5C4
fwgp= 803926C8

$sp=803ac738
$at=00000000	$v0=00000000	$v1=803926c8	$a0=82a89728
$a1=82a89714	$a2=00000004	$a3=0000000f	$t0=801e7910
$t1=3c1c0000	$t2=00000000	$t3=803ac78c	$t4=82a11b20
$t5=00000000	$t6=803ac6ba	$t7=00000016	$t8=0000000d
$t9=8018b2c4	$s0=0001000c	$s1=00000000	$s2=0001000c
$s3=0000e300	$s4=8018b2c4	$s5=82a88800	$s6=00000005
$s7=82a897d0	$s8=803ac848	$ra=82a888cc	$t0=00000000
$t1=00000000	$gp=803926c8	$k1=82a88904

<<< Unexpected Exception >>>
CAUSE   = 00008408
  EPC = 82a88904
 *EPC   = 8c420000
   SR   = 10000403
badVAddr = 00000000
 task = 0
_runCount=1
lastTask(0) = 0
memory monitor
cmd number = 10

>

Gruß,
Happy

[DeadBeef]

Code: Alles auswählen

TAP_Main = [color=blue]82A8896C[/color]
startTap = 8018A5C4
fwgp= [color=red]803926C8[/color]
...
$t1=00000000    $gp=[color=red]803926c8[/color]    $k1=82a88904
...
  EPC = [color=blue]82a88904[/color]
 *EPC   = 8c420000

Es sieht so aus, daß die startTap-Funktion zurückgekehrt ist, aber der Inhalt von $gp immer noch den $gp Wert der Firmware hat.

PS: Der $gp Wert entspricht nicht der FW in Deiner Signatur.

[Happy]

PS: Der $gp Wert entspricht nicht der FW in Deiner Signatur.

st: st:

[DeadBeef]

Sobald ich es aber umschreibe, damit dass TAP auf ein EVT_KEY hin gestartet werden soll, schmiert der Topf beim Aufruf, also beim Drücken der Taste, ab.

Ich kann es nicht nachvollziehen - kein Absturz. Dafür wird bei mir das zu startende TAP nicht ausgeführt, wenn die Funktion aus dem Event-Handler aufgerufen wird.
Mir ist dabei eine andere unschöne Sache aufgefallen: ich bin mir nicht sicher, ob TAP_Hdd_ChangeDir auch das Arbeitsverzeichnis der FW verändert. Denn wenn nicht, muß das zu startende TAP in dem Arbeitsverzeichnis der FW und nicht dem des TAPs sein.

[DeadBeef]

Ich habe ein bisschen experimentiert und folgendes ist dabei rausgekommen.

1. Die Firmware arbeitet tatsächlich in einem anderen Verzeichnis als alle TAPs und zwar in DataFiles. Es wäre echt unpraktisch die zu startenden TAPs dort abzulegen, solange man keinen Weg hat das Arbeitsverzeichnis der FW zu ändern.
2. Absolute Pfade werden von der startTap() Funktion nicht akzeptiert.
3. Folgender Code kann auf meinem Topf sowohl in TAP_Main als auch in TAP_EventHandler aufgerufen werden und funktioniert ohne Probleme:

Code: Alles auswählen

 
void doIt()
{
  volatile dword tapGp = 0;
  dword fwGp = getFwGp();
  // retrieve the address of the start TAP function, it is usually located in 
  // the second megabyte of the firmware
  StartTap startTap = (StartTap)findStartTapFunction((dword*)0x80100000, 0x100000);
  TAP_Print("startTap = %p\n", startTap);
  TAP_Print("starting TAP ...\n");
  if((startTap == NULL) || (fwGp == 0))
  {
    TAP_Print("initialization failed\n");
    return;
  }
  // make sure the current working directory is ProgramFiles
  changeDirectory();
  // Instead of using a code wrapper just save the value of the $gp register
  // and provide the firmware specific $gp value.
  __asm__ __volatile__ ("or %0,$28,$00\n" : "=r"(tapGp) : );
  __asm__ __volatile__ ("or $28,%0,$00\n" : : "r"(fwGp));
  startTap("test.tap");
  // restore the TAP value of $gp
  __asm__ __volatile__ ("or $28,%0,$00\n" : : "r"(tapGp));
 
  TAP_Print("done\n");
}

[Happy]

3. Folgender Code kann auf meinem Topf sowohl in TAP_Main als auch in TAP_EventHandler aufgerufen werden und funktioniert ohne Probleme:

Hallo,
so gehts jetzt bei mir auch , wenn das TAP in DataFiles liegt.
Einziger Unterschied zu meinem letzten Versuch gestern:
Ich hatte

Code: Alles auswählen

StartTap startTap = NULL

global definiert und im Main die Zuweisung

Code: Alles auswählen

startTap  = (StartTap)findStartTapFunction((dword*)0x80100000, 0x100000);

Dann gibts beim Aufruf den Absturz.

Gruß,
Happy

[DeadBeef]

Ich hatte

Code: Alles auswählen

StartTap startTap = NULL

global definiert und im Main die Zuweisung

Code: Alles auswählen

startTap  = (StartTap)findStartTapFunction((dword*)0x80100000, 0x100000);

Dann gibts beim Aufruf den Absturz.

Globale Zeiger sind am Übergang in den FW-Kontext nicht gut, weil der Compiler sie meistens über $gp referenziert. Wenn ich mich nicht irre, sollte eine lokale Kopie des globalen Zeigers das Problem lösen. Mit Präfix "volatile" sollte es auf jeden Fall klappen.

Nun muß ich versuchen, das FW-Arbeitsverzeichnis temporär zu "verbiegen".

[Elle4u]

Da ich gar nicht verstehe von was ihr da genau redet, wäre es nett wenn ihr mir die funktionierende Libary am Ende zukommen lassen könntet .


Danke!

[Happy]

Globale Zeiger sind am Übergang in den FW-Kontext nicht gut, weil der Compiler sie meistens über $gp referenziert. Wenn ich mich nicht irre, sollte eine lokale Kopie des globalen Zeigers das Problem lösen. Mit Präfix "volatile" sollte es auf jeden Fall klappen.

Habe beides probiert, die globale Variable volatile zu deklarieren, reicht nicht. Aber mit der lokalen Kopie klappt es.

Nun muß ich versuchen, das FW-Arbeitsverzeichnis temporär zu "verbiegen".

Viel Erfolg.

Gruß,
Happy

[DeadBeef]

Habe beides probiert, die globale Variable volatile zu deklarieren, reicht nicht. Aber mit der lokalen Kopie klappt es.

Ich meinte eher die lokale Kopie mit volatile zu versehen, damit es auch bei eingeschalteter Optimierung klappt. Aber die uns vorliegende Compiler-Version optimiert sowieso nicht.

[Elle4u]

Mal ne Frage ops: :

Seit ihr hier schon irgendwie weiter gekommen???
Funktioniert der TAP-Start nun?

[Harvey]

exTAP verbiegt vor dem Aufruf von tap_start einen Pointer.

Ich bin ziemlich sicher, daß dort in wie auch immer kodierter Form (sind ziemlich tief verschachtelte Unterfunktionen) das Arbeitsverzeichnis drin steckt.

Für die aktuelle Release des TF5x00PVR wäre das

dword *fw_tap_load_data0;
dword *fw_tap_load_data1;
dword *fw_tap_load_data2;

fw_tap_load_data0 = (dword *)0x8038122c; // -25604($gp)
fw_tap_load_data1 = (dword *)0x8037fb38; // -31480($gp)
fw_tap_load_data2 = (dword *)0x8037fb28; // -31496($gp)

*fw_tap_load_data0 = *fw_tap_load_data1;
doit();
*fw_tap_load_data0 = *fw_tap_load_data2;

In der Firmware finde ich das anders, dort wird *fw_tap_load_data0 häufig gesichert (0x80146678), übeschrieben und später wieder zurückgesichert (0x80146684).