Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Possible bad instruction decode #6

Closed
mumbel opened this issue Jun 1, 2019 · 2 comments
Closed

Possible bad instruction decode #6

mumbel opened this issue Jun 1, 2019 · 2 comments
Labels
bug Something isn't working

Comments

@mumbel
Copy link
Owner

mumbel commented Jun 1, 2019

@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 by bd a3 91 10 which doesn't decode
jumping to 00 5d 7b 10 which doesn't decode

other things:

  • I've only been using ELF so far, so this definitely is useful to look at. DWARF helps so much with arguments, and I know my implementation is lacking, not sure how to handle it.
  • Do you know if this image has PCP? I'll hopefully be adding PCP soon (looking to use the same approach as ARM/THUMB)
  • Looking at adding the specific TC172x processor spec with at least memory mappings, still figuring out labels with-in the mappings
@mumbel mumbel added the bug Something isn't working label Jun 1, 2019
@esaulenka
Copy link

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!

@mumbel
Copy link
Owner Author

mumbel commented Jun 4, 2019

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

@mumbel mumbel closed this as completed Jun 11, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants