[Tiptoi] Mehr zu OidMain

[Björn]

[2. Versuch ...]

Guten Abend, Matthias!

Da wir das Prinzip der GME-Binaries noch nicht verstanden haben, denke 
ich, dass es einfacher wäre, erstmal das normale Hauptprogram der 
Firmware (PROG) zu patchen.

Wie es aussieht, rufen in diesem diverse Routinen eine 
Dummy-UART-Ausgabe auf, welche leer ist.
Wenn es nun gelänge deine Routine im Speicher unterzubringen und die 
Aufrufe umzubiegen, sollten wir diverse Debug-/Tracing-Outputs sehen können.

Schönen Abend,
Björn



Am 27.11.2020 um 21:48 schrieb Matthias Weber via tiptoi:
> Guten Abend!
> 
> Können wir die Binaries hinten raus bzw. allgemein noch vergrößern?
> 
> Was wären denn die notwendigen Schritte dafür?
> 
> Ich würde gerne folgende Funktion anspringen können (von beliebiger
> Stelle) und damit über den UART die aktuellen Prozessor-Register
> ausgeben. Bisher nur eine Idee!
> 
> Man könnte eine beliebige Instruktion duch einen Sprung zu dieser
> Funktion ersetzen. Dann ggf. noch die ersetzte Instruktion vor den
> Prolog setzen.
> 
> Der Gedanke ist, dass die Funktion dann erstmal alle Register auf dem
> Stack sichert, und dann über UART 'reg r15:' und den Inhalt von r15 als
> 32 bit Hexadezimalzahl ausgibt. Dabei wird "nur" Stack verwendet und
> 'reg<SP>r\0\0\0' wird als nullterminierter String auf dem Stack abgelegt?
> 
> Und danach sollte alles wiederhergestellt werden...
> 
> Handgeschrieben, nicht getestet:
>> push {r0, r1, r2, ..., r13, r14, r15}
>>
>> mov r4, sp
>>
>> mov r0, #0x72000000
>> push {r0}
>> orr r0, #0x00650000
>> orr r0, #0x00006700
>> orr r0, #0x00000020
>> push {r0}
>>
>> bl _bootrom_uart_init
>>
>> mov r0, sp
>> bl _bootrom_uart_puts
>>
>> mov r0, #49
>> bl _bootrom_uart_putc
>>
>> mov r0, #53
>> bl _bootrom_uart_putc
>>
>> mov r0, #58
>> bl _bootrom_uart_putc
>>
>> mov r0, r4
>> bl bootrom_uart_put_num2hex
>>
>> mov r0, #10
>> bl _bootrom_uart_putc
>>
>> ...
>>
>> pop {r0}
>> pop {r0}
>> pop {r0, r1, r2, ..., r13, r14, r15}
> 
> Kann das vom Prinzip her klappen?
> 
> Gruß
> Matthias
>