C development and patching for P01/P59
C development and patching for P01/P59
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
Please don't PM me with technical questions - start a thread instead, and send me a link to it. That way I can answer in public, and help other people who have the same question. Thanks!
- antus
- Site Admin
- Posts: 8258
- Joined: Sat Feb 28, 2009 8:34 pm
- cars: TX Gemini 2L Twincam
TX Gemini SR20 18psi
Datsun 1200 Ute
Subaru Blitzen '06 EZ30 4th gen, 3.0R Spec B - Contact:
Re: C development and patching for P01/P59
I think we should use the same toolset as we use for the flash kernels, with a similar/same build system. objcopy will convert to srecord, or we could update the tooling to use bins.
It might be possible to emulate in easy68k but I think it would mean compiling c to asm, and getting that asm in to easy68k (not sure if compatible? or if it can run executable payloads straight up)? http://www.easy68k.com/QuickStart/LoadPageFrames.htm
The site index is down, but additionally the code is on github. https://github.com/ProfKelly/EASy68K
It wouldnt be able emulate the whole OS but you could essentially unit test a function or a couple of functions.
It might be possible to emulate in easy68k but I think it would mean compiling c to asm, and getting that asm in to easy68k (not sure if compatible? or if it can run executable payloads straight up)? http://www.easy68k.com/QuickStart/LoadPageFrames.htm
The site index is down, but additionally the code is on github. https://github.com/ProfKelly/EASy68K
It wouldnt be able emulate the whole OS but you could essentially unit test a function or a couple of functions.
Have you read the FAQ? For lots of information and links to significant threads see here: http://pcmhacking.net/forums/viewtopic.php?f=7&t=1396
Re: C development and patching for P01/P59
Oh right, we have a compiler.
Parts of the easy68k site still work:
http://www.easy68k.com/features.htm
The binaries are on github:
https://github.com/ProfKelly/EASy68K
It says the emulator supports srecord files, so I'm guessing it will be possible to load and step through srecord files generated by the compiler.
Parts of the easy68k site still work:
http://www.easy68k.com/features.htm
The binaries are on github:
https://github.com/ProfKelly/EASy68K
It says the emulator supports srecord files, so I'm guessing it will be possible to load and step through srecord files generated by the compiler.
Please don't PM me with technical questions - start a thread instead, and send me a link to it. That way I can answer in public, and help other people who have the same question. Thanks!
Re: C development and patching for P01/P59
I may be mistaken for I am no expert, however I do believe the GNU m68k toolchain used for the kernels is incompatible with Easy68k ...
Yes, the GNU m68k toolchain does output S-Records.
[edit]
After further investigation, it appears GNU m68k Style is configurable, maybe there is a compatible style.
Yes, the GNU m68k toolchain does output S-Records.
[edit]
After further investigation, it appears GNU m68k Style is configurable, maybe there is a compatible style.
Intelligence is in the details!
It is easier not to learn bad habits, then it is to break them!
If I was here to win a popularity contest, their would be no point, so I wouldn't be here!
It is easier not to learn bad habits, then it is to break them!
If I was here to win a popularity contest, their would be no point, so I wouldn't be here!
Re: C development and patching for P01/P59
I would like to help with this but I don't think I know enough to really help.
I will force myself to learn C once this us up and running. Writing a simple spark launch control in ASM was terrible and took forever.
I'd like to program a PID launch control routine, but don't even want to think about doing it without a higher level language.
I will force myself to learn C once this us up and running. Writing a simple spark launch control in ASM was terrible and took forever.
I'd like to program a PID launch control routine, but don't even want to think about doing it without a higher level language.
LS1 Boost OS V3 Here. For feature suggestions post in here Development Thread. Support future development ->Patreon.
Re: C development and patching for P01/P59
What we need to do is get m68k added to Compiler Explorer, that would make it oh so easy to code patches.
Intelligence is in the details!
It is easier not to learn bad habits, then it is to break them!
If I was here to win a popularity contest, their would be no point, so I wouldn't be here!
It is easier not to learn bad habits, then it is to break them!
If I was here to win a popularity contest, their would be no point, so I wouldn't be here!
Re: C development and patching for P01/P59
Would anyone be able to help point me in the right direction as to how to get this setup?
I have some ideas that I would like to implement into custom code, but I really won't be able to do it without a higher level language.
Thanks!
I have some ideas that I would like to implement into custom code, but I really won't be able to do it without a higher level language.
Thanks!
LS1 Boost OS V3 Here. For feature suggestions post in here Development Thread. Support future development ->Patreon.
Re: C development and patching for P01/P59
Not sure what you are looking for, gnu has the -S option that stops prior to the assembler leaving the assembly available for review/modification.
I think you are going to find that it bloats the ASM more then you like starting with a higher language, however I find it useful for testing code bits and learning ...
-Enjoy
I think you are going to find that it bloats the ASM more then you like starting with a higher language, however I find it useful for testing code bits and learning ...
-Enjoy
Intelligence is in the details!
It is easier not to learn bad habits, then it is to break them!
If I was here to win a popularity contest, their would be no point, so I wouldn't be here!
It is easier not to learn bad habits, then it is to break them!
If I was here to win a popularity contest, their would be no point, so I wouldn't be here!
Re: C development and patching for P01/P59
Exactly this, I have been using it for the E40 stuff which has been great for:NSFW wrote:Oh right, we have a compiler.
Parts of the easy68k site still work:
http://www.easy68k.com/features.htm
The binaries are on github:
https://github.com/ProfKelly/EASy68K
It says the emulator supports srecord files, so I'm guessing it will be possible to load and step through srecord files generated by the compiler.
a) Generate new assembly code for complex C coding (CRCs ect)
b) stepping through code to see registry changes
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Re: C development and patching for P01/P59
I have to say that all pretty much goes over my head.
Looked into it a little more...you use C++Builder with easy68k to compile C++ into S-Record Files?
I'll have to do some more research.
Looked into it a little more...you use C++Builder with easy68k to compile C++ into S-Record Files?
I'll have to do some more research.
LS1 Boost OS V3 Here. For feature suggestions post in here Development Thread. Support future development ->Patreon.