I'm starting work for a 5120 hack for my RS6.
There's nothing new in what I'm going to do, but I'll try to document the process, maybe it'll be of use to someone.

Most of the work will be based on this A2L posted a while ago. Offsets are generally WAY off from my SW version, but amount and "distribution" of maps through the bin seems to be similar. Also, there's an XLS file by sweegie that can help cross-reference map locations.

There's also an XDF posted in that thread, but we'll get to it later.


Anyways, I started by searching for "hPa" in compu_methods.
Found the following 20 methods:

compu_method	unit	variable	map
adb_uw_q0p00195	hPa/V		DSTGRAD
dgrad_uw_q0p015	hPa/V		DSLGRAD, DSUGRAD
fak1_q1p63Em5	[g*K]/hPa		KMLTESG
fak_q0p015625	hPa/(g*s)		KFBALB
grd_sw_q0p78	hPa/s	grdpssf_w, grdpssol_w	PSSOLNGRD, PSSOLPF, PSSOLPGRD
pgrad_q0p039	hPa/s	dpbkvep_w, dpbkvps_w, dpbkvsp_w
pgrad_q0p15625	hPa/s	dmnpbkv_w, dmxpbkv_w
p_sb_q0p25	hPa	pte	FQTEPT
p_sb_q0p625	hPa	pterw
p_sb_q10	hPa	lde	DLUL, EDLDRP, ELDOB, LDEIAO, LDEIAP, LDEIAPS, LDEIAU, UMDYLDR, KFLDRQ0/1/2
p_sw_q0p000977	hPa	pte_w	KLTDS
p_sw_q0p00244	hPa	pterw_w	KLTDS
p_sw_q0p039	hPa	dpbkvae_w, dpsdvs_w, dpsfg_w, dpsmp_w	DPBKVLE, DPSPBKVNPH, DPSPUBKVH, DSBOFS, DSLOFS, DSUOFS, OPBKVUKKB, OPBKVUKNKH, OPBKVUKNWB, OPBKVUKPB, OPBKVUKPUB
p_sw_q0p078	hPa	dpus_w	FRLFSDP
p_ub_q10	hPa	dpspu, pdpld, plsol, psmxbkvg, pvdk, pvdkds, pvdkspud	DPUPS, LDPBN, MSNPCV, PVDKPUD, KFDLULS, KFTVLDRE
p_ub_q5	hPa	pbkv, pu	DPBKVUS, DPSLV, NDLDRAPU, NLDIAPU, KFANFPU, KFDLULS, KFLDIOPU
p_uw_b32	hPa/%	fvisrm_w
p_uw_q0p039	hPa	see below
p_uw_q0p078	hpa		DPUFVMN, DPUFVSMN
rel_uw_b0p3	%/hPa	fupsrl_w, psrlro_w	KFURL

The most interesting one is p_uw_q0p039, which is referenced by a whole bunch of variables and maps:

vars: dpbkvpa_w, dpbkvppa_w, dpbkvu_w, dpbkvuk_w, dpbkvukb_w, dpbkvukh_w, dpbkvukk_w, dpbkvukp_w, dpbkvukr_w, dpbkvunw_w, dpbukk_w, dpbukkb_w, dpbuknkh_w, dpbuknw_w, dpbuknwb_w, dpbukp_w, dpbukpb_w, dpbunkhb_w, dpdk_w, dpspvdkd_w, dpu_w, dpvdkspu_w, pbkv_w, pbkva_w, pbkvel_w, pbkvmod_w, pbkvp_w, pbkvpaus_w, pbkvpdf_w, pbkvpmn_w, pbkvprd_w, pbr_w, pbrint_w, pdpld_w, pirg_w, pirgro_w, plgru_w, plgruo_w, plgrus_w, plgruso_w, plmaxa_w, plsol_w, plsolr_w, ps_w, psbkv_w, psfg_w, psfil_w, psmp_w, psmx_w, psmxbkvg_w, psp_w, pspmx_w, pssol_w, psspbkv_w, pu_w, pubkv_w, pukor_w, pukorf_w, pumean_w, pumem_w, pus_w, pvdk_w, pvdkds_w, pvdkdsl_w, pvdkdsu_w, pvdkmx_w, pvdkr_w, pvdks_w, pvdksf_w.
maps: DIFFMAX, DLDUVES, DPBKVPMN, DPBKVRPD, DPBKVSPS, DPDSVLU, DPSBKV, DPSSPBKVPB, DPUBABMX, DPUBKV, DPUFFMN, DPUFFMX, HSLDSUA, LDUVRS, PBKBKREHY, PBKVKRHY, PBKVMN, PBKVMX, PLSOLAP, PSAPES, PUE, PUEBKV, PUMN, PUMX, PUSMAX, PUSMIN, PUSPSMX, PVDKMN, PVDKPSMX, DPBKVPPBKV, DPBKVUKKPU, DPBKVUKNKH, DPBKVUKNW, DPBKVUKP, DPBKVUKPU, DPUPVDK, FMDPUBKV, KLDPDK, PBKVVSTGPV, PUKORRV, PVDKMX, KFDPLGU, KFFLTA, KFGLTA, KFLDIMX, KFPLGUB, KFPRG, KFSDLDSUA, KFTXFTA, KFXFTA.

I may have missed it, but what binary are you using? Some of these RS6 files have Tuner Protection and will encounter limp mode after a few days. I'd start with a version that does not have this issue.

You know that. I know that.

The OP may not have known that, or be capable of it.

That, and it's easier to find something when you know it exists.

Answering questions first:
My bin revision is 366304. As far as I can tell, tprot is disabled in it.
Wish I had the matching bin for that A2L though.

There's not much to report currently, work on this project has been going pretty slowly, and I still don't have some of the required consts/maps defined in my ols. LDUVRS and HSLDSUA have been pretty elusive and values at the "assumed location" for the whole bunch of other consts (DPUFVMN, DPUFVSMN, DPUPS, EDLDRP, PUKORRV, PSSOLNGRD, PSSOLPF, PSSOLPGRD) don't line up with other documented bins. (Note: I'm not talking about A2L locations, which I know are wrong for the bin). I guess IDA will help find them.

Oh, by the way, I'm also using this awesome RS4 K-box project for cross-referencing stuff. Also used the IDA project from there to start digging in the code itself.

Anyway, re-visiting "first steps" in disassembly and it turns out to be easier than I had recalled. Basic idea is to load the bin into IDA at correct offsets, this is crucial to get proper references to RAM/ROM variables. The whole memory structure of ME7.x is well documented on this website already, the thread with autoit scripts for loading binaries was quite useful. I'm using IDA 6.4, so had to mod them a bit, but the basic idea is:

• choose the correct CPU architecture (C166)
• load BIN to the 0x800000 offset
• create IRAM segment at 0xE000-0x10000
• create RAM segment at 0x38000-0x39000
• set DPPs (I didn't bother figuring out the "proper" ones, just used the default from the script (204h, 205h, E0h, 3)

I also copied first 32K of the bin to be used as "CPU" code, but I'm not sure that's necessary (or even correct).
But this was enough to get me started on the disassembly, most of the code seemed out to "convert" correctly. I didn't fix the "import *.ecu" function initially and just went over the vars manually to get a better understanding of what is happening inside.

Now, how do you start when there's a bunch of weird code and nothing seems to be clear? It's actually pretty easy: you take one known variable (name and location) from the .ecu file generated by the ME7Logger and simply search the "IDA view" of the code for references to it. E.g. for my binary we take "ps_w" and it has offset of "0xF96E", therefore we search for "word_F96E" in IDA and rename it to "ps_w". (Note: 8 bit vars will be "byte_", not "word_". Actually it's easier to just search for the offset itself and then verify the dimension.) Some of the constants (1x1 maps) from the BIN will be referenced the same way. So we can search for the "PSAPES" as "word_81F280", for example. (Note: don't forget to add the 0x800000 to the offset for those, since that's how the BIN is seen by CPU).

So, yeah, to go this way you need some "basic preliminary knowledge" of the binary. *.ECU files, public XDF, KP, A2L and so on might be of use. I won't go into details here, it shouldn't be too hard for you if you got to this point anyway.

When you've renamed some of the vars/consts, you will start to get a basic vision of what is going on in the code. Knowing basic ASM commands will surely help. The next tool that will help you is funktionsrahmen document. Basically, you search it for some variable name and try to find the fitting diagram for your code segment. It can help figure out what's actually happening there. This will let you name other vars that were unknown to you. And this way you "expand" understanding of the function that interests you. You can also "cross-reference" code from other binaries, since functions mostly look the same - it's data offsets that differ.

I guess, that's the basic process to get you started. It's pretty slow, tedious and takes A LOT of patience and time.

Anyway, I hope this will help someone. Don't be scared of the disassembly as I was, it's pretty much the same pattern finding and matching as "x-reffing" your bin to the other documented one by other means.
Hopefully I will have more solid results to post next time.

Yeah, of course! I only did it manually because I wanted to look through code "step by step" myself. Won't repeat it in the next bin I go through.

Following...

I'm not yet as 'super disassembler' as many on here, so it is cool to follow someone who is taking the time to fully document their modifications. Especially when it is on a platform that is relevant to my interests

Heya! Not sure what you mean by that question. My bin revision is 366304, and maps for now are modified by some local guy, - but I'll probably just start from scratch once I figure (and accordingly test) everything. Should be fully capable of that by now.


I might be wrong, but there's no matching bin for that A2L I posted. Couldn't find anything else for the RS6. Do you mind sharing damos/bin if you have one? Thanks.


Anyway, back on track. IDA turned out to be a blast! Digging through code is actually pretty fun!

I needed a "reference point" to compare stuff to. Tried that RS4 project I mentioned earlier, but it's rather incomplete. So, I started digging around and found that there's plenty of info for 4Z7907551R: bin, ols, csv mappack and especially "tasty" one - ram variables file! I can't find URLs, since I downloaded them from my home PC, but I'm on my laptop now. I will edit the post later, adding them. FIXED
These allowed me to build a very good reference file. I later used CB-box as well, there's quite a bit of info for that too.

What I did:
Automatically parsed all the byte and word "1x1 map" constants into IDA. Also took some time to parse the .ecu file, adding RAM vars. Later I also added "flag" vars, check this post.

Aaaand after that I went on looking through code trying to find similarities, looking for "pressure related" RAM vars.
Here's the stuff I found (again, RS6 366304):

not that sure about these:   

And a bunch of extras:

This should allow me to properly log what's happening in Motronic, how pressure-related vars "go through" functions. List is incomplete, but I'm slowly getting there.

Then I also searched for addresses containing 4D65h (some should be halved) and 8702h (doubled) and noted offsets that contain according code (and are not just some random data). Actually cheating a bit here - looked those up ("asm divisions") from M-box differences.

Then I went through all the according maps/consts with hPa axes and confirmed their offset for my bin, creating proper OLS mappack. I also found an extra hPa map, which is KFLDIAPL at 28748h (do not blindly trust A2L if it's not for your exact bin revision!) Couldn't find anything related to *bkv, though. I presume it's just not present in my bin since my car has just the "suction jet pump" and purely mechanical brake booster, without any electronic gizmos, so this shouldn't get too messed up.

So, at this point I pretty much have everything prepared and ready for first iteration of "5120 test".
There's some VERY weird stuff with some of the maps (namely: PSSOLPF and PSSOLPGRD. PUKORRV also looks funny), I guess I'll have to look closely for some memory vars, "served" by those.

Buuuuut, the funny thing is that I actually grew so fond of digging through code that I got carried away and started figuring out (or, rather, confirming) differences between S6 MT and S6 AT bins to properly finish my MT tune - and never actually got to testing the 5120. I will definitely get to it at some point, though.