C development and patching for P01/P59
Posted: Wed Sep 30, 2020 3:14 pm
This thread was inspired by bubba2533's thoughts on using C rather than assembly for hacking on P59 firmware.
viewtopic.php?f=42&t=6247&p=102624
Programming in C is indeed easier.
The catch is that in order to develop patches in C we'll need a tool that copies the machine code from the C compiler into unused ROM, and ovewrites the target addresses of the jump instructions that you're hijacking to call your code. I wrote such a tool for Subaru hacking years ago that could probably work for P01/P59 if we have a 68332 compiler that produces Motorola S-record output. It's not the most elegant approach but it was pretty easy to implement and it has some features that I like.
The code:
https://github.com/LegacyNsfw/RomPatch
Instructions for end users:
http://www.romraider.com/forum/viewtopi ... =32&t=7892
Things I like about this design:
- The source code contains the data that the patch utility needs.
- So, instead of copying an address from the compiler output into a metadata file, you can just put the function name into the metadata file and the tools take care of the rest.
- The patch (assembly code) and the metadata (which data to put where) get built into a single file, so you don't have to maintain the patch metadata separately from a patch bin file.
This is what I mean by metadata:
https://github.com/LegacyNsfw/EcuHacks/ ... Metadata.s
As a developer, the workflow looks like:
1. compile and link the C code with some extra options that tell them to generate an Srecord file, and how to handle the metadata
2. run the patch tool with an option that tells it to copy the patch and metadata into a new Srecord file.
3. Done.
End users can then run the patch tool with their bin file and an Srecord file, and it will take care of the rest.
To make this work for GM PCMs, we'll need a compiler that can produce 68332 / CPU32 code, and some experimenting to get it to produce the Srecord output that the path tool needs.
This is the C project that contains my Subaru stuff:
https://github.com/LegacyNsfw/EcuHacks
And this is a related thread about the development tools I was using for Subaru stuff. I wish I knew of a GUI debugger like this for 68332 development, it made Subaru hacking easier that I ever imagined. Or maybe "easier" is the wrong word but it was much less hard than I imagined. But anyway, it has some context about the patch tool and the C project:
http://www.romraider.com/forum/viewtopi ... =40&t=7680
viewtopic.php?f=42&t=6247&p=102624
Programming in C is indeed easier.
The catch is that in order to develop patches in C we'll need a tool that copies the machine code from the C compiler into unused ROM, and ovewrites the target addresses of the jump instructions that you're hijacking to call your code. I wrote such a tool for Subaru hacking years ago that could probably work for P01/P59 if we have a 68332 compiler that produces Motorola S-record output. It's not the most elegant approach but it was pretty easy to implement and it has some features that I like.
The code:
https://github.com/LegacyNsfw/RomPatch
Instructions for end users:
http://www.romraider.com/forum/viewtopi ... =32&t=7892
Things I like about this design:
- The source code contains the data that the patch utility needs.
- So, instead of copying an address from the compiler output into a metadata file, you can just put the function name into the metadata file and the tools take care of the rest.
- The patch (assembly code) and the metadata (which data to put where) get built into a single file, so you don't have to maintain the patch metadata separately from a patch bin file.
This is what I mean by metadata:
https://github.com/LegacyNsfw/EcuHacks/ ... Metadata.s
As a developer, the workflow looks like:
1. compile and link the C code with some extra options that tell them to generate an Srecord file, and how to handle the metadata
2. run the patch tool with an option that tells it to copy the patch and metadata into a new Srecord file.
3. Done.
End users can then run the patch tool with their bin file and an Srecord file, and it will take care of the rest.
To make this work for GM PCMs, we'll need a compiler that can produce 68332 / CPU32 code, and some experimenting to get it to produce the Srecord output that the path tool needs.
This is the C project that contains my Subaru stuff:
https://github.com/LegacyNsfw/EcuHacks
And this is a related thread about the development tools I was using for Subaru stuff. I wish I knew of a GUI debugger like this for 68332 development, it made Subaru hacking easier that I ever imagined. Or maybe "easier" is the wrong word but it was much less hard than I imagined. But anyway, it has some context about the patch tool and the C project:
http://www.romraider.com/forum/viewtopi ... =40&t=7680