bubba2533 wrote:I have to patch multiple locations (New Code + Hooks) that are not continuous with each other. I don't see anything in what you sent me that does that.
I could just combine it all into a bin file, but then there is no info that tells me what goes where. Again I am trying to not have to do this manually.
It looks like NSFW is doing what I want. Or at least similar, but it's done with C and it's a totally different build system so I don't know if it's worth learning.
You're facing the same set of problems that I faced when I wanted to stitch my stuff in Subaru .bin files. I don't feel strongly about whether you re-use my stuff but I think it's worth learning how it works, so that you can make an informed decision about whether to re-use it or create something else that solves the same problems. What I did isn't necessarily the best way to do it. It's more like the bare minimum I felt could get away with.
srec is a nice output format because it provides address information for all of your code and data. I like having a standard build process produce a single file that includes the code (and where to put it), and the data (and where to put it) and also a "metadata" section that tells my RomPatch tool what steps to take to insert the hooks into the original .bin file.
To make sure the compiler would put my code and data in the address ranges that I wanted to use, I decorated the functions and data with stuff like this:
Code: Select all
void RevLimiterCode(void) __attribute__ ((section ("RomHole_RevLimiterCode")));
void RevLimiterCode()
{
...
I'm sure that a similar decoration exists for asm code, but I don't know what it is.
After the code is compiled, the linker decides what address to put it at, and it uses "sections" for that. RomHole_RevLimiterCode is the name of a section, and there is a corresponding linker setting that tells the linker what address range to use for that section. And all of the functions that do rev-limiter stuff (launch control, flat-foot-shifting) go into that section.
The RomPatch tool reads the srec file into a collection of "blobs." Some of the blobs are treated as code and data to copy into the bin file. Some of the blobs are basically instructions to the patch tool. One of them tells RomPatch to compare the calibration ID of the bin file with the calibration ID in the srec file, so that people won't screw up their 2005 bin file with a patch for a 2008 ("calibration ID" for these Subarus is basically equivalent to "operating system ID" in the GM world, because Subaru had a different OS for almost every calibration). Some of the srec blobs tell RomPatch to replace target addresses of jump-to-subroutine instructions in the original code with the addresses of new code.
My workflow was:
1) compile and link the C code
2) RomPatch baseline patch.srec factory.bin
3) RomPatch apply patch.srec mycar.bin
The "baseline" step in that process looks at a factory bin file and the addresses that the srec file would overwrite, and it adds the factory data to the srec file. Then, in the "apply" step, it before making any changes, RomPatch compares the baseline data in the srec file with the actual data in the bin file. That should prevent people from applying the wrong patches to the wrong bin files.
One more bit of context / advice:
GM puts all of the tuning parameters together in a single calibration segment. In Subaru's bin files, the tuning parameters are tightly interleaved with the code - there's no calibration segment. Most of the big tables are grouped together, but all of the parameters are just spread all over the place, near the code that needs them.
In my patches, I did something in between, where the parameters for a particular feature were combined together, and the mini-calibration segments and code segments have some empty space between them. That way I could edit code and add/remove/repurpose things in each of those mini-calibration-segments without affecting the addresses of parameters in other mini-calibration-segments. That let me spend less time updating XML files after making changes to the code. For example, I could add a new parameter for flat-foot-shifting and all of the rev-matching parameters would stay at the same addresses.