CSL '0401' Program Binary Disassembly Notes

[Bry5on]

Do you happen to have a build thread somewhere for the Jag? I would love to read it if it exists.

Really light on details of the Jag sadly.

Here's what it looks like (not much has changed in the past four years except for stable mates): https://youtu.be/UGBo-wUDK4g

And a few details here, although I wasn't as great about updates. Not having the details was part of what motivated me to make this wagon build thread: https://www.jaguarforums.com/forum/x...roject-184994/

[karter16]

In my other car.

Do you happen to have a build thread somewhere for the Jag? I would love to read it if it exists.

[karter16]

This is brilliant. I'm still working on absorbing your written description and browsing through your project simultaneously to make sense of how you arrived at it, but writing it out like that is extremely helpful.

Another dumb question, when building a project like this did you have to populate the memory map in Ghidra or is that done automatically based on selecting the 68k architecture? I'm assuming you did, based on the nomenclature used for the memory segments.

Nice one - yeah it takes a while to get the hang of how the program works as a whole and then it all starts to make more sense.

Yeah we had to populate the memory map manually. There's lots of different ways to configure the 68k memory so it was built out based on the work others have done in the past, referring to the Motorola documentation, etc. It's fairly crucial to get it right as the disassembler takes the memory map into account when disassembling (e.g. if you leave program ROM marked as writable you are in for a bad time with pointer references lol because the disassembler has to assume anything could change at any time.)

[R3VM3UP]

This is brilliant. I'm still working on absorbing your written description and browsing through your project simultaneously to make sense of how you arrived at it, but writing it out like that is extremely helpful.

Another dumb question, when building a project like this did you have to populate the memory map in Ghidra or is that done automatically based on selecting the 68k architecture? I'm assuming you did, based on the nomenclature used for the memory segments.

[karter16]

Amazing, thank you! The only things I've noticed are just clerical: Definitions for TAN and P_UMG don't exist on the page in the Input Variables section. You added a quick (Definition) for other variables that were referenced but don't show up directly in these functions

Thanks - great call out! Have amended :-)

[Bry5on]

Amazing, thank you! The only things I've noticed are just clerical: Definitions for TAN and P_UMG don't exist on the page in the Input Variables section. You added a quick (Definition) for other variables that were referenced but don't show up directly in these functions

[karter16]

I've also uploaded an archive ghidra project which contains all my latest work - it can be found here: https://github.com/karter16/CSL_0401...2025_03_09.gar It's a work in progress and I keep on wanting to tidy it up more before sharing but if I do that I'll never share it. You'll just need to put up with the fact that some of my comments will be out of date and the inconsistencies of work in progress. Let me know if you have any Q's.

Again my ask would be if you figure things out that you post them here as you go so that I can keep incorporating discoveries into the master disassembly project.

[karter16]

I've written up a wiki page here: https://github.com/karter16/CSL_0401...works#overview which describes in detail how the MAP sensor is used to calculate RF. It includes explanation, details of all variables and parameters along with a full code listing and code walkthrough of the functions that calculate RF and the integral controller component.

If anyone has the time I'd really appreciate it if you could have a read through and review - my intent is that this should be a complete explanation of how the MAP sensor is used. It would be great as well if you have questions about how specific values are obtained (e.g. "how do I know that xyz really does what you say it does?") then please point these out and I can do detailed listings of those things as well. It's a bit hard to figure out what the appropriate bounds of this are as you can go to the n'th degree with everything. Ideally I'd like the end result to be something that is so clear and comprehensive it leaves no remaining doubt that this is indeed the way the MAP sensor works.

Random screenshots of the wiki page to snazz up this post.


Screenshot from overview


Screenshot from function description of rf_calc()


Screenshot from code walkthrough of rf_calc()


Screenshot from code walkthrough of rf_p_kad_i_calc()

[R3VM3UP]

Ah okay, that's the part I was missing, I don't think I've ever seen those posted anywhere. I was only aware of the 52_V508.A2L file.

[karter16]

Is there a specific reason why you have higher confidence that the 1801 XDF is more accurate?

Yeah in the same way the original XDFs were built off an 0901 A2L there is also an 1801 A2L.

Not sure if an 1801 XDF actually exists btw, if it does it's probably one that was built off the original 0901 work.


Sent from my iPhone using Tapatalk

[R3VM3UP]

Is there a specific reason why you have higher confidence that the 1801 XDF is more accurate?

[karter16]

Sorry for the massive quote, and forgive my ignorance on some of this, but are you just doing this all manually or have you developed some sort of scripts to handle this? I get it that you've got a fairly complete XDF for the 1801 binary, are you just looking up how variables defined in the 1801 XDF are being used in the 1801 decompiled binary, and then checking to make sure that they are being used in the same way in the decompiled 0401 binary?

No worries - the translation from 1801 to 0401 was manual. Previous efforts were scripted and resulted in about a 1 in 5 error rate. Which comes down to the way BMW managed the codebase and the way the compiler reorders variable name to memory address assignments. Doing this manually, in this case, results in a much lower error rate and also captured where memory locations have been repurposed, etc.


Sent from my iPhone using Tapatalk

[R3VM3UP]

bmwfnatic and I have been making a lot of progress, and that's culminated this weekend in me having the time to map across characteristics (Parameters, Curves and Maps) as well as Global Variables from the 1801 master binary to the 0401 master (I'm still to do the slave binary).

We've managed to map 973 global variables which I've listed here: https://github.com/karter16/CSL_0401...#master-binary



As well as all the characteristics from 1801 (except for things which don't apply to the CSL like HFM). There were 5 characteristics in the 1801 master binary I wasn't able to identify, plus another 115 that are specific to the 0401 binary. These 120 characteristics which are still to be identified are listed here: https://github.com/karter16/CSL_0401...#master-binary



I should be able to work out what a bunch of these are, I'm just focused first on getting in all the characteristics, etc. to both the Master and Slave so we can update the archive to share with others.


Side note - I found it interesting as I was going through the master binary to see that the EGAS module has a separate EGAS_WDK table for when the CSL snorkel flap is open which has some subtle differences in both the interpolation point and the values around the 1200 RPM mark - others are probably already aware of this but I hadn't come across it before:

Sorry for the massive quote, and forgive my ignorance on some of this, but are you just doing this all manually or have you developed some sort of scripts to handle this? I get it that you've got a fairly complete XDF for the 1801 binary, are you just looking up how variables defined in the 1801 XDF are being used in the 1801 decompiled binary, and then checking to make sure that they are being used in the same way in the decompiled 0401 binary?

On a similar note, as you find stuff, are you just manually labeling variables you find in the decompiled binary?

[karter16]

Is the C decompiler part of the disassembly tool?

Yep - the screenshots I've shared of C code are generated by the decompiler. The variable names and stuff need to be done by hand, but not having to manually convert all the ASM to C equivalent saves a lot of time. The decompiler isn't perfect so you need validate its output sometimes, but overall an awesome tool.


Sent from my iPhone using Tapatalk

[ac427]

Absolutely - things like the C decompiler (although not infallible) are a game changer for quickly understanding what's going on, I can understand ASM but no where near as easily as C.


Sent from my iPhone using Tapatalk

Is the C decompiler part of the disassembly tool?