Closed mumbel closed 5 years ago
Do you have any thoughts on offset 0x68ee0 7e 77 bd a3.
It looks like some kind of checksum (automotive programmers loves checksums. This image have at least 5 functions to calculate CRC). At 8004005C
present reference to that place, also at 800672DE
some function does some strange things ;-)
DWARF helps so much with arguments
I am not familiar with tricore compilers. What is calling convention in your binaries? "My" code uses d2
as return value, but in most cases ghidra suggests, that functions return value in a2
.
Do you know, there are some ability to setup this behavior? It seems nessesary to add new prototype
section in .cspec file.
Do you know if this image has PCP?
I am never faced with PCP, but there is many references to their address space. I think that code, that i'm researching, fully executed by main core, and i am not very interesting in PCP disasm now.
Looking at adding the specific TC172x processor spec
Oh, its great! Thank you!
Returning a2 vs d2 is the same issue as passing arguments. The manual just says the data arguments are d# and pointer arguments are a#
The way I read that is:
size_t read(int fd, void * buf, size_t count)
would be d2 = read(d4, a4, d5)
and void * memcpy(void * dst, void * src, size_t n)
would be a2 = memcpy(a4, a5, d4)
And no clue how to best do that right now, and I may be completely wrong in my interpretation of the manual
@esaulenka Thanks again for the firmware.
Do you have any thoughts on offset 0x68ee0
7e 77 bd a3
.Hopefully its data, but as a decode:
80068ee0 7e 77 jne d15,d7,LAB_80068eee
followed bybd a3 91 10
which doesn't decode jumping to00 5d 7b 10
which doesn't decodeother things: