NefMoto

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 (http://nefariousmotorsports.com/forum/index.php?topic=116.msg3543#msg3543) 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 (http://nefariousmotorsports.com/forum/index.php?topic=2630.msg24927#msg24927) 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.

Next step was to combine all maps into one list:

FR name	A2L addr	size
DIFFMAX	16546	2
DLDUVES	133B4	2
DLUL	19CDE	1
DPBKVLE	2A900	2
DPBKVPMN	2A8E6	2
DPBKVPPBKV	2A8E8	18
DPBKVRPD	2A8FA	2
DPBKVSPS	2A84E	2
DPBKVUKKPU	2A850	18
DPBKVUKNKH	2A862	18
DPBKVUKNW	2A874	18
DPBKVUKP	2A886	18
DPBKVUKPU	2A898	18
DPBKVUS	1AF4E	1
DPDSVLU	1E93E	2
DPSBKV	2A902	2
DPSLV	1832A	1
DPSPBKVNPH	2A904	2
DPSPUBKVH	2A906	2
DPSSPBKVPB	2A8FC	2
DPUBABMX	164C2	2
DPUBKV	2A908	2
DPUFFMN	164C4	2
DPUFFMX	164C6	2
DPUFVMN	164C8	2
DPUFVSMN	164CA	2
DPUPS	10619	1
DPUPVDK	1E940	34
DSBOFS	2A818	2
DSLGRAD	13DE8	2
DSLOFS	13DEA	2
DSTGRAD	16496	2
DSUGRAD	1E962	2
DSUOFS	1E964	2
EDLDRP	19CDF	1
ELDOB	19BEC	1
FMDPUBKV	26A14	20
FQTEPT	1A27E	13
FRLFSDP	1F210	46
HSLDSUA	14F46	2
KFANFPU	1ABA0	37
KFBALB	19477	50
KFDLULS	27ED5	82
KFDPLGU	27D82	164
KFFLTA	29526	30
KFGLTA	29544	30
KFLDIMX	28002	256
KFLDIOPU	19B90	64
KFLDRQ0	28294	128
KFLDRQ1	28314	128
KFLDRQ2	28394	128
KFPLGUB	27E26	164
KFPRG	1E7C2	156
KFSDLDSUA	14F48	240
KFTVLDRE	19CAD	46
KFTXFTA	29562	30
KFURL	1E85E	156
KFXFTA	29580	30
KLDPDK	1EBF8	66
KLTDS	1649A	26
KMLTESG	29606	2
LDEIAO	19BD0	1
LDEIAP	19BD1	1
LDEIAPS	19BD2	1
LDEIAU	19BD3	1
LDPBN	19C47	8
LDUVRS	15030	2
MSNPCV	19727	29
NDLDRAPU	27FB7	5
NLDIAPU	284A0	5
OPBKVUKKB	2A8D6	2
OPBKVUKNKH	2A8D8	2
OPBKVUKNWB	2A8DA	2
OPBKVUKPB	2A8DC	2
OPBKVUKPUB	2A8DE	2
PBKBKREHY	2A8E0	2
PBKVKRHY	2A8E2	2
PBKVMN	2A90A	2
PBKVMX	2A90C	2
PBKVVSTGPV	2A82E	26
PLSOLAP	13F52	2
PSAPES	1F240	2
PSSOLNGRD	13DA4	2
PSSOLPF	13DA6	2
PSSOLPGRD	13DA8	2
PUE	1E966	2
PUEBKV	2A848	2
PUKORRV	295A8	34
PUMN	1E968	2
PUMX	1E96A	2
PUSMAX	16548	2
PUSMIN	1654A	2
PUSPSMX	1E96C	2
PVDKMN	1E96E	2
PVDKMX	1E970	18
PVDKPSMX	1E982	2
PVDKPUD	18CDF	1
UMDYLDR	19BEB	1

This is pretty much my current point, I've also cross-checked some of these maps with a list posted by Bische (http://nefariousmotorsports.com/forum/index.php?topic=3027.msg29814#msg29814) in official 5120 thread, some do match up, some don't.

Specifically, there's no mention of KFDPVL, PADMSA, FLAMPA and PUELSU in RS6 A2L.
Plus, I find it quite strange that Bische modifies PVDKMN and leaves alone PVDKMX.

Also, I think I've figured out most of map the addresses for my BIN and they indeed are WAY off, so use those A2L locations with care. Always double-check!

It's also a good idea to grab IDA and start looking through functions. I already tried it to some extent, but I'm not that deep.
Speaking of which, can anyone confirm DPPs for a 7.1.1 mentioned in this thread (http://nefariousmotorsports.com/forum/index.php?topic=1803.0)?
DPP0 - 0x23F
DPP1 - 0x3C
DPP2 - 0xE0
DPP3 - 0x3

Anyways, time permitting, I will try to update this thread as I progress

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 can just patch this.

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.

Awesome start. Please keep us updated, especially if you find things that apply to many other files that others may have missed.

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. :P

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 (http://nefariousmotorsports.com/forum/index.php?topic=2306.0) 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 (http://nefariousmotorsports.com/forum/index.php?topic=2431.0) 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 (http://www.keil.com/dd/docs/datashts/infineon/c166ism.pdf) will surely help. :) The next tool that will help you is funktionsrahmen (http://www.nefariousmotorsports.com/forum/index.php?topic=400.0title=) 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. :)

I actually have a few scripts to assist in this... since ME7L does such a great job detecting ram locations, importing this information directly into IDA pro via script helps a BUNCH when you're trying to find the basics...

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. :)

Hello nubcake,

Looks like some good stuff here! What RS6 software are you using for this? Let me know if you need anything :)

Following...

Why? There is a full damos available, and finding the ASM divisions takes 30 seconds. Anyone that's been here more than 6 months should be able to knock this out in 20 minutes.

OP, not trivializing your work in any way. If you need help, just post. Don't forget the pus_w multiplications that were excluded from the original thread.

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 :)

No disassembly needed. The divisions/multiplications look the same in every file :P

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 (http://nefariousmotorsports.com/forum/index.php?topic=19.0), ols (http://nefariousmotorsports.com/forum/index.php?topic=205.0), csv mappack (http://nefariousmotorsports.com/forum/index.php?topic=613.msg5023#msg5023) and especially "tasty" one - ram variables file (http://nefariousmotorsports.com/forum/index.php?topic=472.msg4325#msg4325)! 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 (http://nefariousmotorsports.com/forum/index.php?topic=7575.msg80038#msg80038) 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. :)

Thanks for the update, and PLEASE let us know if you find anything that might be applicable to the already well known ME7.1 5120 hacks.

I really appreciate the effort you are making, and your sharing it with us.

Will do!  ;)

Try this as the bin:

OK, this looks interesting.

Problem is, I'm completely illiterate when it comes to anything that doesn't have a point and shoot interface lol.

can someone clarify for me exactly how all this scripting stuff works???

I know that's probably a really broad question, but basically what I want to know is how I would take a .bin like one from a 3.0 or 4.2 (both of which have no defined files as far as I can tell) and use these scripting programs being discussed here to pinpoint map addresses.

I'm especially interested in being able to find the 1x1 addresses and small one dimensional maps as I can't tell where they are just by looking at the binary in winOLS. 

I could also do with a very hands-on how-to-load-binary-to-IDA. All the instructions here seem to be from/to experienced users versed in ASM, or maybe I'm just being exceptionally slow :)

I work with computers/software as my day job, hobby from late 1980's but disassembly is new for me. I've been messing with IDA but it's kind of frustrating when I don't know if the reason I'm not getting any results is because the binary isn't loaded correctly.

Thank you DD, the binary match with the a2l. Might come in handy some day, if nothing else it might help when working with other 7.1.1 without dam/a2l .
Now it should be much easier for OP to fix the 5120 for RS6 2003.

As for post about IDA from hopsis I hope you can post in one of numerous IDA threads about your desire. Or even read a thread or two to learn how to import a bin into IDA.

To the OP, I got about 85 percent of this done last night, including the divisions. LMK where you are.

I to would like to know how this is done? How do people start from knowing nothing about this bin to defining it? Say you have no reference bin with an xdf. How can you properly define this bin?

Think outide the box, what functions use and return important vars?

Heya!

Thanks for the bin! I've got it elsewhere already and I've been digging through it for a while. :) Sorry about the lack of updates.
It's actually quite different from the "production" 366304, so I decided to "dig deeper" and update my binary instead of flashing the A2L one. It's helping me immensely with cross-referencing, though.

Status of my 5120 project didn't change much since my last post, since I got sidetracked with ARMD/MDFAW/etc re-calibration for MT. My car is highly custom, so I wanted to fix everything else before moving forward with boost control.

Everything is pretty much ready to go, all the maps and needed ASM offsets are defined in OLS and "noted" in my excel spreadsheet.
Some of the maps are zeroed and can be ignored, namely: DPSLV, DPUPVDK, KLDPDK, LDEIAO, MSNPCV.
FQTEPT, KFANFPU, KFLDIOPU are zeroed as well, FRLFSDP is constant throughout - but somehow I didn't mark them with "ignore" note.  ;D
There's some very weird stuff going on with PSSOLPF, PSSOLPGRD, PUKORRV. Just halving them is easy, but not sure the result will be "proper".
I'm also hesitant about LDRQ0S and LDRQ1ST - they are noted as "%/100hPa" - I guess it's logical to just leave them alone, since they are "fixed" at 100hPa per, but they are noted as "double" in 1.8 5120 project file.

So, yeah, I'm ready to test, but at the same time I want to figure out all the other stuff that is wrong with my tune. :)

EDIT: if I can be of any help with ASM stuff - ask away! :)

ktm733: well, at this point it's quite easy, since all Motronic ECUs share many functions and are largely similar, even between different families. Starting "ground up" is surely much more difficult, but I wasn't faced with that challenge yet, so can't say much about it. :)

EDIT (16th Jul 2016): It's been tested and running for a while now. Not bumping the thread since I didn't do anything new, everything is described here already. Basically I just took every var related to pressures, logged em on "ordinary" bin, then logged on 5120. Compared "median" of those and checked that they got changed according to my expectations. I might do a detailed post later on to better describe the process.

When I did my Volvo 5120 there was a lot of stuff missing from the nefmoto version, also ou should log every map output to ensure it's right


ktm733:   Ther's never a ground up approach unless you are thick then you wouldn't be using IDA.  See my post re the functions that return important vars..